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

[John C Klensin <[e-mail]>]

Scott,

If it is one per domain (with a few qualifications about what
you mean by "domain"), sure.  But that may also be a stronger
reason to think about this is  terms of a role address
("catchall" if you prefer) rather than about trying to involve
the DNS.   

Or, as a different way to look at it (and at the risk of Tim
making choking noises), if the address is a really a per-domain
contact point, there is already a way to specify such an address
and it is already required: it is the RNAME field of the SOA
record, which RFC 1035 describes as "the mailbox of the person
responsible for this zone".   :-(

And, again, neither of those options, nor any other "role
address" one, requires a change to either the email or DNS
infrastructure.

   john

--On Wednesday, February 22, 2023 10:46 -1000 Scott Antipa
<[e-mail]> wrote:

> 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
>> 
>>