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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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"" <[EMAIL PROTECTED]> 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
>
pgpPItlPdCegB.pgp
Description: PGP signature
