While investigating Dovecot's deliver with Postfix, I encountered some
behaviors making me wonder whether I really understand the purpose of
that binary. So, if you allow...
This is from Postfix' main.cf:
mailbox_command = /usr/local/dovecot/libexec/dovecot/deliver -e -nThis is my quick setup for Dovecot:
# 1.2.rc4: /usr/local/etc/dovecot.conf
# OS: Darwin 9.7.0 i386
protocols: pop3
ssl: no
disable_plaintext_auth: no
login_dir: /usr/local/var/run/dovecot/login
login_executable: /usr/local/dovecot-1.2.rc4/libexec/dovecot/pop3- login first_valid_uid: 2001 mail_location: mbox:~/_mailboxes:INBOX=~/_inbox/mailspool mbox_read_locks: flock mbox_write_locks: flock dotlock mail_executable: /usr/local/dovecot-1.2.rc4/libexec/dovecot/pop3 mail_plugin_dir: /usr/local/dovecot-1.2.rc4/lib/dovecot/pop3 pop3_lock_session: yes pop3_uidl_format: %08Xv%08Xu auth default: passdb: driver: pam args: * userdb: driver: passwd
Here is an excerpt from mail.log:
postfix/smtpd[4117]: connect from localhost[127.0.0.1]
postfix/smtpd[4117]: 163E1CA2675: client=localhost[127.0.0.1]
postfix/cleanup[4120]: 163E1CA2675: message-id=<27002A3F-AF44-410D-A500-368D04F5FA9A@almbp.local >
postfix/qmgr[3232]: 163E1CA2675: from=<testuser@almbp.local>,
size=2650, nrcpt=1 (queue active)
dovecot[4129]: deliver(www): mail_location: mbox: mkdir(/Library/
WebServer/_mailboxes) failed: Permission denied (euid=70(_www)
egid=70(_www) missing +w perm: /Library/WebServer)
dovecot[4129]: deliver(www): Fatal: Namespace initialization failed
postfix/local[4122]: 163E1CA2675: to=<www@almbp.local>,
relay=local, delay=0.09, delays=0.02/0/0/0.07, dsn=4.3.0,
status=deferred (temporary failure)
postfix/smtpd[4117]: disconnect from localhost[127.0.0.1]
- Shouldn't deliver honor the first_valid_uid setting?
After all, if some user isn't allowed to login, is that user supposed
to receive mail?
- What exactly is the -e option supposed to do?
User _www clearly isn't configured for receiving mail, but Postfix
will nevertheless try to deliver the message until
maximal_queue_lifetime has expired.
From the log excerpt, it appears that Postfix has been led to
consider a temporary failure; unless I'm wrong, that's because Postfix
didn't receive neither a "D.S.N text" string nor an EX_* fatal return
code.
From deliver.c, it seems that many calls to i_fatal() are liable to
be executed before the -e option is taken into account (through the
local variable stderr_rejection).
As a result, I'm wondering under which circumstances exactly deliver
is liable to return EX_NOPERM, so that Postfix may consider a
permanent failure and bounce the message.
Note that the question may somehow be re-phrased as: when invoked
without the -e option, under which circumstances will deliver send a
rejection message?
- Doesn't failure_exit_callback() in deliver.c tend to merge many
(possibly dissimilar) errors into the single EX_TEMPFAIL one?
And BTW, is that function guaranteed to be always called with an EX_*
value? Seems to be the case, but... ;-)
TIA for your patience, Axel