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

[Scott Antipa <[e-mail]>]

For the desired effect is to have an email sent to a bare domain address to
go to one inbox. Its just another email address like any other, nothing
special. My initial use case is for personal websites so I can use
scottantipa.com as my email address instead of [e-mail].

 Although I do agree that starting with some kind of keyword approach and
letting the servers handle that special case could be a way to get the ball
rolling in the right direction.

On Fri, Feb 17, 2023 at 2:38 PM John C Klensin <[e-mail]> wrote:

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