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

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

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

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

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

Am 24.10.2012 22:04, schrieb Bill Shirley:

On 10/24/2012 2:24 PM, Robert Schetterer wrote:

...

...

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?

Am 24.10.2012 19:21, schrieb Bill Shirley: 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

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

On 10/24/2012 12:10 PM, Troy Vitullo wrote:

On Tue, 23 Oct 2012 21:32:59 -0400 Bill Shirley Bill@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 vmail 24014 0.0 0.9 161204 75880 ? SN Oct23 0:05 spamd child vmail 24015 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/4 S+ 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 /home/bill drwxr-s--- 2 bill bill 4096 Oct 24 12:42 /home/bill/.spamassassin

My main.cf: mailbox_transport = 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

My master.cf: vdovecot unix - 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}

You could try my config substituting your user and directory for mine: I'm using user=vmail:vmail and --virtual-config-dir=/home/vmail/domains/%d/%l/.spamassassin You're using user=dovecot:secmail and --virtual-config-dir=/var/lib/spamassassin/users/%d/%l

Currently, your user=dovecot:secmail should probably be user=spamd:spamd in master.cf unless group secmail has write permissions on /var/lib/spamassassin and subdirectories.

Hope this helps, Bill

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

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

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

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