[Dovecot] Some questions about deliver

[Timo Sirainen]

On Tue, 2009-05-26 at 14:35 +0200, Axel Luttgens wrote:
>      postfix/local[8643]: 1AFE4CA5D97: to=<www at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20090528/895a2c9f/attachment.bin