On Aug 23, 2006, at 4:21 AM, Harald Alvestrand wrote:
just because I have some available, here are some examples of SMTP error codes...The issue of making the text of SMTP responses language-appropriate has been recognized since RFC 821 was written. 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. When the codes proved inadequate in practice, we extended the codes, which was entirely consistent with that general model. 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.| SMTP error in RCPT TO: 553 '<@>' <n5ial at n5ial> not matched: (ERR | | Error in RCPT TO: 550 5.1.1 unknown or illegal alias: @ (MX) | | Error in RCPT TO: 501 5.7.1 This system is not configured to rel | | Connect(raw) failed: Connection refused | | 5.1.1 (Unknown user): QMail; 550 <brandl at htu.tu-graz.ac.at>... U | | Error in RCPT TO: 550 Sorry, no mailbox here by that name. (#5.1 | | Error in RCPT TO: 554 5.0.0 Mail to ace3 is not permitted (MX) | | Error in RCPT TO: 550 5.1.1 <@>... email address lookup in domai | | Error in RCPT TO: 553 5.3.0 <@>... Unknown user jwessel at staff.ui | | 5.1.1 (Unknown user): QMail; 550 <sn at plato.chemietechnik.uni-dor | | Error in RCPT TO: 550 5.7.1 Unable to relay for @ (MX) | | Error in RCPT TO: 554 Mail for @ rejected for policy reasons. (M | | RELAY problem: 550 5.7.1 <@>... Relaying denied (MX) | | Error in RCPT TO: 553 sorry, that domain isn't in my list of all | | Error in RCPT TO: 554 5.7.1 <@>... User unknown (MX) |<@> is an abbreviation for "the original email address was here". These are truncated to 64 chars.the important points are:- a lot of servers return quite different errors with the same error code - the servers try to return info that's useful for the sender, not for the relay agentQuery: Has anyone seen a production piece of software that tries to decode the extendedstatuscodes as text for display to the users?Harald
I'm not sure that this is the sort of example you had in mind, as this is at the MTA level, not the MUA level...but we added at it the MTA level to partially make up for the current dearth of such "localizing SMTP extendedstatuscode" support at the MUA level.
The Sun JES MS MTA has options that for DSNs generated by the MTA, sites can specify their own choice (in their own choice of language and charset -- to correspond to their choice of language and charset for the entire first/human-readable portion of the DSN) an additional text string to be reported corresponding to each extendedstatuscode. That is, when the MTA is generating a DSN (based on, say, an SMTP rejection from a remote SMTP server), the DSN can include an optional site-specified "interpretation" of the extendedstatuscode in addition to the actual SMTP rejection code and text. This will then be included in the first (human readable)
portion of the multipart/report. That is, a site could set 5.1.1=<localized-string> 5.1.2=<another-localized-string>etc., (actually, they can set a bunch of such options, one set for each language/charset combination for which they wish such special support) and then when the MTA generates a DSN reporting on encountering such an extended code, the MTA will include the site's localized string, as well as the actual "original" text (if any) issued by the remote SMTP server in the
human-readable first portion of the DSN.This option has been used by some sites, though probably not many. As Harald Alvestrand observed, since the current situation is that a single extendedstatuscode will be used by different servers to report various (though "related" in being the same RFC 1893 category) errors, the general "interpretation" you can make for a particular extendedstatuscode currently tends towards the vague -- essentially a localized version of the category as
defined in RFC 1893. Regards, Kristin kristin.hubner at sun.com
_______________________________________________ Ltru mailing list Ltru at ietf.org https://www1.ietf.org/mailman/listinfo/ltru
_______________________________________________ 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.