On Thu, 9 Jan 1997 23:34:44 EST Roger Fajman <[log in to unmask]> said: >(2) The notary codes are described in RFC 1893, a standards-track >RFC. This is not a "semi-standard list of codes." What I meant is that these codes are similar in nature to the SMTP reply codes. If you look in the RFC, you will find (just taking a few common examples, and trying not to pick the exotic ones): 550 Requested action not taken: mailbox unavailable 553 Requested action not taken: mailbox name not allowed 554 Transaction failed In practice, the actual error that the MTA is trying to convey can vary widely from the descriptions given above, and it is common for a given product to have different messages associated with the same formal reply code, to describe different errors where the desired response from the MTA at the other end is the same. This is not to say that the official descriptions convey no information, but you cannot reasonably claim that the official description always matches the reported problem, even setting aside cases where people have used the wrong codes, or just couldn't find a code that was a reasonable match for what they had to report. >(3) I don't understand why you say that the same code can mean >different things in different contexts. I imagine that sendmail, an X.400 gateway, an All in one mail router, a cc:Mail gateway, a firewall and a BITNET mailer will have widely varying phrasing and interpretations of the codes. >(4) The Status field of a DSN (Delivery Status Notification), >defined in RFC 1894 (also standards-track), does not require >error message text. This is correct, however the same could be said about SMTP reply codes. If I want to write a SMTP agent that just replies with a number, this is a perfectly valid implementation, and as you know other MTAs are forbidden from even looking at the text. Luckily all (as far as I know) SMTP developers understood the merit of providing human-readable text that describes the actual error that they were trying to report. Similarly, there is a "Diagnostic-Code:" field in the DSN which LISTSERV does use when present. What I am trying to say is that a MTA that says 5.1.1 is no different from a SMTP server that says "554 ERR" or just "554". LISTSERV treats these two situations in the same manner, the only difference is that SMTP servers typically provide a descriptive error text whereas, DSN being new and all that, not all MTAs that use DSN fill in the "Diagnostic-Code:", even though (being for the most part existing products into which DSN was retrofitted) they do have code to generate these one-line descriptions everywhere that they occur. They just haven't had the time to add a "Diagnostic-Code:" field with these errors, or maybe they haven't realized the need. This is a new standard and we need to give people some time to implement it. >(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. Yes but this is not computer parseable, and LISTSERV needs a reasonably short (1-2 line) error description. >(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. For the auto-deletion report, I need something that fits on a line or two. Quite honestly, I have no idea what this network congestion code is for (if the network is congested you should just try again later), but I assume it has uses or it wouldn't be in there. If phrased in a more specific context, I don't doubt that I would understand what it means. I must be missing the obvious, but I think this illustrates the problem with these generic codes. Basically I don't understand why you seem to think that accurate failure information can be omitted at the source because it can be regenerated from a static, high-level table of generic meanings at the destination. Eric