procmail is ignoring user settings

Question

I use procmail for filtering emails in combination with postfix. procmail is triggered by postfix via the in the main.cf mailbox_command

mailbox_command = /usr/bin/procmail -t -a "$EXTENSION"

but in the master.cf

procmail unix    n    n    -    20    pipe
    flags=R user=vmail argv=/usr/bin/procmail -o SENDER=${sender} -m USER=${user} EXTENSION=${extension}

I do not understand exactly but it seems to me that the two are not the same command Is it possible that this situation is the reason why procmail is ignoring the user setting un the /home/user/.procmailrc ?

if we take a look to the procmail logs we see that

From info@some_spam_domain.com  Sat Mar  1 17:10:24 2014
 Subject: ***** SPAM 27.4 ***** Hi i'm Masha 22 yo. do you have web camera?
  Folder: /usr/lib/dovecot/deliver -m Junk -d hans                       4202

it is actually using dovecot to deliver the emails. hans is a user and JUNK is a folder defined in the main /etc/procmailrc as

DROPPRIVS=no    
DELIVER="/usr/lib/dovecot/deliver"
SPAMORDNER="$DELIVER -m Junk -d $USER"

:0 w
* ^X-Spam-Status: Yes
| $SPAMORDNER

I have there in my procmailcf

DROPPRIVS=no

DROPPRIVS=no works with -d, but turns off the user .procmailrc DROPPRIVS=yes forced procmail to act as user witch has as result that deliver works without -d and it delivers to /var/mail/ And here we get closer to the point I do not understand.

turning on DROPPRIVS seems to work only if the user has a .prcocmailrc in his home folder, because I can define there to deliver to /home/ else the mails are delivered to /var/mail/ and its in mbox format instead of maildir format

I supose the workaround would be something like this (exemple in pseudocode) in /etc/procmailrc

if exist  /home/<username>/.procmailrc
    set DROPPRIVS=yes
else
    set DROPPRIVS=no

how do I write this in procmail language ?

If Procmail falls off the end of `/etc/procmailrc` it will process the user's `.procmailrc` if any, and otherwise deliver to `DEFAULT`. Unfortunately, `DEFAULT` can only be a mailbox name, not a pipeline to Dovecot's `deliver` program. Maybe either Procmail or Dovecot should improve integration; I would place my bets on Dovecot, as Procmail has not been in active development for a long time. — tripleee, Mar 03 '14 at 17:20
they key is this DROPPRIVS. If true it processes the user's .procmailrc if any. If DROPPRIVS is false it ignores them. And this has nothing to do with the way you deliver. I was not able to make procmail to deliver in a maildir format, into the users folders. It was always mbox what procmail generated, so I choose dovecot to make the deliver, as i already use it for the imap. — Max Muster, Mar 03 '14 at 21:46
You can set `DEFAULT` to a Maildir mailbox name. The format of the file name determines the delivery format. A plain file is mbox, a directory with a trailing slash is Maildir. This will not update the Dovecot indices, though. (There is also `dir/.` for the legacy MH format.) See also https://wiki.debian.org/MaildirConfiguration — tripleee, Mar 03 '14 at 22:24

score 0 · Accepted Answer · answered Mar 02 '14 at 21:09

the solution seems to be this

TMPFILE="$HOME/.procmailrc"
:0 w
* ?test -f $TMPFILE
{
    DROPPRIVS=yes
}

:0 Ew
* !test -f $TMPFILE
{
    DROPPRIVS=no
}

it works perfect, but there seems to be a bug that writes the following in the log file

procmail: Executing "test -f $TMPFILE"
procmail: Match on "test -f $TMPFILE"
procmail: Assigning "DROPPRIVS=yes"
procmail: Assuming identity of the recipient, VERBOSE=off
procmail: Program failure (75) of "/usr/lib/dovecot/deliver"

I am not able to understand who set this VERBOSE=off, because its not in my procmailrc it seems to be somewhere in the code of deliver.

anyway after this line it jumps correctly to the user .procmailrc and executes it without failure. so this failure seems to be just a cosmetic one.

P.S. the best way to understand a problem is to try to explain it to someone else :))

I think the `VERBOSE=off` is built into Procmail; presumably, it disables `VERBOSE` in order to prevent users from flooding system logs (or, conversely, from private information to end up in world-readable logs). — tripleee, Mar 03 '14 at 17:11

procmail is ignoring user settings

1 Answers1

Linked