Re: [EAI] mail bounce versus punycode conversion

[Joseph Yee <[e-mail]>]

On 2010-07-13, at 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.

Speaking for myself and my past experience on <ASCII@non-ASCII> ...

Some MUAs, with plugin, converts <ASCII@non-ASCII> to <ASCII@A-label>  before submitting.  Some would display <ASCII@A-label> to <ASCII@non-ASCII>.
MTAs 'listen' domain in ASCII and A-label format only.  


So from now to at least in early phase when EAI introduced, there may be some mail addresses in <ASCII@non-ASCII> format but not running under UTF8SMTPbis.  And if EAI aware users with EAI aware MUA and EAI aware MTA send message to those mail addresses, the message would be rejected.  I would guess this group would be early adopters of EAI, but never assume this is the case.

Personally I see the domain convert as 'last resort' hoping to deliver the email.  I don't think it as must-do, but I hope it does not get into must-not-do.  

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

I like this text.  Address the domain convert as optional.  We would need to make sure the new text in both 5335bis section 4.4 and 5336bis section 3.2 (last paragraph) be consistent.

Joseph

> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ima