Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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 ?

share|improve this question
    
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 3 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. –  eichertc Mar 3 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 wiki.debian.org/MaildirConfiguration –  tripleee Mar 3 at 22:24

1 Answer 1

up vote 0 down vote accepted

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 :))

share|improve this answer
1  
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 3 at 17:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.