--On Monday, 13 July, 2020 10:46 +0800 Jiankang Yao
<yaojk(_at_)cnnic(_dot_)cn> wrote:
...
--On Saturday, July 11, 2020 22:30 -0400 John R Levine
<johnl(_at_)taugh(_dot_)com> 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
用户1@后缀.services.net
用户1(_at_)xn--fqr621h(_dot_)services(_dot_)net
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 that it SHOULD implement it in the same way. That is
to treat these two addresses to be same.
用户1@后缀.services.net
用户1(_at_)xn--fqr621h(_dot_)services(_dot_)net
Besides john's example,
there is another example:
Do we regard these two addreses to be same?
user(_at_)EXAMPLE(_dot_)com
user(_at_)example(_dot_)com
I think that it is yes.
user(_at_)EXAMPLE(_dot_)com is another form of user(_at_)example(_dot_)com.
It is yes, but that is irrelevant because the DNS specifications
involve/require case insensitivity for ASCII domain names. IDNA
does not permit upper-case non-ASCII (e.g., EXÁMPLE.com is
invalid, is not a U-label, and has no U-label equivalent.
For the same reason,
用户1@后缀.services.net in another form of
用户1(_at_)xn--fqr621h(_dot_)services(_dot_)net
For DNS purposes, yes. But the only time an SMTP-client is
supposed to be checking the DNS is at resolution time.
Otherwise, absent specific language in the SMTPUTF8 specs (which
I couldn't find when I looked back through them yesterday), the
RFC 5321 rule that MTAs other than the final delivery one are
not supposed to be trying to figure out what addresses "mean"
almost certainly applies.
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.
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.
That is not what the above says.
What it says is that
(1) When SMTPUTF8 is in use with a non-ASCII local-part, UTF-8
is required to be used in both the local-part and the
domain-part. That makes 用户1(_at_)xn--fqr621h(_dot_)services(_dot_)net a
violation of the spec, regardless of what it matches.
(2) When SMTPUTF8 is in use with a non-ASCII domain-part, a
domain-part that contains non-ASCII labels SHOULD be in U-label
form. For example, user@后缀.services.net is, at least,
strongly preferred to user(_at_)xn--fqr621h(_dot_)services(_dot_)net
(3) When SMTPUTF8 is not supported (and therefore not in use),
A-labels SHOULD be used. For that case, the rules fall back to
the rules of RFC 5321 and it prohibits non-ASCII character in
mailboxes so both of your examples are invalid. The SHOULD is
actually out of scope for RFC 6531 and someone should file an
erratum.
It doesn't say a word about matching of different forms, only
what forms are allowed (or preferred). And, for the examples
you and John have used, use of the A-label form is already
non-conforming (modulo the deliberate loophole around the
SHOULD, but that does not apply to the first case), so it may be
the question itself is improperly formed, at least before the
robustness principle is applied. But I can find no
justification for asserting the two mailbox forms MUST be
treated as matching.
best,
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp