> >Yes, I extracted the list from the RFC and posted it back then. However,
> >it seems to me  that LISTSERV should be able to look  up the status code
> >in a table and display a reasonable explanation.
>
> But there are a zillion of these codes, and more will be added regularly.
> And the  same code can mean  different things in different  contexts. The
> mailer reporting the  error is supposed to provide an  error message that
> can be  echoed back to  a human reader and  that is more  meaningful than
> "5.4.4 Unable  to route"  or "5.4.5 Network  congestion" (no  kidding?) A
> mailer that  just says "5.4.4"  with no  further information is  not very
> different from a mailer that says "unknown imail error 21". In both cases
> you can look up the error code in a semi-standard list of meanings and in
> both cases I would delete the subscriber  on the grounds of having a mail
> system that sends messages that I don't understand.
>
>   Eric
 
I find a lot to disagree with here:
 
(1) I count 57 codes, which is a fair number, but not quite what
I would consider a "zillion".  That's exclusive of the first
number, which is independent of the others and indicates
"success", "persistent transient failure", or "permanent
failure".  They wouldn't make a that big a table.
 
(2) The notary codes are described in RFC 1893, a standards-track
RFC.  This is not a "semi-standard list of codes."  New codes are
to be added only by other standards track RFCs, not made up by
implementors.  Anyway, not understanding some new code is not a
justification for not providing an explanation of the codes you
do understand.
 
(3) I don't understand why you say that the same code can mean
different things in different contexts.
 
(4) The Status field of a DSN (Delivery Status Notification),
defined in RFC 1894 (also standards-track), does not require
error message text.  A comment may be provided, but it is not
required.  The codes were intended to allow descriptions to be
provided in different languages by the program receiving the DSN.
 
(5) The first section of the multipart/report structure used for
DSNs is available for a text description of the error.  This is
for users whose systems don't understand DSNs.  LISTSERV discards
this section in Auto-delete processing.
 
(6) You shouldn't just say "5.4.5 Network Congestion".  It should
at least be "5.4.5 Permanent error, network congestion" or, more
likely, "4.4.5 Persistent transient error, network congestion".
But RFC 1893 contains longer descriptions of the meaning of the
codes and you are free to use those or reword them.
 
(7) The question about what the codes mean has been asked several
times on this list.  People want to know without having to
consult RFC 1893.
 
Here are some relevant quotes from the RFCs:
 
RFC 1894
 
2.3.4 Status field
 
   The per-recipient Status field contains a transport-independent
   status code which indicates the delivery status of the message to
   that recipient.  This field MUST be present for each delivery attempt
   which is described by a DSN.
 
   The syntax of the status field is:
 
     status-field = "Status" ":" status-code
 
     status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT
 
          ; White-space characters and comments are NOT allowed within a
          ; status-code, though a comment enclosed in parentheses MAY follow
          ; the last numeric subfield of the status-code.  Each numeric
          ; subfield within the status-code MUST be expressed without
          ; leading zero digits.
 
   Status codes thus consist of three numerical fields separated by ".".
   The first sub-field indicates whether the delivery attempt was
   successful (2 = success, 4 = persistent temporary failure, 5 =
   permanent failure).  The second sub-field indicates the probable
   source of any delivery anomalies, and the third sub-field denotes a
   precise error condition, if known.
 
   The initial set of status-codes is defined in [5].
 
RFC 1893
 
   Status codes consist of three numerical fields separated by ".". The
   first sub-code indicates whether the delivery attempt was successful.
   The second sub-code indicates the probable source of any delivery
   anomalies, and the third sub-code indicates a precise error
   condition.
 
   The codes space defined is intended to be extensible only by
   standards track documents.  Mail system specific status codes should
   be mapped as close as possible to the standard status codes.  Servers
   should send only defined, registered status codes.  System specific
   errors and diagnostics should be carried by means other than status
   codes.
 
   New subject and detail codes will be added over time.  Because the
   number space is large, it is not intended that published status codes
   will ever be redefined or eliminated.  Clients should preserve the
   extensibility of the code space by reporting the general error
   described in the subject sub-code when the specific detail is
   unrecognized.