Re: Make username optional in email addresses

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 [email protected] and
[email protected] 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
<[email protected]> 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
> <[email protected]> wrote:
> 
>> Scott Antipa <[email protected]> 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 ([email protected] or [email protected] 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).
>