Subject: [ietf-smtp] Are A-label and U-label addresses supposed to be equivalent ?

From: "John R Levine" <[email-masked]>
Date: 11 Jul 2020 22:30:42 -0400

Let's say I had these two addresses, which are the same except that one 
has a U-label and the other has the equivalent A-label.  They're both 
non-ASCII addresses since the mailbox name is in Chinese

[email-masked]
[email-masked]

Presumably if you're sending mail to those addresses, you should send them 
to the same place.  But on the final delivery MTA, is that one address or 
two?  Different mail software implement it differently.

Looking at RFCs 6530 and 6531 I get the impression the authors assumed 
they'd be the same but I don't see anywhere it explicitly says so.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Sat, 11 Jul 2020 23:42:50 -0400

(adding Jiankang since I'm not sure he is on this list)

--On Saturday, July 11, 2020 22:30 -0400 John R Levine
<[email-masked]> wrote:

> Let's say I had these two addresses, which are the same except
> that one has a U-label and the other has the equivalent
> A-label.  They're both non-ASCII addresses since the mailbox
> name is in Chinese
> 
> [email-masked]
> Presumably if you're sending mail to those addresses, you
> should send them to the same place.

Given the way the interactions between RFC 6531, RFC 5321, and
IDNA work, you have little choice: the sending MTA needs to go
through IDNA to get an FQDN that can actually get looked up and,
after that, the place where it sends (or tries to send) the
message is all about the MX records. 
 
>   But on the final delivery
> MTA, is that one address or two?  Different mail software
> implement it differently.

I think the precedents for this are quite clear.  If you
disagree or think it should be spelled out more clearly, please
put an erratum or other notes somewhere so the issue doesn't get
lost.  Consider the following ASCII-only example.

DNS records
    example.net. IN CNAME example.com.
    example.com. IN A 1.2.3.4
    example.com. IN MX 0 whatever.
or even
    example.net. IN A 1.2.3.4
    example.com. IN A 1.2.3.4
    example.com.IN  MX 0 whatever.
   example.net. IN MX 0 whatever.

Now the sending MTA is going to open a connection to
<whatever.>, which has to be a primary host name associate with
an Address RR.   Once the mail session is open, it sends some or
all of
   RCPT TO:<[email-masked]>  
   RCPT TO:<[email-masked]>
   RCPT TO:<[email-masked]>

Now, despite that fact that all of those addresses result in
delivery to the SMTP server at <whatever> and example.com and
example.net are about as close to equivalent in the DNS as
possible (especially in the first case), once that delivery
server has accepted the message, those three addresses are, more
or less, just strings.  It can decide what to do with each one
and can forward or deliver to the same mailbox or two or three
difference mailboxes although 5321 does say (more politely) that
treating <[email-masked]> and <[email-masked]> as different
is, in general, stupid.

Now, following that logic, if the server at <whatever> decided
to treat

	 [email-masked]

As distinct mailboxes, I think it would be within its rights to
do so.  I also think that, like the "user" and "UseR" local part
distinction, doing so would be fairly dumb and, if I were
implementing the MTA that <whatever> was going to use, I don't
think I'd go out of my way to make separating the two easy.
But, as I said above, I think the answer at the SMTP level is
fairly clear even though I do not believe that stupidity in
applying distinctions that users won't understand is desirable
if it can be avoided.
 
> Looking at RFCs 6530 and 6531 I get the impression the authors
> assumed they'd be the same but I don't see anywhere it
> explicitly says so.

Speaking as one of the authors, I don't think we discussed it
(rather than assuming anything).  There is a specific reason why
we probably didn't, which goes to the "what questions are you
really asking" issue.  The core SMTPUTF8 specs rather strongly
discourage using anything but native character UTF-8 strings
anywhere other than in the SMTP client when it is trying to
figure the next hop out.  Of course there it has to do a U-label
-> A-label conversion.   It is always a matter of taste (and the
IETF does not specify MUA behavior) but, it I were writing an
MUA and someone came to it and asked that mail be sent to
[email-masked], I'd put up a message to the
effect that I assume the user is trying to send to
[email-masked], ask for confirmation, and, upon
getting it, put the latter address into the relevant header
fields and use it in the RCPT command to the Submission server.
If MUA authors behaved that way -- and I assume you can see the
reasons why they probably should -- then the case you describe
would probably just not happen in practice unless something else
was wrong or an attack was being attempted.

best,
   john

---

From: "John R Levine" <[email-masked]>
Date: 12 Jul 2020 00:13:11 -0400

On Sat, 11 Jul 2020, John C Klensin wrote:
> [ Are corresponding A-label and U-label addresses different mailboxes? ]

> think I'd go out of my way to make separating the two easy.

That's what I was thinking.  But I was also thinking it might be different 
from upper/lower case mailboxes since, there is a defined mapping betwen 
A-labels and U-labels, and we already have at least one place, DNS 
lookups, where the MTA has to turn one into the other.

I'm doing a project for the UASG testing the EAI conformance of a bunch of 
mail software.  It appears that Postfix treats A-label and U-label 
addresses differently, and Coremail may only accept the U-label and reject 
the A-label, although it's hard to tell because at the moment, its mail 
server for the 互联网.中国 domain doesn't accept anything.

MUA support leaves a lot to be desired, e.g. Roundcube webmail always 
turns the domain into A-labels, even if the mailbox is non-ASCII.

R's,
John

PS:

Coremail isn't accepting any mail at all for the 互联网.中国 domain. 
Telnet to port 25 and it says:

  554 IP<10.12.1.170> is rejected: 0

Huh? What?

---

From: John C Klensin <[email-masked]>
Date: Sun, 12 Jul 2020 01:08:23 -0400

--On Sunday, July 12, 2020 00:13 -0400 John R Levine
<[email-masked]> wrote:

>> As distinct mailboxes, I think it would be within its rights
>> to do so.  I also think that, like the "user" and "UseR"
>> local part distinction, doing so would be fairly dumb and, if
>> I were implementing the MTA that <whatever> was going to use,
>> I don't think I'd go out of my way to make separating the two
>> easy.
> 
> That's what I was thinking.  But I was also thinking it might
> be different from upper/lower case mailboxes since, there is a
> defined mapping betwen A-labels and U-labels, and we already
> have at least one place, DNS lookups, where the MTA has to
> turn one into the other.

But, while, again, I'd think that taking advantage of the
distinction would be dumb, an MTA also has to do DNS lookups to
get the MX records but substituting the MX-target domain into
either the RCPT command or header "To:" would not work and would
be catastrophically stupid as well as clearly non-conforming.
So, as far as the MTA is concerned, that is a one-way
transformation with no need that I can thinks of to ever map tan
A-label to a U-label except _maybe_ in error reporting.

> I'm doing a project for the UASG testing the EAI conformance
> of a bunch of mail software.  It appears that Postfix treats
> A-label and U-label addresses differently, and Coremail may
> only accept the U-label and reject the A-label, although it's
> hard to tell because at the moment, its mail server for the
> 互联网.中国 domain doesn't accept anything.

The last I looked at Coremail, my impression was that it had
that MUA, MSA, and MTA functions a little confused.  Whether the
above would be plausible might depend on sorting that out.  In
addition, if the local-part is all-ASCII, a conversion to
A-labels is allowed by IDNA, especially in the MSA (just another
application) and SMTPUTF8 need not be involved.  I'm not going
to go back and look, but I think the SMTPUTF8 specs are fairly
clear that A-labels anywhere prior to the MTA's interface to the
DNS are strongly discouraged but, because of how IDNA works, not
prohibited.

> MUA support leaves a lot to be desired, e.g. Roundcube webmail
> always turns the domain into A-labels, even if the mailbox is
> non-ASCII.

That is clearly non-conforming to the intent of the specs;
whether it is clearly non-conforming is another question.  But I
suggest that USAG does no one any favors by hair-splitting about
the difference between intent (which was intended to promote
both operability and a decent user experience) and conformance
(which is closer to the former only).

> PS:
> 
> Coremail isn't accepting any mail at all for the
> 互联网.中国 domain. Telnet to port 25 and it says:
> 

If it sees your Telnet client as 10.12.1.170 and absent any
other information, I'd be inclined to wonder whether that is a
"we aren't accepting connections or mail from RFC 1918
addresses" rather than anything having to do with the address.

best,
   john

---

From: "Jiankang Yao" <[email-masked]>
Date: Mon, 13 Jul 2020 10:46:44 +0800

From: John C Klensin
Date: 2020-07-12 11:42
To: John R Levine; ietf-smtp
CC: YAO Jiankang
Subject: Re: [ietf-smtp] Are A-label and U-label addresses supposed to be equivalent ?
>(adding Jiankang since I'm not sure he is on this list)

Dear John,
Thanks for adding me. I will add more comments after yours.

> > implement it differently.

I think that it SHOULD implement it in the same way. That is to treat these two addresses to be same. 

[email-masked]

Besides john's example,
there is another example:

Do we regard these two addreses to be same?
[email-masked]
[email-masked]

I think that it is yes.
[email-masked] is another form of [email-masked].

For the same reason, 
[email-masked] in another form of 
[email-masked]

>figure the next hop out.  

Besides john's explanation,
RFC6531 has some clarification.

Section 3.7.  Additional ESMTP Changes and Clarifications

   The information carried in the mail transport process involves
   addresses ("mailboxes") and domain names in various contexts in
   addition to the MAIL and RCPT commands and extended alternatives to
   them.  In general, the rule is that, when RFC 5321 specifies a
   mailbox, this SMTP extension requires UTF-8 form to be used for the
   entire string.  When RFC 5321 specifies a domain name, the
   internationalized domain name SHOULD be in U-label form if the
   SMTPUTF8 extension is supported; otherwise, it SHOULD be in A-label
   form.

So in the email address, both U-label and A-label are different forms for the Internationalized Domain Names.

Best Regards
Jiankang Yao

---

From: "Jiankang Yao" <[email-masked]>
Date: Mon, 13 Jul 2020 10:54:24 +0800

From: John R Levine
Date: 2020-07-12 12:13
To: John C Klensin; ietf-smtp
CC: YAO Jiankang
Subject: Re: [ietf-smtp] Are A-label and U-label addresses supposed to be equivalent ?

>server for the 互联网.中国 domain doesn't accept anything.

Accoreding to my experiences, I think that Coremail accepts both U-label and A-labe.
I add Marvin Woo from coremail to join this discussion.

Best Regards
Jiankang Yao