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

John C Klensin <john@jck.com> Sun, 12 July 2020 03:43 UTC

Return-Path: <john@jck.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569683A09AC for <ietf-smtp@ietfa.amsl.com>; Sat, 11 Jul 2020 20:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU68OlF6MYMi for <ietf-smtp@ietfa.amsl.com>; Sat, 11 Jul 2020 20:42:59 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19DC63A09AB for <ietf-smtp@ietf.org>; Sat, 11 Jul 2020 20:42:58 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john@jck.com>) id 1juStE-000NL2-BM; Sat, 11 Jul 2020 23:42:56 -0400
Date: Sat, 11 Jul 2020 23:42:50 -0400
From: John C Klensin <john@jck.com>
To: John R Levine <johnl@taugh.com>, ietf-smtp@ietf.org
cc: YAO Jiankang <yaojk@cnnic.cn>
Message-ID: <B952EF2B98EC9E710ED099CC@PSB>
In-Reply-To: <alpine.OSX.2.22.407.2007112221060.44735@ary.qy>
References: <alpine.OSX.2.22.407.2007112221060.44735@ary.qy>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/XuKnXMRggErl9BzSYqyJO5CNmtA>
Subject: Re: [ietf-smtp] Are A-label and U-label addresses supposed to be equivalent ?
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Jul 2020 03:43:00 -0000

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

--On Saturday, July 11, 2020 22:30 -0400 John R Levine
<johnl@taugh.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@xn--fqr621h.services.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 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:<user@example.net>  
   RCPT TO:<user@example.com>
   RCPT TO:<UseR@example.com>

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@example.com> and <UseR@example.com> as different
is, in general, stupid.

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

	 用户1@后缀.services.net
	 用户1@xn--fqr621h.services.net

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@xn--fqr621h.services.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.

best,
   john