Re: [EAI] mail bounce versus punycode conversion

based on the ietf 78 eai meeting,

 I have updated it to the following text:

  If a server advertises UTF8SMTP and the client does not recognize the
   extension, the client may send a regular message [RFC5321] and
   [RFC5322].  In this case, the client may continue to use the
   [RFC5890] to transform the domain portion of an address to A-label
   [RFC5890].  If the email address is in the format of ASCII@non-ASCII,
   the legacy SMTP servers MUST reject the message with the
   ASCII@non-ASCII if the non-ASCII domain part is not transformed into
   the format of A-label by the client.  UTF8SMTPbis servers MUST
   recognize and decode the ACE label(s) as appropriate.

Jiankang Yao

----- Original Message ----- 
From: "Ernie Dainow" <edainow@ca.afilias.info>
To: "John C Klensin" <klensin@jck.com>
Cc: <ima@ietf.org>
Sent: Tuesday, July 13, 2010 8:59 PM
Subject: Re: [EAI] mail bounce versus punycode conversion

> On 7/13/2010 1:53 AM, John C Klensin wrote:
>>
>> --On Monday, July 12, 2010 17:17 -0400 Ernie Dainow
>> <edainow@ca.afilias.info>  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
>>
>>    
> 
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www.ietf.org/mailman/listinfo/ima