On 10/24/2012 12:32 PM, /dev/rob0 wrote:
There seems to be much confusion in this thread. I might be able to help clear up some of it, but probably not all, because I agree with Robert about using amavisd-new for filtering and LMTP for delivery.
On Tue, Oct 23, 2012 at 02:52:45PM -0600, Troy Vitullo wrote:
My server uses a system comprised of postfix, dovecot and dspam to filter and deliver mail.
Postfix used the following flags in calling spamc and dovecot:
flags=DRhu user=dovecot:secmail argv=/usr/bin/spamc -u ${recipient} -e /usr/lib/dovecot/deliver -d ${recipient} This looks like you might be using pipe(8). If so, refer to the manual, and note that you are invoking this command as user "dovecot" and group "secmail".
That is wrong use of the "dovecot" user. You probably should have made and used a dedicated "vmail" user. And according to your own post, q.v., the group "secmail" is definitely wrong.
after an upgrade from Debian lenny to squeeze we were able to get everything working except spam filtering. Spamassassin is able to judge whether the mail coming in is spam but everything stops there. Automated or semi-automated upgrades are often a source of pain.
In mail.err I see:
pamc[3608]: exec failed: Permission denied I guess that is spamc, and yes, of course.
spamc shows the same thing in syslog:
exec failed: Permission denied
postfix delays the email:
postfix/pipe[3607]: 50DEFF180EE: to=<[mail]>, relay=dovecot, delay=1.7, delays=0.07/0.01/0/1.6, dsn=4.3.0, status=deferred (system resource problem)
Here are the permissions for deliver:
-rwsr-x--- 1 root dovecot 865084 May 25 2011 /usr/lib/dovecot/deliver The pipe command is not executed as root. Nor is it invoked with the GID "dovecot". You specified group "secmail". Therefore the "other" permissions are what apply. "---" is no read, no write, no execute.
Here are the relevant groups:
s1:~# grep dovecot /etc/group secmail:x:119:postfix,spamd,dovecot This is not relevant. The process has EGID secmail, and the fact that dovecot is a member of secmail does not matter. Bottom line here: it seems that you misunderstood what the group permissions meant.
dovecot:x:111:
here's the dovecot user: s1:~# grep dovecot /etc/passwd dovecot:x:108:111:Dovecot mail server,,,:/usr/lib/dovecot:/bin/false
here's dovecot -n:
# 1.2.15: /etc/dovecot/dovecot.conf You upgraded -- to 1.2.15? Why?
Many thanks in advance for any advice you can give. Again, you should check on the wiki about the appropriate use of the "dovecot" user, and also read the wiki about virtual mailboxes. Fix
snip that. Even if you make it work with permissions, you are breaking Dovecot's security model of privilege separation. The "dovecot" user is for Dovecot's internal use only, not for delivering mail and ownership of mailboxes.
The poster who was talking about postconf(5) mailbox_command was bringing in a red herring. That is for local(8) delivery, and you evidently are using pipe(8). Just a note: the original post did NOT have the word 'virtual' in it.
If it did, I missed it and apologize for introducing confusion.
Bill