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