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

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

Sorry, should have added that, if you are interested in mail to
domain owners rather than mail to everyone using the domain, you
could think about a role address/ keyword for that too.  "OWNER"
or "DomainOwner" come to mind.  That would have an added
advantage: distinguishing between [e-mail] and
[e-mail] would avoid the ambiguity as to which
one was intended by @example.com.

And, fwiw, I agree with Dave.  The SMTP extension model
introduced in RFC 1425 and eventually incorporated into RFC 2831
and 5321 would have been a much better example for Russ to use.
For multiple reasons, I _really_ would not recommend it but, in
theory, you could do what you are after while minimizing
rejections with syntax errors by inventing an "NLPP"
(null-local-parts-permitted) SMTP extension and seeing who
accepts it.  You can infer many of the reasons why that would be
a bad idea from Russ's note.

   john


--On Friday, February 17, 2023 17:26 -0500 John C Klensin
<[e-mail]> wrote:

> Russ,
> 
> At least IMO, excellent explanation.
> 
> Scott, 
> 
> If I understand what you are trying to accomplish, there is
> another way it could be done without any of the disruptions or
> complexities Russ and Dave identified.  Define a special "role"
> address akin to "Postmaster" (in RFC 5321), the suggestions of
> RFC 763, or the more detailed specification and useful analysis
> in RFC 2142.  Give it a mnemonic name with reasonable odds of
> not being confused with a conventional user name, e.g.,
> "EveryoneAt" or "AllUsersAt".  Then see if you can persuade
> people running SMTP Servers for domains of interest to treat
> those role addresses as distribution addresses for all such
> users (or any group of users they might select -- I'm thinking
> about local opt-out rules here).
> 
> That would give you something almost completely non-disruptive.
> It would conform to existing syntax rules and would did not
> require any changes in existing mail protocols or to systems
> sending or relaying mail messages.  Receiving systems that got
> such a message would either handle as you specify, treat it as
> undeliverable, of, if the sender were unlucky, deliver it to a
> mailbox of that name (the reason for "not being confused" above
> -- I wouldn't want to use "alice" or "bob" for that address
> convention.  If you found yourself getting any traction at all,
> I'd recommend a really short RFC updating RFC 2142 to include
> this additional type of name and the name itself and have
> trouble imagining anyone violently objecting.
> 
> If there is some reason to not do that, I believe your document
> is probably in need of a section explaining what it is.
> 
> best,
>   john
> 
> 
> 
> 
> --On Friday, February 17, 2023 13:45 -0800 Russ Allbery
> <[e-mail]> wrote:
> 
>> Scott Antipa <[e-mail]> writes:
>> 
>>> As Dave mentioned to me, this is of course a gigantic change
>>> which would require changes to all the parsers out there in
>>> the wild. I'm not expecting to just get a thumbs up here
>>> immediately. But I'd like to spark a conversation and get
>>> feedback.
>> 
>> Talking to standards bodies is often depressing since mostly
>> they tell you all the things your idea will break.  :)
>> 
>> I think there are two ways of interpreting your idea.  One is
>> to provide some sort of address-book lookup feature that would
>> allow people to use bare domains in email clients, and the
>> email client would then convert that to a traditional email
>> message.  I have no strong opinions about that; as a purely
>> client feature, it would have no affect on the protocol. It's
>> "just" a UI change to email clients from the perspective of
>> the email standards such as SMTP, although there would
>> probably need to be some ancillary standards defined around it
>> for how email clients should convert domain names into email
>> addresses.
>> 
>> The other way is to interpret the proposal as a proposal for a
>> syntax change to the email address in the SMTP and email
>> message format protocols.  I'm not sure there's much feedback
>> people are going to be able to give you on that version of
>> your proposal other than "making this significant of a change
>> to email protocols is effectively impossible."
>> 
>> The installed base of software that parses and manipulates
>> email messages is almost undescribably huge, and this sort of
>> fundamental syntax change will break a large amount of it.
>> Most of it is never updated even to deal with major ongoing
>> issues when the changes are minor.  This sort of very
>> fundamental change to a basic syntax element seems essentially
>> certain to stall out at a very small percentage of the
>> software in use, and thus never become usable in practice.
>> 
>> It's going to be vastly easier to work with the existing email
>> address syntax, using one of the short email patterns you
>> already see today ([e-mail] or [e-mail] or
>> whatever).
>> 
>> Email message format is unusually difficult to modify in this
>> sort of way even by the standards of IETF protocols because
>> it's a network store and forward protocol rather than a
>> point-to-point protocol.  You can't negotiate a new message
>> format between just the sender and the recipient; every
>> intermediate server through which the message passes has an
>> opinion about the syntax of the email address.  So even if you
>> could change SMTP to support this format by introducing a new
>> version similar to what HTTP did with HTTP/2 (and it would
>> require that level of effort to change the syntax of the email
>> address, since it's so foundational), you still can't
>> practically change the message format without introducing a
>> truly enormous gatewaying and down-conversion problem.
>> 
>> I think a comparable change would be MIME, which introduced
>> structured email and non-ASCII character sets, and that change
>> took decades to be reliably usable (one could argue that it's
>> still not 100% reliable) despite a use case that was necessary
>> to solve for email to continue to be relevant at all.  And in
>> a way this change as stated would be even more disruptive than
>> the introduction of MIME, since MIME remained
>> backward-compatible in header formats (although old software
>> would see encoded nonsense in some cases).
>