Re: [EAI] mail bounce versus punycode conversion

[Ernie Dainow <[e-mail]>]

On 7/13/2010 1:53 AM, John C Klensin wrote:
>
> --On Monday, July 12, 2010 17:17 -0400 Ernie Dainow
> <[e-mail]>  wrote:
>
>    
>> A message to mailbox<ASCII@non-ASCII>  will bounce if the
>> UTF8SMTPbis extension is not supported by an MTA. According to
>> rfc5336bis, this will not be done by an MTA. This is not
>> obvious behavior, since it is fairly trivial to do a punycode
>> conversion of the domain part so that the address is all
>> ASCII. Many users are familiar with web browsers that do this
>> conversion and may expect similar behavior in email.
>>      
> Speaking for myself only, this is actually one of the difficult
> cases I was sort of alluding to in an earlier note today.
>
> Please review draft-iab-idn-encoding (-03 was posted yesterday).
> If one has a system in which any string in a multi-target name
> resolution slot is passed to a common name resolution interface,
> then it probably will not be possible to prevent an
> <ASCII@non-ASCII>  string from being resolved, with or without
> EAI.  Similarly, if a system identifies the domain part as being
> an IDNA-aware domain name slot,<ASCII@non-ASCII>  might be
> turned into<ASCII@A-label.A-label....>  before the mail-specific
> software actually gets its hands on it and subsequently treated
> as an all-ASCII address.
>
> It is plausible to put<ASCII@non-ASCII>  outside the scope of an
> EAI standard if the extension isn't specified.  That follows
> from the observation that, if the extension is not specified,
> everything (ASCII and non-ASCII alike) is outside the scope of
> the standard.  But requiring message rejection in one of those
> cases is not reasonable: servers who do not announce the
> extension are bound only by the rules of RFC 5321 and friends.
> Those specifications are specific about what must be accepted
> but deliberately not specific about what must be rejected.
>
>
>    
>> To reinforce that this is a failure case, we should add the
>> following example to section 4.4 of rfc5335bis-00.
>>
>>      <ASCII@non-ASCII>
>>           ; message will bounce if UTF8SMTPbis extension is not
>> supported. An MTA will not convert
>>           ; the domain part to ASCII, but this may be done by
>> an MUA or submission server (MSA).
>>      
> The strongest thing that can be said, ideally with a citation of
> 5321, is something like:
>
>      <ASCII@non-ASCII>
>           ; if theUTF8SMTPbis extension is not supported,
>           ; the MTA is required to be SMTP [RFC 5321]-compliant
>           ; only.  Such an MTA is not required to
>           ; convert the domain part to from U-label form to
>           ; A-label form.  If it does not, the message may be
>           ; rejected or simply not delivered.  Similarly,
>           ; if theUTF8SMTPbis extension is not supported, an
>           ; MUA or submission server (MSA) may perform conversions
>           ; to A-label form, but is not required to do so.
>    

According to section 3.2 in  5336bis-00, <ASCII@non-ASCII> is an 
internationalized address and can't be submitted to an MTA that does not 
support UTF8SMTPbis. An MTA cannot rewrite such a header so the message 
must be rejected. If we want to allow an MTA to do punycode conversion, 
the following paragraph in 5336bis-00 needs to be revised.

1.  If and only if the SMTP client (sender) is a Message Submission
        Server ("MSA") [RFC4409], it MAY, consistent with the general
        provisions for changes by such servers, rewrite the envelope,
        headers, or message material to make them entirely ASCII

>    
> Note that the IRI spec makes this even more difficult because
>
> 			mailto:ASCII@non-ASCII
>
> is at least as likely to be converted into
>
>              mailto:ASCII@%-encoded-UTF-8
>
> as into
>
>              mailto:ASCII@A-label...
>
> john
>
>