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