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 ?
the solution seems to be this
it works perfect, but there seems to be a bug that writes the following in the log file
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 :))