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

Speaking as a simple dns person

_role.example.com TXT tjw.ietf@gmail.com

Is my fuel for the discussion 

Tim 

Sent from my iPhone

> On Feb 17, 2023, at 17:26, John C Klensin <john-ietf@jck.com> 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
> <eagle@eyrie.org> wrote:
> 
>> Scott Antipa <scottantipa@gmail.com> 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 (me@bobsmith.com or mail@bobsmith.com 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).
> 
> 
> _______________________________________________
> ietf-smtp mailing list
> ietf-smtp@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-smtp