Re: [ietf-smtp] Make username optional in email addresses
John C Klensin <john-ietf@jck.com> Sat, 18 February 2023 04:25 UTC
Return-Path: <john-ietf@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 86C4CC15DD44 for <ietf-smtp@ietfa.amsl.com>; Fri, 17 Feb 2023 20:25:44 -0800 (PST)
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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcEHVaEGThFN for <ietf-smtp@ietfa.amsl.com>; Fri, 17 Feb 2023 20:25:43 -0800 (PST)
Received: from bsa2.jck.com (bsa2.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 CA6C5C14CE27 for <ietf-smtp@ietf.org>; Fri, 17 Feb 2023 20:25:43 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1pTEn7-0004Tp-93; Fri, 17 Feb 2023 23:25:41 -0500
Date: Fri, 17 Feb 2023 23:25:36 -0500
From: John C Klensin <john-ietf@jck.com>
To: tjw ietf <tjw.ietf@gmail.com>
cc: Russ Allbery <eagle@eyrie.org>, Scott Antipa <scottantipa@gmail.com>, ietf-smtp@ietf.org
Message-ID: <F05DF83AC689517AB12F2B19@PSB>
In-Reply-To: <76D0BF6D-7DE1-41FF-B41D-DB078A46BAD6@gmail.com>
References: <00442A7D2E63E30765843D13@PSB> <76D0BF6D-7DE1-41FF-B41D-DB078A46BAD6@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@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/4o45P1ie3ZFQlczXHmpmkk5-Ul0>
Subject: Re: [ietf-smtp] Make username optional in email addresses
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 18 Feb 2023 04:25:44 -0000
--On Friday, February 17, 2023 17:30 -0500 tjw ietf <tjw.ietf@gmail.com> wrote: > Speaking as a simple dns person > > _role.example.com TXT tjw.ietf@gmail.com > > Is my fuel for the discussion Tim, There are at least three issues there (or with something similar using SRV records). One, which may not apply to the smaller, more personal, domains I think Scott is most concerned about, is that sometimes the process of modifying a DNS record involves different people and/or procedures than modifying an email delivery MTA. Second, it is typically going to means three DNS lookups to identify an email address and where to send it, one for the _role record as shown, one to get the MX record(s) for the target domain, and, unless one gets lucky and the addresses of the servers identified in the MX records show up as additional information, a third (or more) to retrieve the addresses for that server or servers. And third, as I think was mentioned in another context, every time that someone has proposed something that might involve a DNS entry per person rather than per host or pseudo-host, the conclusion has been that it would not scale properly. Now Scott's situation may be a bit different because I think he is thinking about one email address per domain (or, if there were, using the terminology of my earlier note, an "owner" and an "all" one, two). That might therefore not trigger the scaling problem. But, still... Whether one did it with a special name and DNS entry or a "role" email address, I think the problem is the same" either the user or the originating MUA needs to understand the naming or RR convention and how to use it. Then, with Scott's proposal, the delivery server and everything in between need to understand a now-prohibited address and the delivery server needs to understand what it means. With my "owner" suggestion, the delivery server has to have an alias for the correct/target address (not unlike the usual treatment for "Postmaster"); with yours the address on the wire is actually the target address. And, Scott, please pay attention to Nathaniel's comment. Many of us who "own" dedicated domains of which we are the only important user use a multitude of email addresses to organize materials, set up special security mechanisms, and so on. I don't know about Nathaniel, but I use subaddress mechanisms and probably use hundreds of different addresses. Some get special post-delivery routing, others don't, and the rules change frequently (in my case, it is rare for a week to go by without my making at least one internal or routing or classification change). For us, "owner@example.com" or "everyone@example.com" would be just one more of those specialized addresses to put in the relevant tables, tables that we need to maintain anyway. Keeping in mind that "@gmail" would almost certainly either have to be rejected or treated as a synonym for something Postmaster-like and that at least some of the cases of @personaldomain.example would be used as Nathaniel and I use them, it is not clear to me that there would actually be significant demand for "@example.com" even if you could get it adopted. best, john
- [ietf-smtp] Make username optional in email addre… Scott Antipa
- Re: [ietf-smtp] Make username optional in email a… Dave Crocker
- Re: [ietf-smtp] Make username optional in email a… Scott Antipa
- Re: [ietf-smtp] Make username optional in email a… Russ Allbery
- Re: [ietf-smtp] Make username optional in email a… Dave Crocker
- Re: [ietf-smtp] Make username optional in email a… Russ Allbery
- Re: [ietf-smtp] Make username optional in email a… Dave Crocker
- Re: [ietf-smtp] Make username optional in email a… John C Klensin
- Re: [ietf-smtp] Make username optional in email a… tjw ietf
- Re: [ietf-smtp] Make username optional in email a… Scott Antipa
- Re: [ietf-smtp] Make username optional in email a… John C Klensin
- Re: [ietf-smtp] Make username optional in email a… Nathaniel Borenstein
- Re: [ietf-smtp] Make username optional in email a… Paul Smith
- Re: [ietf-smtp] Make username optional in email a… Scott Antipa
- Re: [ietf-smtp] Make username optional in email a… Valdis Kl ē tnieks
- Re: [ietf-smtp] Make username optional in email a… John C Klensin
- Re: [ietf-smtp] Make username optional in email a… Peter J. Holzer
- Re: [ietf-smtp] Make username optional in email a… Steffen Nurpmeso
- Re: [ietf-smtp] Make username optional in email a… John Levine
- Re: [ietf-smtp] Make username optional in email a… John Levine
- Re: [ietf-smtp] Make username optional in email a… Keith Moore
- Re: [ietf-smtp] Make username optional in email a… Scott Antipa
- Re: [ietf-smtp] Make username optional in email a… Scott Antipa
- Re: [ietf-smtp] Make username optional in email a… Tim Wicinski
- Re: [ietf-smtp] Make username optional in email a… John C Klensin
- Re: [ietf-smtp] Make username optional in email a… Keith Moore
- Re: [ietf-smtp] Make username optional in email a… John Levine
- Re: [ietf-smtp] Make username optional in email a… Paul Smith