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

[Russ Allbery <[e-mail]>]

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

-- 
Russ Allbery ([e-mail])             <https://www.eyrie.org/~eagle/>