(adding Jiankang since I'm not sure he is on this list)
--On Saturday, July 11, 2020 22:30 -0400 John R Levine
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
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.
example.net. IN CNAME example.com.
example.com. IN A 22.214.171.124
example.com. IN MX 0 whatever.
example.net. IN A 126.96.36.199
example.com. IN A 188.8.131.52
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
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 <user(_at_)example(_dot_)com> and <UseR(_at_)example(_dot_)com> as
is, in general, stupid.
Now, following that logic, if the server at <whatever> decided
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
用户1(_at_)xn--fqr621h(_dot_)services(_dot_)net, I'd put up a message to the
effect that I assume the user is trying to send to
用户1@后缀.services.net, 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.
ietf-smtp mailing list