Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses

[Kristin Hubner <[e-mail]>]

On Aug 23, 2006, at 4:21 AM, Harald Alvestrand wrote:

>>
>> 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.
>>
> just because I have some available, here are some examples of SMTP 
> error codes...
>
>
> | SMTP error in RCPT TO: 553 '<@>' <n5ial@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 <[e-mail]>... 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 [e-mail] |
> | 5.1.1 (Unknown user): QMail; 550 <[e-mail]-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 agent
>
> Query: 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
[e-mail]

>
>
> _______________________________________________
> Ltru mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ltru