On Tue, 2009-05-26 at 14:35 +0200, Axel Luttgens wrote:
postfix/local[8643]: 1AFE4CA5D97: to=<www@almbp.local>,relay=local, delay=0.08, delays=0.01/0.01/0/0.06, dsn=5.2.0,
status=bounced (cannot update mailbox /Library/WebServer/_inbox/ mailspool for user www. unable to create lock file /Library/WebServer/ _inbox/mailspool.lock: No such file or directory)
That looks like a server configuration mistake.
So, Postfix' default behavior is to bounce the message; strictly
speaking, deliver can't thus be viewed as a transparent substitute.
If I was running a mail server, I'd prefer Postfix not to bounce the message in that situation.
At least, it would be nice to have a very precise description of how
deliver is supposed to behave when facing various conditions. This would then be a documentation matter.
Maybe.. Although it can be summarized pretty easily:
- Invalid command line parameter gives EX_USAGE
- Invalid configuration gives EX_CONFIG
- User-over-quota optionally bounces or exits with EX_NOPERM
- Anything else is EX_TEMPFAIL.
Anyway, let's consider this (stupid) one:
mailbox_command = /usr/local/dovecot/libexec/dovecot/deliver -e -n -x
Here, deliver immediately returns with EX_USAGE and, by default,
Postix will reject the message; but this is something I could have
noticed and fixed in the meantime.
It could be argued that Postfix shouldn't be bouncing the message. :) EX_USAGE is meant exactly for that error, so I don't think it's a good idea for deliver to fail with EX_TEMPFAIL just to work around a Postfix issue.
On the other hand, it could also be argued that an over-quota
recipient is fixable as well: just pick the phone and ask the
recipient to clean his mailbox. And one could thus conclude that
deliver's default behavior isn't the right one...
The difference is that over-quota can be caused by a user. Configuration mistakes can't be caused by a user. Dovecot in general uses this logic in writing errors. Users can't (well, shouldn't) ever cause Dovecot to log warnings/errors.
And BTW, is that function guaranteed to be always called with an EX_* value? Seems to be the case, but... ;-)
What do you mean? It's called with FATAL_* values and it replaces them with EX_TEMPFAIL.
Sorry, some kind of mental short circuit occurred here; I meant:
"guaranteed to always return with status set to an EX_* value?".
Pretty much, yes.
I asked because of the default case in failure_exit_callback(), which
just returns and leaves status as it was on entry. Conceptually, one
could thus enter and leave the function with status set to a value
differing from one of the FATAL_* and the EX_*, that value being
ultimately returned to the caller. May this happen in practice? If
yes, when and which values?
The code looks like that to allow some future code change or plugin to exit with other values. Currently it never happens. But note that all the i_fatal_status(EX_USAGE, ..) etc. calls also go through that failure_exit_callback(). So it can't convert everything to EX_TEMPFAIL anyway, it would have to catch the used EX_* values at least.