Subject: Re: [EAI] mail bounce versus punycode conversion

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 10 Aug 2010 13:32:47 +0800

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" <[email-masked]>
To: "John C Klensin" <[email-masked]>
Cc: <[email-masked]>
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
>> <[email-masked]>  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<[email-masked]....>  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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: John C Klensin <[email-masked]>
Date: Tue, 10 Aug 2010 06:22:39 -0400

--On Tuesday, August 10, 2010 13:32 +0800 Jiankang YAO
<[email-masked]> wrote:

>   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.

I think this is correct, but unnecessarily confusing about what
we really intend.  In particular, "the client" implies that
transformations can be made by _any_ SMTP client; we want to
encourage that only for either MUAs/MSAs or for the
ASCII@non-ASCII case only, which is unclear from the above.  In
addition, "UTF8SMTP" applies exclusively to the experimental
versions.   We have also discovered, especially with the
IDNA2008 documents, that referring to a series of RFCs by number
only is very confusing for the readers; I would encourage you to
adopt the style finally agreed upon there, e.g., to use
something like
       the IDNA Definitions document [RFC5890]
in the first appearance in a block of text and simply 
       the IDNA Definitions document
thereafter.

As a mechanical editing convenience, the XML for Framework
(4952bis) includes, as the first ENTITY statement in the
"DOCTYPE rfc" declaration:

    <!ENTITY EAISMTPkeyword "UTF8SMTPbis">

any use of UTF8SMTP then becomes &EAISMTPkeyword;", making it
very easy to convert to the new keyword when appropriate and
easy to find those references when needed.  I recommend that
others developing relevant documents in XML follow that
convention.

For a suggestion on making the distinctions suggested above
clear, you may want to reread the text I proposed some weeks
ago, ignoring obvious typographical errors (quoted in your note):

>>> The strongest thing that can be said, ideally with a
>>> citation of 5321, is something like:
>>> 
>>>      <ASCII@non-ASCII>
>>>           ; the MTA is required to be SMTP [RFC
>>>           5321]-compliant ; only.  Such an MTA is not
>>>           required to
>>>           ; MUA or submission server (MSA) may perform
>>>           conversions ; to A-label form, but is not required
>>>           to do so.

best,
   john