On Wed, 23 Aug 2006, Harald Alvestrand wrote: > > Query: Has anyone seen a production piece of software that tries to decode the > extendedstatuscodes as text for display to the users? Yes, and the result is usually unhelpful in my experience. A significant number of support queries that I have to deal with are solved by me pulling an error message out of the logs that was hidden by some software between my servers and the user. (Admittedly, this is more likely to happen for us because we don't support enhanced status codes, but since they carry so little extra information I doubt they would help.) John says: > > As with many other Internet protocols, the most effective model is to > use a single form on the wire and then perform translations (of > character sets, terminal information, formats, and, yes, languages) at > the endpoints. The "rely on the codes" requirement of 821 was, and is, > part of that concern. That's not the way I read it. To me it says that the non-enhanced codes are for the client state machine and the text is for a human; it does not imply that a client should replace the server's text with its own idea of what went wrong. > If a user needs to look at an SMTP reply message directly, then I > suggest that either there is a debugging case in action or the relevant > MUA is broken. Debugging cases are easier with more uniformity and > simplicity, not more options. If a user sees an SMTP response then something has gone wrong so it's a debugging case by definition. Addison says: > > Almost no one interacts with SMTP servers directly. Of course they do, to the same extent that they interact with IMAP or POP or HTTP servers - mediated by a user agent. >From my point of view, and from the point of view of my colleagues on the help desk, it would be much easier if MUAs did not try to impose their own gloss on my servers' error messages (or do other stupid things like truncate them). That way I can provide helpful text that explains what went wrong, and/or a URL to help pages or a directory. The current set of enhanced status codes is non-orthogonal and does not cover the range of possibilities or provide enough detail within their coverage. For example, there are codes for bad syntax and bad domain for both sender and recipient addresses, but you can only specifically say the local part is bad for destination addresses, and there are different OK codes for senders and recipients. There's a code for "too many recipients" but not "too few recipients" (e.g. RFC 4468 has a different gloss of 5.5.0 for this situation). In SMTP you can say that an address has changed (551) but not with enhanced status codes. (We've had a number departments changing name recently where it might have been useful to use the 551 feature, but since no-one implements it we just used an ad-hoc "try newname.cam.ac.uk instead" error.) The range of codes for client policy restrictions is inadequate: there's no way of expressing the distinction between "relaying is not permitted", "you have been blacklisted", "you are making too many concurrent connections", "you have been rate-limited", "you have been greylisted", etc. There are no codes for saying that the message content violates security restrictions, such as a virus infection or a forbidden attachment type or a spam classification. Even if you solve these problems, there is no provision for extending the set of status codes except as a standards action - there is no IANA registry. And in fact an IANA registry wouldn't solve the problem because no existing software will have glosses for any new status codes you might register, so the new codes would be useless. The idea of a fixed set of status codes is fundamentally unable to cope with evolving operational requirements. Tony. -- f.a.n.finch <dot at dotat.at> http://dotat.at/ FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR GOOD. _______________________________________________ Ltru mailing list Ltru at ietf.org https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.