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
- [ietf-smtp] Are A-label and U-label addresses sup… John R Levine
- Re: [ietf-smtp] Are A-label and U-label addresses… John C Klensin
- Re: [ietf-smtp] Are A-label and U-label addresses… John R Levine
- Re: [ietf-smtp] Are A-label and U-label addresses… John C Klensin
- Re: [ietf-smtp] Are A-label and U-label addresses… Jiankang Yao
- Re: [ietf-smtp] Are A-label and U-label addresses… Jiankang Yao
- Re: [ietf-smtp] Are A-label and U-label addresses… John C Klensin