Prevent use of procmailrc by some users

Question

We have an e-mail server running Postfix (SMTP) and Dovecot (POP/IMAP) on Debian 10. Users cannot log directly on it (SSH), but have access to their homes through NFS.

We would like to use Procmail to sort messages tagged as spam by SpamAssassin (X-Spam-Flag: YES header) in a separate folder for each user, using a global /etc/procmailrc file. This seems easy to do, as shown in https://serverfault.com/questions/488044/send-spam-mail-to-a-special-folder-using-postfix, to give an example.

The question is: we don't want to allow our users to use $HOME/.procmailrc files, for security reasons. Is there a way to prevent Procmail from activating $HOME/.procmailrc for most users, except for some trusted ones?

EDIT:

Considering tripleee's answer, I could then write a /etc/procmailrc file containing a test for privileged users (i.e. users allowed to have a local .procmailrc file) as this:

# /etc/procmailrc

# if the e-mail is flagged as spam, deliver it to $JUNK and stop
:0:
    * ^X-Spam-Flag: YES
    $JUNK

# if the user is NOT allowed to have a $HOME/.procmailrc,
# then deliver the message to the default mailbox and stop
:0W:
    # check whether the user is allowed to have a .procmailrc file
    * ! ? check_allowed_user $LOGNAME
    $DEFAULT

# else, do nothing (and $HOME/.procmailrc will be activated)

Do you think this is the way to go? If so, I just need to find a simple and robust way to make the check_allowed_user test.

Answer 1

One way to force Procmail to stop here and now is to simply deliver the message. Inside of /etc/procmailrc I guess you explicitly want to DROPPRIVS first.

DROPPRIVS=yes
:0:
$DEFAULT

Depending on what your local DEFAULT delivery action is set to, maybe remove the second colon to not attempt to lock the destination during delivery. If your mailboxes are traditional /var/spool/mail/username Mbox spools, those do require locking.

For the record, another way to force Procmail to terminate immediately is to assign a value to the special variable HOST. (If Procmail was invoked with multiple file name arguments and the current file is not the last one, it will still process any remaining files.)

There is also DELIVERED=yes which does not by itself stop Procmail from processing the rest of the current recipe file, but which in combination with HOST='' can be used to force Procmail to report a successful delivery to the caller.

Update: Your check_allowed_user script seems like a viable approach, though it might be more efficient if you could embed the check into /etc/procmailrc directly; if you have a fairly limited set of users, maybe something like

DROPPRIVS=yes
:0:
* ! LOGNAME ?? ^(arnie|bertie|cecilia)$
$DEFAULT

where arnie, bertie, and cecilia are your allowed users.

Running an external binary for every delivery is something you generally want to try to avoid, even though today's servers can probably handle it quite well (up to a point!)

Answer 2

Procmail by itself does not have any provisions for that. You have to either modify procmail code by yourself and recompile, or craft some clever wrapper script around procmail that will do what you want.