Re: [ietf-smtp] Make username optional in email addresses

[Scott Antipa <[e-mail]>]

I was thinking this would be a single special email per domain, eg “
[e-mail]” or whatever. Does that address the scaling problem?

On Fri, Feb 17, 2023 at 6:25 PM John C Klensin <[e-mail]> wrote:

>
>
> --On Friday, February 17, 2023 17:30 -0500 tjw ietf
> <[e-mail]> wrote:
>
> > Speaking as a simple dns person
> >
> > _role.example.com TXT [e-mail]
> >
> > 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, "[e-mail]" or "[e-mail]"
> 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
>
>