Re: Make username optional in email addresses

Thanks, Dave!
Also Eliot Lear sent me the below when I first inquired:

> I think something like this may have been tried in the very early days of
the internet.  Have a look at RFC 1183, and the RP record in DNS.  It might
be possible to cause a query for that record to be made by a client when no
@ is present.  But the user interface would have to convert the domain to a
real email address at that time, lest too many things break.  That @ is
expected throughout the architecture.

On Fri, Feb 17, 2023 at 12:38 PM Dave Crocker <[email protected]> wrote:

> On 2/17/2023 12:26 PM, Scott Antipa wrote:
> > As Dave mentioned to me
>
> To prime the thread a bit more, here's the technical substance of the
> note I sent to Scott...
>
> > -------- Forwarded Message --------
> >
> > ...
> >
> > Less for convenience, and more for the ability to query the DNS for
> > person-specific information, there have periodically been suggestions
> > for a convention for turning a regular email address into a form that
> > can be used to query the DNS.  So, for example, permit
> > scottantipa.gmail.com as a query for per-user information. Clearly the
> > DNS has no problem with that, syntactically.  However the consensus
> > has been that it wouldn't scale very well.
> >
> > While the example you gave was for a simple, two-part domain name, the
> > construct has to work for any arbitrary domain name.  And it has to
> > work for potentially billions of users. DNS servers tend not to be
> > built to handle the resulting query rate.
> >
> > A consideration for any proposal is to have a clear and compelling
> > value proposition, which is likely to motivate developers, operators
> > and users.  The barrier is especially high for modifying an existing
> > service, because the modification generally needs to work in a way
> > that does not affect, or at least does not hurt, that installed base.
> >
> > What you are proposing needs to cause all email address parsers to
> > change.  Modifying the entire email infrastructure to support this
> > change is unlikely to happen, even with strong incentives -- take a
> > look at the decades-long delays that have occurred for DNSSec, DANE,
> > and IPv6, each of which has quite a strong value proposition.
> >
> > While your proposal has the intuitive appeal of a simplification, in
> > the example use you gave, the practical benefit of it seems small.
> > First, there is likely (almost) no current base of domain owners who
> > would benefit from the capability.  Even the small market niche of
> > technical folk who own domains typically want multiple email addresses
> > to work for the domains they own. Then balance this the global,
> > systems-level changes that would be needed to support it.
> >
> > Working through incentives and downsides is a hassle, especially in
> > the face of the enthusiasm that comes with thinking up a technical
> > proposal.  Worse is that it's a realm of guesses about human behavior.
> >
> > ...
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> mast:@[email protected]
>
> _______________________________________________
> ietf-smtp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>

_______________________________________________
ietf-smtp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-smtp