Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
Am 24.10.2012 03:32, schrieb Bill Shirley:
What is your mailbox_command in main.cf? I just use:
mailbox_command = /usr/bin/spamc -u $USER -e
/usr/lib64/dovecot/deliver -a $RECIPIENT -f $SENDER -m $EXTENSION
I don't need anything in master.cf. But you should be using -u ${user}
for spamc.
long time ago i tested this with dovecot lda postfix master.cf
with a total virtual setup
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/bin/spamc -e
/usr/lib/dovecot/deliver -f ${sender} -d ${recipient}
but i strongly do not recommand this !!!
use spamass-milter, amavis etc with dovecot lmtp
as described on many sites
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Joerg Heidrich
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On 10/24/2012 2:33 AM, Robert Schetterer wrote:
Am 24.10.2012 03:32, schrieb Bill Shirley:
What is your mailbox_command in main.cf? I just use:
mailbox_command = /usr/bin/spamc -u $USER -e
/usr/lib64/dovecot/deliver -a $RECIPIENT -f $SENDER -m $EXTENSION
I don't need anything in master.cf. But you should be using -u ${user}
for spamc.
long time ago i tested this with dovecot lda postfix master.cf
with a total virtual setup
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/bin/spamc -e
/usr/lib/dovecot/deliver -f ${sender} -d ${recipient}
but i strongly do not recommand this !!!
use spamass-milter, amavis etc with dovecot lmtp
as described on many sites
Best Regards
MfG Robert Schetterer
Can you get per-user Spamassassin configs this way?
Why user=vmail:vmail? Is this for virtual domains? I didn't think we
were talking about them.
Instead of strongly recommending against this, why not elaborate on the
problems with using spamc in the mailbox_command?
Bill
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
Am 24.10.2012 17:47, schrieb Bill Shirley:
On 10/24/2012 2:33 AM, Robert Schetterer wrote:
Am 24.10.2012 03:32, schrieb Bill Shirley:
What is your mailbox_command in main.cf? I just use:
mailbox_command = /usr/bin/spamc -u $USER -e
/usr/lib64/dovecot/deliver -a $RECIPIENT -f $SENDER -m $EXTENSION
I don't need anything in master.cf. But you should be using -u ${user}
for spamc.
long time ago i tested this with dovecot lda postfix master.cf
with a total virtual setup
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/bin/spamc -e
/usr/lib/dovecot/deliver -f ${sender} -d ${recipient}
but i strongly do not recommand this !!!
use spamass-milter, amavis etc with dovecot lmtp
as described on many sites
Best Regards
MfG Robert Schetterer
Can you get per-user Spamassassin configs this way?
Why user=vmail:vmail? Is this for virtual domains? I didn't think we
were talking about them.
Instead of strongly recommending against this, why not elaborate on the
problems with using spamc in the mailbox_command?
Bill
Hi Bill, you missed
my
i tested this with dovecot lda
in hope you may adapt the syntax to your needs by your own
here are the recommanded setups
http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix
http://wiki.dovecot.org/LDA/Postfix
--snip
mailbox_command = /usr/bin/spamc -e /usr/lib/dovecot/deliver
--snipend
by the way using dovecot lmtp and i.e amavis or spamass-milter/clamav-milter
might be better choice in many ways
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Joerg Heidrich
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On Tue, 23 Oct 2012 21:32:59 -0400
Bill Shirley b...@knoxvillechristian.org wrote:
On 10/23/2012 9:06 PM, Bill Shirley wrote:
What is your mailbox_command in main.cf? I just use:
mailbox_command = /usr/bin/spamc -u $USER -e
/usr/lib64/dovecot/deliver -a $RECIPIENT -f $SENDER -m
$EXTENSION
I don't need anything in master.cf. But you should be using -u
${user} for spamc.
Bill
Forgot to ask, are you using Spamassassin's per-user configs? If
you're not, that probably is your problem. It's probably trying to
update bayes tokens and it doesn't have permission.
I use per-user configs which are nice. One man's spam is another
man's ham. Plus each user can have his/her own whitelist.
I use these spamd args: -d -c -m10 --user-config
You usually can find the args in /etc/sysconfig.
Bill
Thanks for getting back to me Bill. Actually I'm using per-user prefs and
permissions look great all the way down. When I send a test mail with
everything turned on the bayes tokens are updated. Things appear to die later
in the process.
Regarding the mailbox command I was using:
mailbox_command = /usr/lib/dovecot/deliver -d $USER -m $EXTENSION
I tried removing the flags from master.cf and changing my command to:
mailbox_command = /usr/bin/spamc -u $USER -e /usr/lib/dovecot/deliver -d
$USER -m $EXTENSION
and then:
mailbox_command = /usr/bin/spamc -u ${recipient} -e /usr/lib/dovecot/deliver -d
${recipient} -m $EXTENSION
and everything in between.
No mail made it through, so I kept this in master.cf:
dovecot unix - n n - - pipe
flags=DRhu user=dovecot:dovecot argv=/usr/lib/dovecot/deliver -d ${recipient}
and of course it over-rode my mailbox_command. Mail came thrrough but it
contained no spamassassin header.
I'm starting to thing that spamc doesn't have the permissions to write its
headers to the message. How can I test that theory?
spamd runs witht these flags:
/usr/sbin/spamd --create-prefs -x --max-children 3 --username spamd
--helper-home-dir /var/lib/spamassassin -s /var/lib/spamassassin/spamd.log
--virtual-config-dir=/var/lib/spamassassin/users/%d/%l -d
--pidfile=/var/run/spamd.pid
It's pretty much the same as yours, I just use the long versions of the args.
the spamd user exists:
spamd:x:1010:1011::/var/lib/spamassassin:/bin/false
I was missing /etc/dovecot/default.sieve, which had to be a big problem, but I
recovered it. Here's are its contents:
require fileinto;
if exists X-Spam-Flag {
if header :contains X-Spam-Flag NO {
} else {
discard;
stop;
}
}
Anything else I could be missing? I even insanely running spamd as the root
user:
/usr/sbin/spamd --create-prefs -x --max-children 3 --username root
--helper-home-dir /var/lib/spamassassin -s /var/lib/spamassassin/spamd.log
--virtual-config-dir=/var/lib/spamassassin/users/%d/%l -d
--pidfile=/var/run/spamd.pid
Thanks,
Troy
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On 10/24/2012 12:09 PM, Robert Schetterer wrote:
Am 24.10.2012 17:47, schrieb Bill Shirley:
On 10/24/2012 2:33 AM, Robert Schetterer wrote:
Am 24.10.2012 03:32, schrieb Bill Shirley:
What is your mailbox_command in main.cf? I just use:
mailbox_command = /usr/bin/spamc -u $USER -e
/usr/lib64/dovecot/deliver -a $RECIPIENT -f $SENDER -m $EXTENSION
I don't need anything in master.cf. But you should be using -u ${user}
for spamc.
long time ago i tested this with dovecot lda postfix master.cf
with a total virtual setup
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/bin/spamc -e
/usr/lib/dovecot/deliver -f ${sender} -d ${recipient}
but i strongly do not recommand this !!!
use spamass-milter, amavis etc with dovecot lmtp
as described on many sites
Best Regards
MfG Robert Schetterer
Can you get per-user Spamassassin configs this way?
Why user=vmail:vmail? Is this for virtual domains? I didn't think we
were talking about them.
Instead of strongly recommending against this, why not elaborate on the
problems with using spamc in the mailbox_command?
Bill
Hi Bill, you missed
my
i tested this with dovecot lda
in hope you may adapt the syntax to your needs by your own
here are the recommanded setups
http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix
http://wiki.dovecot.org/LDA/Postfix
--snip
mailbox_command = /usr/bin/spamc -e /usr/lib/dovecot/deliver
--snipend
by the way using dovecot lmtp and i.e amavis or spamass-milter/clamav-milter
might be better choice in many ways
Best Regards
MfG Robert Schetterer
I'm saying I have a WORKING setup (local and virtual) where spamc runs
and then uses dovecot deliver. spamd uses spamassassin per-user configs.
master.cf has (caution, line wraps around in email):
vdovecotunix- n n - 5 pipe
flags=DRuh user=vmail:vmail argv=/usr/bin/spamc -p 784 -u
${recipient} -e /usr/lib64/dovecot/deliver -d ${user}@${domain} -a
{recipient} -f ${sender} -n -m ${extension}
main.cf has:
mailbox_command = /usr/bin/spamc -u $USER -e
/usr/lib64/dovecot/deliver -a $RECIPIENT -f $SENDER -m $EXTENSION
virtual_transport = vdovecot
vdovecot_destination_recipient_limit= 1
I don't understand why you strongly recommend against using the
mailbox_command. Is there a security risk here?
I've read all the howtos. There are many ways to setup a mail server.
That's the beauty of postfix, spamassassin, dovecot, etc; you can make
it do what you want. Yes, some setups are bad.
I am not the original poster.
Hope this clears things up,
Bill
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
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?
snip
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
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).
--
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On Wed, Oct 24, 2012 at 12:28:48PM -0400, Bill Shirley wrote: I don't understand why you strongly recommend against using the mailbox_command. Is there a security risk here? One issue is that mailbox_command is only used for local(8) delivery. You brought that up for the OP, who is reporting a problem in trying to use pipe(8). mailbox_command is not relevant for pipe. That added more confusion to the issue at hand. I can't speak for Robert, but as I said in the other post I agree with him, so I will say why. You will get better overall performance with amavisd-new and LMTP, rather than invoking a command via pipe for every delivery. No, mailbox_command in itself is not a security risk, except insofar as you could DoS yourself with more deliveries at once than the system is able to handle. Some risk of DoS is present for any kind of content filtering, though. But amavisd-new after-queue reduces that risk. I've read all the howtos. Eww. I have not. I have made extensive referral to the documentation, however, and that is what I recommend. Many thousands of people who are generating web content do not know much about email. You don't want to turn to them for advice about this! (FWIW, many of the howtos I have looked at are very bad.) There are many ways to setup a mail server. That's the beauty of postfix, spamassassin, dovecot, etc; you can make it do what you want. Yes, some setups are bad. Yes and yes. I am not the original poster. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On 10/24/2012 12:10 PM, Troy Vitullo wrote:
On Tue, 23 Oct 2012 21:32:59 -0400
Bill Shirley b...@knoxvillechristian.org wrote:
On 10/23/2012 9:06 PM, Bill Shirley wrote:
What is your mailbox_command in main.cf? I just use:
mailbox_command = /usr/bin/spamc -u $USER -e
/usr/lib64/dovecot/deliver -a $RECIPIENT -f $SENDER -m
$EXTENSION
I don't need anything in master.cf. But you should be using -u
${user} for spamc.
Bill
Forgot to ask, are you using Spamassassin's per-user configs? If
you're not, that probably is your problem. It's probably trying to
update bayes tokens and it doesn't have permission.
I use per-user configs which are nice. One man's spam is another
man's ham. Plus each user can have his/her own whitelist.
I use these spamd args: -d -c -m10 --user-config
You usually can find the args in /etc/sysconfig.
Bill
Thanks for getting back to me Bill. Actually I'm using per-user prefs and
permissions look great all the way down. When I send a test mail with
everything turned on the bayes tokens are updated. Things appear to die later
in the process.
Regarding the mailbox command I was using:
mailbox_command = /usr/lib/dovecot/deliver -d $USER -m $EXTENSION
I tried removing the flags from master.cf and changing my command to:
mailbox_command = /usr/bin/spamc -u $USER -e /usr/lib/dovecot/deliver -d $USER -m
$EXTENSION
What was your setting for mailbox_transport (in main.cf) when you did
this? mailbox_transport could be overriding mailbox_command.
and then:
mailbox_command = /usr/bin/spamc -u ${recipient} -e /usr/lib/dovecot/deliver -d
${recipient} -m $EXTENSION
and everything in between.
No mail made it through, so I kept this in master.cf:
dovecot unix - n n - - pipe
flags=DRhu user=dovecot:dovecot argv=/usr/lib/dovecot/deliver -d ${recipient}
Where are you calling spamc with this?
and of course it over-rode my mailbox_command. Mail came thrrough but it
contained no spamassassin header.
I'm starting to thing that spamc doesn't have the permissions to write its
headers to the message. How can I test that theory?
spamd runs witht these flags:
/usr/sbin/spamd --create-prefs -x --max-children 3 --username spamd
--helper-home-dir /var/lib/spamassassin -s /var/lib/spamassassin/spamd.log
--virtual-config-dir=/var/lib/spamassassin/users/%d/%l -d
--pidfile=/var/run/spamd.pid
It's pretty much the same as yours, I just use the long versions of the args.
the spamd user exists:
spamd:x:1010:1011::/var/lib/spamassassin:/bin/false
Your permissions on /var/lib/spamassassin are probably right, but check
them and the subdirectories.
I was missing /etc/dovecot/default.sieve, which had to be a big problem, but I
recovered it. Here's are its contents:
require fileinto;
if exists X-Spam-Flag {
if header :contains X-Spam-Flag NO {
} else {
discard;
stop;
}
}
Anything else I could be missing? I even insanely running spamd as the root
user:
/usr/sbin/spamd --create-prefs -x --max-children 3 --username root
--helper-home-dir /var/lib/spamassassin -s /var/lib/spamassassin/spamd.log
--virtual-config-dir=/var/lib/spamassassin/users/%d/%l -d
--pidfile=/var/run/spamd.pid
Thanks,
Troy
I have two instances of spamd running. One for local users and the
other for virtual users (note the port here and in master.cf):
[root@elmo includes]# ps aux | grep spamd
root 2684 0.1 1.0 173760 88484 ?SN 03:30 0:34 spamd child
root 23987 0.0 0.7 147524 61900 ?SNs Oct23 0:05
/usr/bin/spamd -d -c -m10 --user-config
root 24004 0.0 0.7 147504 61844 ?SNs Oct23 0:05
/usr/bin/spamd -d -c -m5 -x
--virtual-config-dir=/home/vmail/domains/%d/%l/.spamassassin -u vmail
--port=784 -H
vmail24014 0.0 0.9 161204 75880 ?SN Oct23 0:05 spamd child
vmail24015 0.0 0.7 147504 59700 ?SN Oct23 0:00 spamd child
root 25772 0.0 0.8 155020 69188 ?SN 12:07 0:00 spamd child
root 28981 0.0 0.0 16688 940 pts/4S+ 12:36 0:00 grep
--color spamd
My vmail user:
[root@elmo includes]# grep vmail /etc/{group,passwd}
/etc/group:vmail:x:399:
/etc/passwd:vmail:x:399:399:Virtual Mail:/home/vmail:/bin/bash
My virtual user .spamassassin permissions:
[root@elmo includes]# ldp /home/vmail/domains/example.com/bill/.spamassassin
drwxr-xr-x 20 root root 4096 May 8 2011 /home
drwxr-xr-x 10 vmail vmail 4096 Oct 22 10:59 /home/vmail
drwxr-x--- 9 vmail vmail 4096 Oct 21 21:24 /home/vmail/domains
drwxr-x--- 6 vmail vmail 4096 Jul 4 2007 /home/vmail/domains/example.com
drwxr-x--- 4 vmail vmail 4096 Jul 4 2007
/home/vmail/domains/example.com/bill
drwxr-s--- 3 vmail vmail 4096 Jan 30 2012
/home/vmail/domains/example.com/bill/.spamassassin
My local user:
[root@elmo includes]# ldp /home/bill/.spamassassin
drwxr-xr-x 20 root root 4096 May 8 2011 /home
drwxr-xr-x 32 bill bill 4096 Oct 22 17:42
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On 10/24/2012 12:44 PM, /dev/rob0 wrote: On Wed, Oct 24, 2012 at 12:28:48PM -0400, Bill Shirley wrote: I don't understand why you strongly recommend against using the mailbox_command. Is there a security risk here? One issue is that mailbox_command is only used for local(8) delivery. You brought that up for the OP, who is reporting a problem in trying to use pipe(8). mailbox_command is not relevant for pipe. That added more confusion to the issue at hand. It was my understanding that he is implementing local users. I can't speak for Robert, but as I said in the other post I agree with him, so I will say why. You will get better overall performance with amavisd-new and LMTP, rather than invoking a command via pipe for every delivery. Admittedly, I have not used amavisd-new or LMTP; they may be better. But will they allow spamassassin per-user prefs? Performance is a plus; another daemon is not. That saying, I'll run another daemon if I get something out of it. Any benchmarks on this? No, mailbox_command in itself is not a security risk, except insofar as you could DoS yourself with more deliveries at once than the system is able to handle. Some risk of DoS is present for any kind of content filtering, though. But amavisd-new after-queue reduces that risk. I've read all the howtos. Eww. I have not. I have made extensive referral to the documentation, however, and that is what I recommend. Many thousands of people who are generating web content do not know much about email. You don't want to turn to them for advice about this! Probably mis-spoke; I said howtos instead of documentation. Yes, there are many bad howtos out there. (FWIW, many of the howtos I have looked at are very bad.) There are many ways to setup a mail server. That's the beauty of postfix, spamassassin, dovecot, etc; you can make it do what you want. Yes, some setups are bad. Yes and yes. I am not the original poster. Respectfully, Bill
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
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?
snip
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
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
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
Am 24.10.2012 18:28, schrieb Bill Shirley: I don't understand why you strongly recommend against using the mailbox_command. Is there a security risk here? no ,until you dont have made any setup failures... your right there are tons of working possible setups your free to configure as you like, but lmtp with dovecot is state of the art in my eyes, these days in my tests lda combined with spamc had not enough performance for my needs and used to much resources compared to lmtp sometimes it crashed, but as i said ,long time ago however i found total virtual setups much more easy then with local by permissions stuff etc, and milters are much more easy to use and setup, also i.e amavis gives great other choices beside spamassassin stuff but do as you like ,no need to flame Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On Wed, Oct 24, 2012 at 01:28:41PM -0400, Bill Shirley wrote: On 10/24/2012 12:32 PM, /dev/rob0 wrote: There seems to be much confusion in this thread. I might be able 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: snip 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) 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. It did not, but it did indeed include the pipe log output shown above, and therefore ^mailbox_.* postconf settings do not apply. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On Wed, Oct 24, 2012 at 01:21:58PM -0400, Bill Shirley wrote: On 10/24/2012 12:44 PM, /dev/rob0 wrote: I can't speak for Robert, but as I said in the other post I agree with him, so I will say why. You will get better overall performance with amavisd-new and LMTP, rather than invoking a command via pipe for every delivery. Admittedly, I have not used amavisd-new or LMTP; they may be better. But will they allow spamassassin per-user prefs? Amavisd-new is indeed capable of per-user preferences. Performance is a plus; another daemon is not. That saying, I'll run another daemon if I get something out of it. Any benchmarks on this? A daemon is generally (I'd almost daresay always) less overhead than the invocation of many single-delivery processes. No benchmarking is needed to support this fact. That said, for many small sites, it does not matter much. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On 10/24/2012 1:37 PM, Robert Schetterer wrote: Am 24.10.2012 18:28, schrieb Bill Shirley: I don't understand why you strongly recommend against using the mailbox_command. Is there a security risk here? no ,until you dont have made any setup failures... your right there are tons of working possible setups your free to configure as you like, but lmtp with dovecot is state of the art in my eyes, these days in my tests lda combined with spamc had not enough performance for my needs and used to much resources compared to lmtp sometimes it crashed, but as i said ,long time ago however i found total virtual setups much more easy then with local by permissions stuff etc, and milters are much more easy to use and setup, also i.e amavis gives great other choices beside spamassassin stuff but do as you like ,no need to flame Best Regards MfG Robert Schetterer I don't see a flame anywhere in my posts. The list is for respectfully exchanging information. I thought that was what we were doing. Bill
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On 10/24/2012 1:39 PM, /dev/rob0 wrote: On Wed, Oct 24, 2012 at 01:28:41PM -0400, Bill Shirley wrote: On 10/24/2012 12:32 PM, /dev/rob0 wrote: There seems to be much confusion in this thread. I might be able 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: snip 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) 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. It did not, but it did indeed include the pipe log output shown above, and therefore ^mailbox_.* postconf settings do not apply. Could be he was going about it the wrong way; mixing the two. Do you know whether he's trying to do virtual or local? My postings describe my implementation. I'm just trying to help him. But I don't think my posts are being received that way. Bill
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
Am 24.10.2012 19:21, schrieb Bill Shirley: Admittedly, I have not used amavisd-new or LMTP; they may be better. But will they allow spamassassin per-user prefs? Performance is a plus; another daemon is not. That saying, I'll run another daemon if I get something out of it. Any benchmarks on this? this went away from the orig post, it went to general design of a email system, i think rob did explain the possible problems to the orginal poster very fine some people may start with local users as traditional mailsetup depend on this next steps they are going to use lda perhaps trying combined with spamc with local users so there is nothing bad on it, its somehow old school, after all, as said ,there are many broken advices out in www by all setups, and sometimes there are mixed up by local and virtual, so people may fail with permissions of local users , daemons etc sometimes later if more domains should be hosted pure virtual setups are the better way, and making stuff more simple ( but often people fail first in seeing virtual more easy ), lmtp is the best choice for it compared starting a deliver process for each mail, its working as a service So anyone should think about what he needs before starting to setup i.e amavis is a well supported framework since long time, it has tons of features you might wanna have and as well it can be used with per-user prefs if you dont like the complex amavis style ( many functions have many config points ), you could simple use a chain of milter i.e spamass-milter ( also with per-user prefs ), clamav-milter with milter you are able to reject on smtp income stage which is very cool anyway milters also have their pros an contras, read postfix sites about them i didnt tested dspam looks like it chained between lmtp so perhaps also good choice, and could be combined with milters i had other setups with chained spampd/clamsmtp amavis on seperate filter hosts etc all worked fine but as dovecot/postfix development going forward , i redesigned all these depending to have more functions and performance so i recommand, use your working setups as i.e lifetime of your hardware etc, but if building new mailserver choose modern setup ideas and daemon combinations Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On Wed, Oct 24, 2012 at 02:04:39PM -0400, Bill Shirley wrote: On 10/24/2012 1:39 PM, /dev/rob0 wrote: On Wed, Oct 24, 2012 at 01:28:41PM -0400, Bill Shirley wrote: On 10/24/2012 12:32 PM, /dev/rob0 wrote: On Tue, Oct 23, 2012 at 02:52:45PM -0600, Troy Vitullo wrote: snip 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) 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. It did not, but it did indeed include the pipe log output shown above, and therefore ^mailbox_.* postconf settings do not apply. Could be he was going about it the wrong way; mixing the two. Do you know whether he's trying to do virtual or local? There are lots of wrong ways. The most wrongful of the OP's ways I found was the misuse of the dovecot user. The second most wrong, which was the actual problem at hand, was a misunderstanding of how group permissions are applied. Mixing virtual and local in Postfix and Dovecot is no problem at all, and in fact multiple modes of delivery are possible, even within a given address class or even within a domain. All we know here is what the OP posted. You don't usually use pipe for delivery to local (Unix) users. My postings describe my implementation. For the OP to change to local delivery would require reworking his setup extensively, on the Postfix side, and here we are on the Dovecot list, so I wouldn't go into that here. But sure, there are other (and for many purposes, better) means of doing what he might want to do. I'm just trying to help him. But I don't think my posts are being received that way. Regarding Robert's flame comment in the other subthread, I agree with you; I saw no flame. And I did not suggest that you were not trying to help. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
Am 24.10.2012 20:25, schrieb /dev/rob0: Regarding Robert's flame comment in the other subthread, I agree with you; I saw no flame. And I did not suggest that you were not trying to help take my sorry, as non native english, perhaps i missused flame here Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On 10/24/2012 2:25 PM, /dev/rob0 wrote: On Wed, Oct 24, 2012 at 02:04:39PM -0400, Bill Shirley wrote: On 10/24/2012 1:39 PM, /dev/rob0 wrote: On Wed, Oct 24, 2012 at 01:28:41PM -0400, Bill Shirley wrote: On 10/24/2012 12:32 PM, /dev/rob0 wrote: On Tue, Oct 23, 2012 at 02:52:45PM -0600, Troy Vitullo wrote: snip 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) 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. It did not, but it did indeed include the pipe log output shown above, and therefore ^mailbox_.* postconf settings do not apply. Could be he was going about it the wrong way; mixing the two. Do you know whether he's trying to do virtual or local? There are lots of wrong ways. The most wrongful of the OP's ways I found was the misuse of the dovecot user. The second most wrong, which was the actual problem at hand, was a misunderstanding of how group permissions are applied. Mixing virtual and local in Postfix and Dovecot is no problem at all, and in fact multiple modes of delivery are possible, even within a given address class or even within a domain. All we know here is what the OP posted. You don't usually use pipe for delivery to local (Unix) users. My postings describe my implementation. For the OP to change to local delivery would require reworking his setup extensively, on the Postfix side, and here we are on the Dovecot list, so I wouldn't go into that here. But sure, there are other (and for many purposes, better) means of doing what he might want to do. I'm just trying to help him. But I don't think my posts are being received that way. Regarding Robert's flame comment in the other subthread, I agree with you; I saw no flame. And I did not suggest that you were not trying to help. Thank you for saying this. My intent was to help. I make my living setting up/programming with open source software. I don't want to only 'take'. I want to show my gratitude for is so freely given to me by also giving. I don't program in C so I can't help with that. But I can share configurations/experiences and hopefully that is a contribution. Bill
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On 10/24/2012 2:24 PM, Robert Schetterer wrote: Am 24.10.2012 19:21, schrieb Bill Shirley: Admittedly, I have not used amavisd-new or LMTP; they may be better. But will they allow spamassassin per-user prefs? Performance is a plus; another daemon is not. That saying, I'll run another daemon if I get something out of it. Any benchmarks on this? this went away from the orig post, it went to general design of a email system, i think rob did explain the possible problems to the orginal poster very fine some people may start with local users as traditional mailsetup depend on this next steps they are going to use lda perhaps trying combined with spamc with local users so there is nothing bad on it, its somehow old school, after all, as said ,there are many broken advices out in www by all setups, and sometimes there are mixed up by local and virtual, so people may fail with permissions of local users , daemons etc sometimes later if more domains should be hosted pure virtual setups are the better way, and making stuff more simple ( but often people fail first in seeing virtual more easy ), lmtp is the best choice for it compared starting a deliver process for each mail, its working as a service So anyone should think about what he needs before starting to setup i.e amavis is a well supported framework since long time, it has tons of features you might wanna have and as well it can be used with per-user prefs if you dont like the complex amavis style ( many functions have many config points ), you could simple use a chain of milter i.e spamass-milter ( also with per-user prefs ), clamav-milter with milter you are able to reject on smtp income stage which is very cool anyway milters also have their pros an contras, read postfix sites about them i didnt tested dspam looks like it chained between lmtp so perhaps also good choice, and could be combined with milters i had other setups with chained spampd/clamsmtp amavis on seperate filter hosts etc all worked fine but as dovecot/postfix development going forward , i redesigned all these depending to have more functions and performance so i recommand, use your working setups as i.e lifetime of your hardware etc, but if building new mailserver choose modern setup ideas and daemon combinations Best Regards MfG Robert Schetterer Thank you for a very informative post. I took a quick look at spamass-milter but I can't find any configuration information on how to use spamasssassin's per-user prefs. I thought the only way to support per-user prefs was post queue since you have to know who is getting the email to check their prefs. I am using clamav-milter. Milters are nice. I set my mail server up 15+ years ago, so it's time for me to have a re-think here. At that time there were no milters for postfix (don't remember a Dovecot either). I've try to steer away from re-injects since they affect the mail received numbers. Are we saying Dovecot's LMTP can call spamd? I'm on Dovecot 1.2 at home until I can upgrade. There is no LMTP in Dovecot 1.x, right? I have a few mail servers running Dovecot 2.0 and 2.1 and yes, I want them to perform well. Bill
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On 10/24/2012 2:32 PM, Robert Schetterer wrote: Am 24.10.2012 20:25, schrieb /dev/rob0: Regarding Robert's flame comment in the other subthread, I agree with you; I saw no flame. And I did not suggest that you were not trying to help take my sorry, as non native english, perhaps i missused flame here Best Regards MfG Robert Schetterer No problem. You do very well at speaking English. Bill
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On Wed, 24 Oct 2012 11:32:55 -0500 /dev/rob0 r...@gmx.co.uk 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. Thanks for the reality check Rob. I'm circling back with the guy who originally set this up to see if we can get back on the right track. We are using pipe with virtual users, and dovecot doesn't own the mailboxes. If/when we get our collective act together and have more questions I'll respond in more detail. Thanks again, Troy
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
Am 24.10.2012 22:04, schrieb Bill Shirley: On 10/24/2012 2:24 PM, Robert Schetterer wrote: Am 24.10.2012 19:21, schrieb Bill Shirley: Admittedly, I have not used amavisd-new or LMTP; they may be better. But will they allow spamassassin per-user prefs? Performance is a plus; another daemon is not. That saying, I'll run another daemon if I get something out of it. Any benchmarks on this? this went away from the orig post, it went to general design of a email system, i think rob did explain the possible problems to the orginal poster very fine some people may start with local users as traditional mailsetup depend on this next steps they are going to use lda perhaps trying combined with spamc with local users so there is nothing bad on it, its somehow old school, after all, as said ,there are many broken advices out in www by all setups, and sometimes there are mixed up by local and virtual, so people may fail with permissions of local users , daemons etc sometimes later if more domains should be hosted pure virtual setups are the better way, and making stuff more simple ( but often people fail first in seeing virtual more easy ), lmtp is the best choice for it compared starting a deliver process for each mail, its working as a service So anyone should think about what he needs before starting to setup i.e amavis is a well supported framework since long time, it has tons of features you might wanna have and as well it can be used with per-user prefs if you dont like the complex amavis style ( many functions have many config points ), you could simple use a chain of milter i.e spamass-milter ( also with per-user prefs ), clamav-milter with milter you are able to reject on smtp income stage which is very cool anyway milters also have their pros an contras, read postfix sites about them i didnt tested dspam looks like it chained between lmtp so perhaps also good choice, and could be combined with milters i had other setups with chained spampd/clamsmtp amavis on seperate filter hosts etc all worked fine but as dovecot/postfix development going forward , i redesigned all these depending to have more functions and performance so i recommand, use your working setups as i.e lifetime of your hardware etc, but if building new mailserver choose modern setup ideas and daemon combinations Best Regards MfG Robert Schetterer Thank you for a very informative post. I took a quick look at spamass-milter but I can't find any configuration information on how to use spamasssassin's per-user prefs. I thought the only way to support per-user prefs was post queue since you have to know who is getting the email to check their prefs. you have to study its parameters ( they may differ by version and distro ) http://linux.die.net/man/1/spamass-milter i use it like /usr/sbin/spamass-milter -P /var/spool/postfix/spamass-milter/spamass.pid -f -p /var/spool/postfix/spamass/spamass.sock -f -e -x -I -u vmail -r 15 -i 127.0.0.1 i have my spamassassin setup with mysql for users self settings use i.e.e webmail horde with sam module, or something equal with i.e squirrelmail or roundcube but i managed it before ,also in using local files with maildrop as i said ,its not ideal cause of pre queue design, but reality shows good enough for big isp setup and it may be combined I am using clamav-milter. Milters are nice. for antispam using sanesecurity antispam signatures are nice thats cheaper then spamassassin I set my mail server up 15+ years ago, so it's time for me to have a re-think here. At that time there were no milters for postfix (don't remember a Dovecot either). I've try to steer away from re-injects since they affect the mail received numbers. Are we saying Dovecot's LMTP can call spamd? i dont tested ,looks like dspam can do it http://wiki2.dovecot.org/HowTo/Virtual%2BPostfix%2BDspam%2BDovecot I'm on Dovecot 1.2 at home until I can upgrade. There is no LMTP in Dovecot 1.x, right? yes ,you should use 2.1.x I have a few mail servers running Dovecot 2.0 and 2.1 and yes, I want them to perform well. so you may change setup layout Bill Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
[Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
Hi,
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}
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.
In mail.err I see:
pamc[3608]: exec failed: Permission denied
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
Here are the relevant groups:
s1:~# grep dovecot /etc/group
secmail:x:119:postfix,spamd,dovecot
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
# OS: Linux 2.6.26-2-686 i686 Debian 6.0.6
base_dir: /var/run/dovecot/
protocols: imap imaps pop3s pop3
ssl_cert_file: /etc/ssl/certs/s1.troyvit.com.cert
ssl_key_file: /etc/ssl/private/s1.troyvit.com.key
ssl_cipher_list: ALL:!LOW
disable_plaintext_auth: no
verbose_ssl: yes
login_dir: /var/run/dovecot/login
login_executable(default): /usr/lib/dovecot/imap-login
login_executable(imap): /usr/lib/dovecot/imap-login
login_executable(pop3): /usr/lib/dovecot/pop3-login
mail_location: maildir:%h/Maildir/
mbox_write_locks: fcntl dotlock
mail_executable(default): /usr/lib/dovecot/imap
mail_executable(imap): /usr/lib/dovecot/imap
mail_executable(pop3): /usr/lib/dovecot/pop3
mail_plugin_dir(default): /usr/lib/dovecot/modules/imap
mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap
mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3
pop3_enable_last(default): no
pop3_enable_last(imap): no
pop3_enable_last(pop3): yes
pop3_client_workarounds(default):
pop3_client_workarounds(imap):
pop3_client_workarounds(pop3): outlook-no-nuls, oe-ns-eoh
pop3_logout_format(default): top=%t/%p, retr=%r/%b, del=%d/%m, size=%s
pop3_logout_format(imap): top=%t/%p, retr=%r/%b, del=%d/%m, size=%s
pop3_logout_format(pop3): top=%t/%T, retr=%r/%R, del=%d/%m, size=%s
namespace:
type: private
separator: /
inbox: yes
list: yes
subscriptions: yes
lda:
postmaster_address: postmaster@sphere.local
auth_socket_path: /var/run/dovecot/auth-master
mail_plugin_dir: /usr/lib/dovecot/modules/lda/
mail_plugins: sieve
auth default:
mechanisms: plain login
verbose: yes
debug: yes
debug_passwords: yes
passdb:
driver: pam
args: dovecot
passdb:
driver: sql
args: /etc/dovecot/dovecot-sql.conf
userdb:
driver: passwd
userdb:
driver: sql
args: /etc/dovecot/dovecot-sql.conf
socket:
type: listen
client:
path: /var/spool/postfix/private/auth
mode: 432
user: postfix
group: postfix
master:
path: /var/run/dovecot/auth-master
mode: 438
user: dovecot
plugin:
sieve_global_path: /etc/dovecot/default.sieve
sieve: /srv/%d/mail/%n/%n.sieve
Many thanks in advance for any advice you can give.
Troy
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On 10/23/2012 4:52 PM, Troy Vitullo wrote:
Hi,
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}
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.
In mail.err I see:
pamc[3608]: exec failed: Permission denied
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
Here are the relevant groups:
s1:~# grep dovecot /etc/group
secmail:x:119:postfix,spamd,dovecot
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
# OS: Linux 2.6.26-2-686 i686 Debian 6.0.6
base_dir: /var/run/dovecot/
protocols: imap imaps pop3s pop3
ssl_cert_file: /etc/ssl/certs/s1.troyvit.com.cert
ssl_key_file: /etc/ssl/private/s1.troyvit.com.key
ssl_cipher_list: ALL:!LOW
disable_plaintext_auth: no
verbose_ssl: yes
login_dir: /var/run/dovecot/login
login_executable(default): /usr/lib/dovecot/imap-login
login_executable(imap): /usr/lib/dovecot/imap-login
login_executable(pop3): /usr/lib/dovecot/pop3-login
mail_location: maildir:%h/Maildir/
mbox_write_locks: fcntl dotlock
mail_executable(default): /usr/lib/dovecot/imap
mail_executable(imap): /usr/lib/dovecot/imap
mail_executable(pop3): /usr/lib/dovecot/pop3
mail_plugin_dir(default): /usr/lib/dovecot/modules/imap
mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap
mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3
pop3_enable_last(default): no
pop3_enable_last(imap): no
pop3_enable_last(pop3): yes
pop3_client_workarounds(default):
pop3_client_workarounds(imap):
pop3_client_workarounds(pop3): outlook-no-nuls, oe-ns-eoh
pop3_logout_format(default): top=%t/%p, retr=%r/%b, del=%d/%m, size=%s
pop3_logout_format(imap): top=%t/%p, retr=%r/%b, del=%d/%m, size=%s
pop3_logout_format(pop3): top=%t/%T, retr=%r/%R, del=%d/%m, size=%s
namespace:
type: private
separator: /
inbox: yes
list: yes
subscriptions: yes
lda:
postmaster_address: postmaster@sphere.local
auth_socket_path: /var/run/dovecot/auth-master
mail_plugin_dir: /usr/lib/dovecot/modules/lda/
mail_plugins: sieve
auth default:
mechanisms: plain login
verbose: yes
debug: yes
debug_passwords: yes
passdb:
driver: pam
args: dovecot
passdb:
driver: sql
args: /etc/dovecot/dovecot-sql.conf
userdb:
driver: passwd
userdb:
driver: sql
args: /etc/dovecot/dovecot-sql.conf
socket:
type: listen
client:
path: /var/spool/postfix/private/auth
mode: 432
user: postfix
group: postfix
master:
path: /var/run/dovecot/auth-master
mode: 438
user: dovecot
plugin:
sieve_global_path: /etc/dovecot/default.sieve
sieve: /srv/%d/mail/%n/%n.sieve
Many thanks in advance for any advice you can give.
Troy
What is your mailbox_command in main.cf? I just use:
mailbox_command = /usr/bin/spamc -u $USER -e
/usr/lib64/dovecot/deliver -a $RECIPIENT -f $SENDER -m $EXTENSION
I don't need anything in master.cf. But you should be using -u ${user}
for spamc.
Bill
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On 10/23/2012 9:06 PM, Bill Shirley wrote:
On 10/23/2012 4:52 PM, Troy Vitullo wrote:
Hi,
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}
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.
In mail.err I see:
pamc[3608]: exec failed: Permission denied
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
Here are the relevant groups:
s1:~# grep dovecot /etc/group
secmail:x:119:postfix,spamd,dovecot
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
# OS: Linux 2.6.26-2-686 i686 Debian 6.0.6
base_dir: /var/run/dovecot/
protocols: imap imaps pop3s pop3
ssl_cert_file: /etc/ssl/certs/s1.troyvit.com.cert
ssl_key_file: /etc/ssl/private/s1.troyvit.com.key
ssl_cipher_list: ALL:!LOW
disable_plaintext_auth: no
verbose_ssl: yes
login_dir: /var/run/dovecot/login
login_executable(default): /usr/lib/dovecot/imap-login
login_executable(imap): /usr/lib/dovecot/imap-login
login_executable(pop3): /usr/lib/dovecot/pop3-login
mail_location: maildir:%h/Maildir/
mbox_write_locks: fcntl dotlock
mail_executable(default): /usr/lib/dovecot/imap
mail_executable(imap): /usr/lib/dovecot/imap
mail_executable(pop3): /usr/lib/dovecot/pop3
mail_plugin_dir(default): /usr/lib/dovecot/modules/imap
mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap
mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3
pop3_enable_last(default): no
pop3_enable_last(imap): no
pop3_enable_last(pop3): yes
pop3_client_workarounds(default):
pop3_client_workarounds(imap):
pop3_client_workarounds(pop3): outlook-no-nuls, oe-ns-eoh
pop3_logout_format(default): top=%t/%p, retr=%r/%b, del=%d/%m, size=%s
pop3_logout_format(imap): top=%t/%p, retr=%r/%b, del=%d/%m, size=%s
pop3_logout_format(pop3): top=%t/%T, retr=%r/%R, del=%d/%m, size=%s
namespace:
type: private
separator: /
inbox: yes
list: yes
subscriptions: yes
lda:
postmaster_address: postmaster@sphere.local
auth_socket_path: /var/run/dovecot/auth-master
mail_plugin_dir: /usr/lib/dovecot/modules/lda/
mail_plugins: sieve
auth default:
mechanisms: plain login
verbose: yes
debug: yes
debug_passwords: yes
passdb:
driver: pam
args: dovecot
passdb:
driver: sql
args: /etc/dovecot/dovecot-sql.conf
userdb:
driver: passwd
userdb:
driver: sql
args: /etc/dovecot/dovecot-sql.conf
socket:
type: listen
client:
path: /var/spool/postfix/private/auth
mode: 432
user: postfix
group: postfix
master:
path: /var/run/dovecot/auth-master
mode: 438
user: dovecot
plugin:
sieve_global_path: /etc/dovecot/default.sieve
sieve: /srv/%d/mail/%n/%n.sieve
Many thanks in advance for any advice you can give.
Troy
What is your mailbox_command in main.cf? I just use:
mailbox_command = /usr/bin/spamc -u $USER -e
/usr/lib64/dovecot/deliver -a $RECIPIENT -f $SENDER -m $EXTENSION
I don't need anything in master.cf. But you should be using -u
${user} for spamc.
Bill
Forgot to ask, are you using Spamassassin's per-user configs? If you're
not, that probably is your problem. It's probably trying to update
bayes tokens and it doesn't have permission.
I use per-user configs which are nice. One man's spam is another man's
ham. Plus each user can have his/her own whitelist.
I use these spamd args: -d -c -m10 --user-config
You usually can find the args in /etc/sysconfig.
Bill
