Re: Make username optional in email addresses
Scott Antipa <[email protected]> Fri, 17 Feb 2023 14:48:34 -0800
| Newsgroups | gmane.ietf.smtp |
|---|---|
| Message-ID | <CAG6nNWeBm-2tSFMhAATatKNUejyQOAfx6tdZzkv3DjdomA7Atw@mail.gmail.com> |
--===============4211731679302154534== Content-Type: multipart/alternative; boundary="0000000000009c42ef05f4ed1d47" --0000000000009c42ef05f4ed1d47 Content-Type: text/plain; charset="UTF-8" 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 [email protected]. 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 <[email protected]> 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 [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). > > > > > --0000000000009c42ef05f4ed1d47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">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 <a href=3D"http://scottantipa.com">scottantipa.com</a> as my email = address instead of <a href=3D"mailto:[email protected]">scott@scottanti= pa.com</a>.</div><div dir=3D"auto"><br></div><div dir=3D"auto">=C2=A0Althou= gh 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.</div><div><br><div class=3D"gmail_quote"><div dir= =3D"ltr" class=3D"gmail_attr">On Fri, Feb 17, 2023 at 2:38 PM John C Klensi= n <<a href=3D"mailto:[email protected]">[email protected]</a>> wrote:= <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex">Sorry, should have added that, if = you are interested in mail to<br> domain owners rather than mail to everyone using the domain, you<br> could think about a role address/ keyword for that too.=C2=A0 "OWNER&q= uot;<br> or "DomainOwner" come to mind.=C2=A0 That would have an added<br> advantage: distinguishing between <a href=3D"mailto:[email protected]" targ= et=3D"_blank">[email protected]</a> and<br> <a href=3D"mailto:[email protected]" target=3D"_blank">AllAddresse= [email protected]</a> would avoid the ambiguity as to which<br> one was intended by @<a href=3D"http://example.com" rel=3D"noreferrer" targ= et=3D"_blank">example.com</a>.<br> <br> And, fwiw, I agree with Dave.=C2=A0 The SMTP extension model<br> introduced in RFC 1425 and eventually incorporated into RFC 2831<br> and 5321 would have been a much better example for Russ to use.<br> For multiple reasons, I _really_ would not recommend it but, in<br> theory, you could do what you are after while minimizing<br> rejections with syntax errors by inventing an "NLPP"<br> (null-local-parts-permitted) SMTP extension and seeing who<br> accepts it.=C2=A0 You can infer many of the reasons why that would be<br> a bad idea from Russ's note.<br> <br> =C2=A0 =C2=A0john<br> <br> <br> --On Friday, February 17, 2023 17:26 -0500 John C Klensin<br> <<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= m</a>> wrote:<br> <br> > Russ,<br> > <br> > At least IMO, excellent explanation.<br> > <br> > Scott, <br> > <br> > If I understand what you are trying to accomplish, there is<br> > another way it could be done without any of the disruptions or<br> > complexities Russ and Dave identified.=C2=A0 Define a special "ro= le"<br> > address akin to "Postmaster" (in RFC 5321), the suggestions = of<br> > RFC 763, or the more detailed specification and useful analysis<br> > in RFC 2142.=C2=A0 Give it a mnemonic name with reasonable odds of<br> > not being confused with a conventional user name, e.g.,<br> > "EveryoneAt" or "AllUsersAt".=C2=A0 Then see if yo= u can persuade<br> > people running SMTP Servers for domains of interest to treat<br> > those role addresses as distribution addresses for all such<br> > users (or any group of users they might select -- I'm thinking<br> > about local opt-out rules here).<br> > <br> > That would give you something almost completely non-disruptive.<br> > It would conform to existing syntax rules and would did not<br> > require any changes in existing mail protocols or to systems<br> > sending or relaying mail messages.=C2=A0 Receiving systems that got<br= > > such a message would either handle as you specify, treat it as<br> > undeliverable, of, if the sender were unlucky, deliver it to a<br> > mailbox of that name (the reason for "not being confused" ab= ove<br> > -- I wouldn't want to use "alice" or "bob" for= that address<br> > convention.=C2=A0 If you found yourself getting any traction at all,<b= r> > I'd recommend a really short RFC updating RFC 2142 to include<br> > this additional type of name and the name itself and have<br> > trouble imagining anyone violently objecting.<br> > <br> > If there is some reason to not do that, I believe your document<br> > is probably in need of a section explaining what it is.<br> > <br> > best,<br> >=C2=A0 =C2=A0john<br> > <br> > <br> > <br> > <br> > --On Friday, February 17, 2023 13:45 -0800 Russ Allbery<br> > <<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= rg</a>> wrote:<br> > <br> >> Scott Antipa <<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>> writes:<br> >> <br> >>> As Dave mentioned to me, this is of course a gigantic change<b= r> >>> which would require changes to all the parsers out there in<br= > >>> the wild. I'm not expecting to just get a thumbs up here<b= r> >>> immediately. But I'd like to spark a conversation and get<= br> >>> feedback.<br> >> <br> >> Talking to standards bodies is often depressing since mostly<br> >> they tell you all the things your idea will break.=C2=A0 :)<br> >> <br> >> I think there are two ways of interpreting your idea.=C2=A0 One is= <br> >> to provide some sort of address-book lookup feature that would<br> >> allow people to use bare domains in email clients, and the<br> >> email client would then convert that to a traditional email<br> >> message.=C2=A0 I have no strong opinions about that; as a purely<b= r> >> client feature, it would have no affect on the protocol. It's<= br> >> "just" a UI change to email clients from the perspective= of<br> >> the email standards such as SMTP, although there would<br> >> probably need to be some ancillary standards defined around it<br> >> for how email clients should convert domain names into email<br> >> addresses.<br> >> <br> >> The other way is to interpret the proposal as a proposal for a<br> >> syntax change to the email address in the SMTP and email<br> >> message format protocols.=C2=A0 I'm not sure there's much = feedback<br> >> people are going to be able to give you on that version of<br> >> your proposal other than "making this significant of a change= <br> >> to email protocols is effectively impossible."<br> >> <br> >> The installed base of software that parses and manipulates<br> >> email messages is almost undescribably huge, and this sort of<br> >> fundamental syntax change will break a large amount of it.<br> >> Most of it is never updated even to deal with major ongoing<br> >> issues when the changes are minor.=C2=A0 This sort of very<br> >> fundamental change to a basic syntax element seems essentially<br> >> certain to stall out at a very small percentage of the<br> >> software in use, and thus never become usable in practice.<br> >> <br> >> It's going to be vastly easier to work with the existing email= <br> >> address syntax, using one of the short email patterns you<br> >> already see today (<a href=3D"mailto:[email protected]" target=3D"_b= lank">[email protected]</a> or <a href=3D"mailto:[email protected]" target=3D= "_blank">[email protected]</a> or<br> >> whatever).<br> >> <br> >> Email message format is unusually difficult to modify in this<br> >> sort of way even by the standards of IETF protocols because<br> >> it's a network store and forward protocol rather than a<br> >> point-to-point protocol.=C2=A0 You can't negotiate a new messa= ge<br> >> format between just the sender and the recipient; every<br> >> intermediate server through which the message passes has an<br> >> opinion about the syntax of the email address.=C2=A0 So even if yo= u<br> >> could change SMTP to support this format by introducing a new<br> >> version similar to what HTTP did with HTTP/2 (and it would<br> >> require that level of effort to change the syntax of the email<br> >> address, since it's so foundational), you still can't<br> >> practically change the message format without introducing a<br> >> truly enormous gatewaying and down-conversion problem.<br> >> <br> >> I think a comparable change would be MIME, which introduced<br> >> structured email and non-ASCII character sets, and that change<br> >> took decades to be reliably usable (one could argue that it's<= br> >> still not 100% reliable) despite a use case that was necessary<br> >> to solve for email to continue to be relevant at all.=C2=A0 And in= <br> >> a way this change as stated would be even more disruptive than<br> >> the introduction of MIME, since MIME remained<br> >> backward-compatible in header formats (although old software<br> >> would see encoded nonsense in some cases).<br> > <br> <br> <br> </blockquote></div></div> --0000000000009c42ef05f4ed1d47-- --===============4211731679302154534== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ietf-smtp mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-smtp --===============4211731679302154534==--