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