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