Re: [EAI] mail bounce versus punycode conversion

[John C Klensin <[e-mail]>]

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

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