Mailing List Archive

On Mon, Feb 02, 2004 at 02:54:33PM -0000, Aaron Stone wrote:
>
> So following up on the issue of return codes from dbmail-smtp, I'm looking
> around on the 'net for any documentation about any standards for return codes,
> perhaps de facto standards (e.g. whatever procmail uses). Best I came up with
> was the suggestion to use codes contained in /usr/include/sysexits.h. Seems
> like a pretty good list of codes. Anyone know of anything better?

By default, Exim treats EX_TEMPFAIL and EX_CANTCREAT as temporary
failures and any other non-zero return codes as permanent failures.
These are the two return codes that procmail uses.

http://www.exim.org/exim-html-4.30/doc/html/spec_29.html#IX2015

I also read that Procmail will read up to 4K of output from the pipe delivery
process and will mail that back to the sender.

Do we prefer our current internal handling of bounces, or should we switch to
using the MTA for this kind of dirty work?

Also, if Exim only support EX_CANTCREAT and EX_TEMPFAIL, and treats them in
the same way, how do we propose to support EX_NOUSER and the like? Is it the
correct behaviour for us to return EX_NOUSER if there's no such user and let
Exim handle the rest, generating a permanent message delivery failure?

Notably absent from the list of return codes is something like "EX_OVERQUOT"
for an over-quota situation. Should that be a permanent or a temporary
failure? (i.e. should we use EX_CANTCREAT if there's "no space to create?")

Aaron


""Christian G. Warden"" <xndbmail@xerus.org> said:

> On Mon, Feb 02, 2004 at 02:54:33PM -0000, Aaron Stone wrote:
> >
> > So following up on the issue of return codes from dbmail-smtp, I'm looking
> > around on the 'net for any documentation about any standards for return codes,
> > perhaps de facto standards (e.g. whatever procmail uses). Best I came up with
> > was the suggestion to use codes contained in /usr/include/sysexits.h. Seems
> > like a pretty good list of codes. Anyone know of anything better?
>
> By default, Exim treats EX_TEMPFAIL and EX_CANTCREAT as temporary
> failures and any other non-zero return codes as permanent failures.
> These are the two return codes that procmail uses.
>
> http://www.exim.org/exim-html-4.30/doc/html/spec_29.html#IX2015
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>

--

On Mon, Feb 02, 2004 at 04:11:04PM -0000, Aaron Stone wrote:
> I also read that Procmail will read up to 4K of output from the pipe delivery
> process and will mail that back to the sender.
>
> Do we prefer our current internal handling of bounces, or should we switch to
> using the MTA for this kind of dirty work?

I think it's best for the MTA to handle bounces. In my setup, I only
pass mail to dbmail that can be delivered. I do alias expansion and
recipient verification in Exim.

> Also, if Exim only support EX_CANTCREAT and EX_TEMPFAIL, and treats them in
> the same way, how do we propose to support EX_NOUSER and the like? Is it the
> correct behaviour for us to return EX_NOUSER if there's no such user and let
> Exim handle the rest, generating a permanent message delivery failure?

Yes, I'd put the responsibility on the MTA. If the MTA can only handle
temporary versus permanent failures, you'll still get the appropriate
action, but a bounce message might not be as informative as it could be.

> Notably absent from the list of return codes is something like "EX_OVERQUOT"
> for an over-quota situation. Should that be a permanent or a temporary
> failure? (i.e. should we use EX_CANTCREAT if there's "no space to create?")

I'd say over-quota is a temporary condition. I haven't used dbmail's
quotas yet. Does it inject an over-quota message directly into the
user's INBOX, bypassing quota restrictions?

xn

Hi Christian,

> > Do we prefer our current internal handling of bounces, or should we switch to
> > using the MTA for this kind of dirty work?
>
> I think it's best for the MTA to handle bounces. In my setup, I only
> pass mail to dbmail that can be delivered. I do alias expansion and
> recipient verification in Exim.

Yes I agree, the MTA should do that. It doesn't matter if exim or dbmail
does the alias expansion I think.

> > Also, if Exim only support EX_CANTCREAT and EX_TEMPFAIL, and treats them in
> > the same way, how do we propose to support EX_NOUSER and the like? Is it the
> > correct behaviour for us to return EX_NOUSER if there's no such user and let
> > Exim handle the rest, generating a permanent message delivery failure?
>
> Yes, I'd put the responsibility on the MTA. If the MTA can only handle
> temporary versus permanent failures, you'll still get the appropriate
> action, but a bounce message might not be as informative as it could be.

As far as I know one of the big advantages of using lmtp is that the MTA
can get speaking error messages.

I have exim 3 and Cyrus 2.1 with lmtp running. If I write a mail to a not
existing user I get a bounce back:

----------------------------------------------------------------------
This message was created automatically by mail delivery software (Exim).

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

blub@tmueller.com
LMTP error after RCPT TO:<blub@tmueller.com>: 550-Mailbox unknown. Either there is no mailbox associated with this
550-name or you do not have authorization to see it.
550 5.1.1 User unknown

------ This is a copy of the message, including all the headers. ------
[.. Headers and some KB of the message ..]
----------------------------------------------------------------------

Before I switched to lmtp I only got 'failed' messages without a reason.

That's the way dbmail should handle bounces too I think.


--
MfG Thomas Mueller - http://www.tmueller.com for pgp key (95702B3B)

The error codes from sysexits.h is the most logical and consistent ones to use. I was looking about, and found this list of exit codes sendmail uses.

Here's the full list of translations sendmail does between the RFC 3463 DSN values and exit codes:
2.*.* EX_OK Successful delivery
4.*.* EX_TEMPFAIL Temporary failure, will keep trying
*.0.* EX_UNAVAILABLE Other address status
*.1.0 EX_DATAERR Other address status
*.1.1 EX_NOUSER Address is that of a bad mailbox 4 (ambiguous address).
*.1.2 EX_NOHOST Address of recipient is bad
*.1.3 EX_USAGE Address of recipient has bad syntax
*.1.4 EX_UNAVAILABLE Address is ambiguous
*.1.5 EX_CONFIG Address of destination is valid
*.1.6 EX_NOUSER Address has moved, no forwarding
*.1.7 EX_USAGE Address of sender has bad syntax
*.1.8 EX_NOHOST Address of sender is bad
*.2.0 EX_UNAVAILABLE Mailbox status is undefined
*.2.1 EX_UNAVAILABLE Mailbox disabled
*.2.2 EX_UNAVAILABLE Mailbox full
*.2.3 EX_DATAERR Mailbox is too small or message is too large
*.2.4 EX_UNAVAILABLE Mailbox led to mail list expansion problems
*.3.* EX_OSERR Operating system error
*.4.0 EX_IOERR Network error is undefined
*.4.1 EX_TEMPFAIL Network: no answer from host
*.4.2 EX_IOERR Network bad connection
*.4.3 EX_TEMPFAIL Network routing failure
*.4.4 EX_PROTOCOL Network unable to route
*.4.5 EX_TEMPFAIL Network congestion
*.4.6 EX_CONFIG Network routing loop detected
*.4.7 EX_UNAVAILABLE Network delivery time expired
*.5.* EX_PROOCOL protocol failure
*.6.* EX_UNAVAILABLE message contents bad, or media failure
*.7.* EX_DATAERR Security: general security rejection
5.*.* EX_UNAVAILABLE any recognized 5.y.z code
*.*.* EX_CONFIG any other unrecognized code

these are done on a first match basis, so the final *.*.* is the default exit code.

Note, sendmail uses EX_DATAERR to deal report problems with quotas. To quote sysexits(3)
BUGS
The choice of an appropriate exit value is often ambiguous.

EX_DATAERR is possible more appropiate than EX_CANTCREAT since it's not that dbmail can't create the entry, it's that dbmail chooses not to create it.

I would expect the MTA should do the reporting rather than dbmail itself. Even now, there's a bug in the dbmail 1.2.3 which causes some bounces not to be sent, due to an incorrect invocation of sendmail. If the bouncing had been left to the MTA, this would not have arisen.
If the MTA doesn't recognise and report the errors it's given, it has no business being an MTA.

What should be of more priority would be making sure error messages in the output conform to RFCs 1893 and 3463. It should be up to the MTA to decide how to convey that error back to the sender.

-fr.

On Mon, 2 Feb 2004 16:11:04 -0000
"Aaron Stone" <aaron@serendipity.palo-alto.ca.us> wrote:

> I also read that Procmail will read up to 4K of output from the pipe delivery
> process and will mail that back to the sender.
>
> Do we prefer our current internal handling of bounces, or should we switch to
> using the MTA for this kind of dirty work?
>
> Also, if Exim only support EX_CANTCREAT and EX_TEMPFAIL, and treats them in
> the same way, how do we propose to support EX_NOUSER and the like? Is it the
> correct behaviour for us to return EX_NOUSER if there's no such user and let
> Exim handle the rest, generating a permanent message delivery failure?
>
> Notably absent from the list of return codes is something like "EX_OVERQUOT"
> for an over-quota situation. Should that be a permanent or a temporary
> failure? (i.e. should we use EX_CANTCREAT if there's "no space to create?")
>
> Aaron
>
>
> ""Christian G. Warden"" <xndbmail@xerus.org> said:
>
> > On Mon, Feb 02, 2004 at 02:54:33PM -0000, Aaron Stone wrote:
> > >
> > > So following up on the issue of return codes from dbmail-smtp, I'm looking
> > > around on the 'net for any documentation about any standards for return codes,
> > > perhaps de facto standards (e.g. whatever procmail uses). Best I came up with
> > > was the suggestion to use codes contained in /usr/include/sysexits.h. Seems
> > > like a pretty good list of codes. Anyone know of anything better?
> >
> > By default, Exim treats EX_TEMPFAIL and EX_CANTCREAT as temporary
> > failures and any other non-zero return codes as permanent failures.
> > These are the two return codes that procmail uses.
> >
> > http://www.exim.org/exim-html-4.30/doc/html/spec_29.html#IX2015
> > _______________________________________________
> > Dbmail-dev mailing list
> > Dbmail-dev@dbmail.org
> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >
>
> --
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>

You da man! This is exactly what I was hoping to find :-)

So perhaps insert_messages() should return a "struct DSN status" that is
translated as appropriate by the caller. If the caller is LMTP, then the codes
are sent out along along descriptive text. If the caller is "SMTP" / pipe,
then the codes are translated into exit codes as below, and perhaps with an
extended message on stdout so that Postfix (maybe others?) can put that
message into the bounce.

Ilja, I'm going to work up a patch for this support, but won't have much free
time until Thursday afternoon. Do you mind holding off rc2 for this patch?

struct dsn_status {
int class;
int subject;
int detail;
}

Maybe have a const char * in there to hold a pointer to the error text? Or
perhaps a translation function that has all of the errors in a lookup table.
That would also make it easier to internationalize with gettext at some
point... I'll think about it this week and do the patch on Thursday!

Aaron


Feargal Reilly <feargal@chrysalink.net> said:

> The error codes from sysexits.h is the most logical and consistent ones to
use. I was looking about, and found this list of exit codes sendmail uses.
>
> Here's the full list of translations sendmail does between the RFC 3463 DSN
values and exit codes:
> 2.*.* EX_OK Successful delivery
> 4.*.* EX_TEMPFAIL Temporary failure, will keep trying
> *.0.* EX_UNAVAILABLE Other address status
> *.1.0 EX_DATAERR Other address status
> *.1.1 EX_NOUSER Address is that of a bad mailbox 4 (ambiguous address).
> *.1.2 EX_NOHOST Address of recipient is bad
> *.1.3 EX_USAGE Address of recipient has bad syntax
> *.1.4 EX_UNAVAILABLE Address is ambiguous
> *.1.5 EX_CONFIG Address of destination is valid
> *.1.6 EX_NOUSER Address has moved, no forwarding
> *.1.7 EX_USAGE Address of sender has bad syntax
> *.1.8 EX_NOHOST Address of sender is bad
> *.2.0 EX_UNAVAILABLE Mailbox status is undefined
> *.2.1 EX_UNAVAILABLE Mailbox disabled
> *.2.2 EX_UNAVAILABLE Mailbox full
> *.2.3 EX_DATAERR Mailbox is too small or message is too large
> *.2.4 EX_UNAVAILABLE Mailbox led to mail list expansion problems
> *.3.* EX_OSERR Operating system error
> *.4.0 EX_IOERR Network error is undefined
> *.4.1 EX_TEMPFAIL Network: no answer from host
> *.4.2 EX_IOERR Network bad connection
> *.4.3 EX_TEMPFAIL Network routing failure
> *.4.4 EX_PROTOCOL Network unable to route
> *.4.5 EX_TEMPFAIL Network congestion
> *.4.6 EX_CONFIG Network routing loop detected
> *.4.7 EX_UNAVAILABLE Network delivery time expired
> *.5.* EX_PROOCOL protocol failure
> *.6.* EX_UNAVAILABLE message contents bad, or media failure
> *.7.* EX_DATAERR Security: general security rejection
> 5.*.* EX_UNAVAILABLE any recognized 5.y.z code
> *.*.* EX_CONFIG any other unrecognized code
>
> these are done on a first match basis, so the final *.*.* is the default
exit code.
>
> Note, sendmail uses EX_DATAERR to deal report problems with quotas. To quote
sysexits(3)
> BUGS
> The choice of an appropriate exit value is often ambiguous.
>
> EX_DATAERR is possible more appropiate than EX_CANTCREAT since it's not that
dbmail can't create the entry, it's that dbmail chooses not to create it.
>
> I would expect the MTA should do the reporting rather than dbmail itself.
Even now, there's a bug in the dbmail 1.2.3 which causes some bounces not to
be sent, due to an incorrect invocation of sendmail. If the bouncing had been
left to the MTA, this would not have arisen.
> If the MTA doesn't recognise and report the errors it's given, it has no
business being an MTA.
>
> What should be of more priority would be making sure error messages in the
output conform to RFCs 1893 and 3463. It should be up to the MTA to decide how
to convey that error back to the sender.
>
> -fr.
>
> On Mon, 2 Feb 2004 16:11:04 -0000
> "Aaron Stone" <aaron@serendipity.palo-alto.ca.us> wrote:
>
> > I also read that Procmail will read up to 4K of output from the pipe delivery
> > process and will mail that back to the sender.
> >
> > Do we prefer our current internal handling of bounces, or should we switch to
> > using the MTA for this kind of dirty work?
> >
> > Also, if Exim only support EX_CANTCREAT and EX_TEMPFAIL, and treats them in
> > the same way, how do we propose to support EX_NOUSER and the like? Is it the
> > correct behaviour for us to return EX_NOUSER if there's no such user and let
> > Exim handle the rest, generating a permanent message delivery failure?
> >
> > Notably absent from the list of return codes is something like "EX_OVERQUOT"
> > for an over-quota situation. Should that be a permanent or a temporary
> > failure? (i.e. should we use EX_CANTCREAT if there's "no space to create?")
> >
> > Aaron
> >
> >
> > ""Christian G. Warden"" <xndbmail@xerus.org> said:
> >
> > > On Mon, Feb 02, 2004 at 02:54:33PM -0000, Aaron Stone wrote:
> > > >
> > > > So following up on the issue of return codes from dbmail-smtp, I'm looking
> > > > around on the 'net for any documentation about any standards for
return codes,
> > > > perhaps de facto standards (e.g. whatever procmail uses). Best I came
up with
> > > > was the suggestion to use codes contained in /usr/include/sysexits.h.
Seems
> > > > like a pretty good list of codes. Anyone know of anything better?
> > >
> > > By default, Exim treats EX_TEMPFAIL and EX_CANTCREAT as temporary
> > > failures and any other non-zero return codes as permanent failures.
> > > These are the two return codes that procmail uses.
> > >
> > > http://www.exim.org/exim-html-4.30/doc/html/spec_29.html#IX2015
> > > _______________________________________________
> > > Dbmail-dev mailing list
> > > Dbmail-dev@dbmail.org
> > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> > >
> >
> > --
> > _______________________________________________
> > Dbmail-dev mailing list
> > Dbmail-dev@dbmail.org
> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >
>
>



--

I just noticed this sentence in my mail:
Here's the full list of translations sendmail does between the RFC 3463 DSN values and exit codes:

Just to clarify, that's not be a complete list of DSN codes, you'll need to check the RFCs for that. But it should be a good starting point for providing sensible errors. I guess somebody will have to figure out which DSNs apply for things like database connection errors and the like.

-fr.

On Tue, 3 Feb 2004 20:18:39 -0000
"Aaron Stone" <aaron@serendipity.palo-alto.ca.us> wrote:

> You da man! This is exactly what I was hoping to find :-)
>
> So perhaps insert_messages() should return a "struct DSN status" that is
> translated as appropriate by the caller. If the caller is LMTP, then the codes
> are sent out along along descriptive text. If the caller is "SMTP" / pipe,
> then the codes are translated into exit codes as below, and perhaps with an
> extended message on stdout so that Postfix (maybe others?) can put that
> message into the bounce.
>
> Ilja, I'm going to work up a patch for this support, but won't have much free
> time until Thursday afternoon. Do you mind holding off rc2 for this patch?
>
> struct dsn_status {
> int class;
> int subject;
> int detail;
> }
>
> Maybe have a const char * in there to hold a pointer to the error text? Or
> perhaps a translation function that has all of the errors in a lookup table.
> That would also make it easier to internationalize with gettext at some
> point... I'll think about it this week and do the patch on Thursday!
>
> Aaron
>
>
> Feargal Reilly <feargal@chrysalink.net> said:
>
> > The error codes from sysexits.h is the most logical and consistent ones to
> use. I was looking about, and found this list of exit codes sendmail uses.
> >
> > Here's the full list of translations sendmail does between the RFC 3463 DSN
> values and exit codes:
> > 2.*.* EX_OK Successful delivery
> > 4.*.* EX_TEMPFAIL Temporary failure, will keep trying
> > *.0.* EX_UNAVAILABLE Other address status
> > *.1.0 EX_DATAERR Other address status
> > *.1.1 EX_NOUSER Address is that of a bad mailbox 4 (ambiguous address).
> > *.1.2 EX_NOHOST Address of recipient is bad
> > *.1.3 EX_USAGE Address of recipient has bad syntax
> > *.1.4 EX_UNAVAILABLE Address is ambiguous
> > *.1.5 EX_CONFIG Address of destination is valid
> > *.1.6 EX_NOUSER Address has moved, no forwarding
> > *.1.7 EX_USAGE Address of sender has bad syntax
> > *.1.8 EX_NOHOST Address of sender is bad
> > *.2.0 EX_UNAVAILABLE Mailbox status is undefined
> > *.2.1 EX_UNAVAILABLE Mailbox disabled
> > *.2.2 EX_UNAVAILABLE Mailbox full
> > *.2.3 EX_DATAERR Mailbox is too small or message is too large
> > *.2.4 EX_UNAVAILABLE Mailbox led to mail list expansion problems
> > *.3.* EX_OSERR Operating system error
> > *.4.0 EX_IOERR Network error is undefined
> > *.4.1 EX_TEMPFAIL Network: no answer from host
> > *.4.2 EX_IOERR Network bad connection
> > *.4.3 EX_TEMPFAIL Network routing failure
> > *.4.4 EX_PROTOCOL Network unable to route
> > *.4.5 EX_TEMPFAIL Network congestion
> > *.4.6 EX_CONFIG Network routing loop detected
> > *.4.7 EX_UNAVAILABLE Network delivery time expired
> > *.5.* EX_PROOCOL protocol failure
> > *.6.* EX_UNAVAILABLE message contents bad, or media failure
> > *.7.* EX_DATAERR Security: general security rejection
> > 5.*.* EX_UNAVAILABLE any recognized 5.y.z code
> > *.*.* EX_CONFIG any other unrecognized code
> >
> > these are done on a first match basis, so the final *.*.* is the default
> exit code.
> >
> > Note, sendmail uses EX_DATAERR to deal report problems with quotas. To quote
> sysexits(3)
> > BUGS
> > The choice of an appropriate exit value is often ambiguous.
> >
> > EX_DATAERR is possible more appropiate than EX_CANTCREAT since it's not that
> dbmail can't create the entry, it's that dbmail chooses not to create it.
> >
> > I would expect the MTA should do the reporting rather than dbmail itself.
> Even now, there's a bug in the dbmail 1.2.3 which causes some bounces not to
> be sent, due to an incorrect invocation of sendmail. If the bouncing had been
> left to the MTA, this would not have arisen.
> > If the MTA doesn't recognise and report the errors it's given, it has no
> business being an MTA.
> >
> > What should be of more priority would be making sure error messages in the
> output conform to RFCs 1893 and 3463. It should be up to the MTA to decide how
> to convey that error back to the sender.
> >
> > -fr.
> >
> > On Mon, 2 Feb 2004 16:11:04 -0000
> > "Aaron Stone" <aaron@serendipity.palo-alto.ca.us> wrote:
> >
> > > I also read that Procmail will read up to 4K of output from the pipe delivery
> > > process and will mail that back to the sender.
> > >
> > > Do we prefer our current internal handling of bounces, or should we switch to
> > > using the MTA for this kind of dirty work?
> > >
> > > Also, if Exim only support EX_CANTCREAT and EX_TEMPFAIL, and treats them in
> > > the same way, how do we propose to support EX_NOUSER and the like? Is it the
> > > correct behaviour for us to return EX_NOUSER if there's no such user and let
> > > Exim handle the rest, generating a permanent message delivery failure?
> > >
> > > Notably absent from the list of return codes is something like "EX_OVERQUOT"
> > > for an over-quota situation. Should that be a permanent or a temporary
> > > failure? (i.e. should we use EX_CANTCREAT if there's "no space to create?")
> > >
> > > Aaron
> > >
> > >
> > > ""Christian G. Warden"" <xndbmail@xerus.org> said:
> > >
> > > > On Mon, Feb 02, 2004 at 02:54:33PM -0000, Aaron Stone wrote:
> > > > >
> > > > > So following up on the issue of return codes from dbmail-smtp, I'm looking
> > > > > around on the 'net for any documentation about any standards for
> return codes,
> > > > > perhaps de facto standards (e.g. whatever procmail uses). Best I came
> up with
> > > > > was the suggestion to use codes contained in /usr/include/sysexits.h.
> Seems
> > > > > like a pretty good list of codes. Anyone know of anything better?
> > > >
> > > > By default, Exim treats EX_TEMPFAIL and EX_CANTCREAT as temporary
> > > > failures and any other non-zero return codes as permanent failures.
> > > > These are the two return codes that procmail uses.
> > > >
> > > > http://www.exim.org/exim-html-4.30/doc/html/spec_29.html#IX2015
> > > > _______________________________________________
> > > > Dbmail-dev mailing list
> > > > Dbmail-dev@dbmail.org
> > > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> > > >
> > >
> > > --
> > > _______________________________________________
> > > Dbmail-dev mailing list
> > > Dbmail-dev@dbmail.org
> > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> > >
> >
> >
>
>
>
> --
>
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>