> >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.
|