[Dovecot] What permanent errors a MDA may encounter? (was Re: PATCH: sendmail-like DSNs in Dovecot deliver (EX_TEMPFAIL always))

Steffen Kaiser skdovecot at smail.inf.fh-bonn-rhein-sieg.de
Thu May 10 16:19:31 EEST 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 9 May 2007, Matthias Andree wrote:

> Steffen Kaiser schrieb:
>> I've put together an always tempfail & sendmail-like DSN report back patch.
>>
>> Because I don't know how to transform the rejection reason into
>> sysexit.h codes, it always tempfails.
>
> Just read /usr/include/sysexits.h and pick the best fit, such as
> EX_NOPERM. 8-)

Well, it's not that easy:

a) there are approx 90 calls to mail_storage_set_error()
b) there is one call to mail_storage_set_syntax_error()
c) calls to mail_storage_set_internal_error() or 
mail_storage_set_critical() -- they set tempfail, but otherwise add a 
"INTERNAL FAILURE" message string.

Some use a fixed string error description, some use a generic one: "%s".

I do not find myself able to wead out the proper sysexit code for them, at 
least not currently.

Actually, it would be cool, if mail_storage_set_error() would differ 
between temp and permanent failures, e.g. for:

static int quota_check(struct mailbox_transaction_context *t, struct mail 
*mail)
{
         ret = quota_try_alloc(qt, mail, &too_large);
         if (ret > 0)
                 return 0;
         else if (ret == 0) {
                 mail_storage_set_error(t->box->storage, "Quota exceeded");

and to pass the appropriate sysexit code.

Probably, if the MTA delivers a mail to a local user, there is just one 
_permanent_ error possible at all:

 	the Sieve script discards the mail.

This is the only permanent error, I can think of, the MTA may not foresee, 
all others could be thought of as temporary, because there must be some 
misconfiguration and the problem needs treatment. After that the message 
can be delivered successfully or get bounced, e.g. initiated by the admin. 
Some conditions, e.g. out of quota, no treatment by the admin is possible 
/ doable, hence, the queue return timeout kicks in or the user perform the 
treatment self.

If this assumption helds. it would be as simple as have
mail_storage_clear_error(storage);
sets temporary_failure always and add a new function 
mail_storage_set_perm_error() that resets the flag - and adds a sysexit 
value ;-) Maybe, change temporary_error into sysexit value, which is 
EX_TEMPFAIL by default.

Bye,

- -- 
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBRkMb5y9SORjhbDpvAQKQrQf9FO2rFZbz2LVpNzuYZArvEaqv0ZMyggUM
5VaIowin5nGeHw9bgJrOANNcOJgyDqccEvQGNxhRY0c/nDn2qwvok4Widt8Lug7M
DBtSxyNOSC8dgmp+F6JDVrMG9Vwhk/48NRYwQNbb11eci4A1vpU49vak2L86ABBB
aeBt0Q7DfTgrGeWu79AKewlmJI/RbdjbwxcpravPet3QzEbcoT7TVVP8j4vTcW9r
xSVjdcn5YdBiBVoCk4WA4wJFUQ4RqsTwU5Dnw41MuzbwhT6SHVKk/psEZzpGGQDU
FuFqbNrcUba3SQMG/2a3bnfhAMmFKnhpvUFvXCfkjNMWaakVLGmN4Q==
=mt6P
-----END PGP SIGNATURE-----


More information about the dovecot mailing list