Then I guess I think the whole premise of these status codes is brain
dead :-) There are just too many operating systems, too many mail
protocols, too many proprietary packages to gateway to that one can
reasonably hope to make a list of 53 error codes that, without any
additional textual info (beyond the failing address and so on) are
sufficient to describe (say) 99% of errors with enough accuracy as to be
an improvement over the previous method (SMTP status code + textual
description). In my opinion, status codes (and I agree by the way that
the SMTP list was too restrictive) should be something that you use to
clue in a computer at the other end as to what can/should be done about
the error. In *some* cases, the status code may even be sufficient to
deliver a comprehensive description of the error ("No such user at this
host", there isn't much more you can say). But in *most* cases, they are
just too vague and too generic. In other words, these codes are perfect
to tell LISTSERV what to do with the bounces, but once LISTSERV has
decided to forward a particular bounce to a human person, these codes
just aren't sufficient to diagnose the problem. I appreciate that most of
the MTAs that have implemented DSN still include the old-format bounce in
the comment/textual section of the DSN, and thus the information is
usually still there, but this isn't good enough. The new format should
contain all the necessary information even for brand new MTAs that don't
have an old format bounce text included for compatibility. MUAs or
LISTSERV should be able to make a summary of errors for the list owner
without having to include the whole prelude because this is the only
place where details are to be found in practice (when in fact this should
just contain the usual "This message is in MIME format, if your mail
program doesn't know, blah blah blah"). This wouldn't be a summary any
longer, given the size of these preludes, and the only thing I really
want is the text after the SMTP status code, but should I have to scan a
free-form comment section for SMTP status codes when I'm reading a bounce
in a format which was specifically designed to be computer parseable?
What, in other words, is the rationale for NOT systematically providing
the traditional textual description in "Diagnostic-Code:" (or in a new
field, it doesn't really matter)?
Eric
|