Re: Make username optional in email addresses
Tim Wicinski <[email protected]> Wed, 22 Feb 2023 15:51:48 -0500
| Newsgroups | gmane.ietf.smtp |
|---|---|
| Message-ID | <CADyWQ+FMF6aQk_7VEfpHrbJDaTR98atNydP+9DfHiZaB1VSKjQ@mail.gmail.com> |
--===============6672073527339850220== Content-Type: multipart/alternative; boundary="00000000000041a6c505f5501122" --00000000000041a6c505f5501122 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Scott I have some domains where I would not mind the *@example.com, but most of them I have a curated list of addresses I want to receive mail to, and the rest can go away. I'm curious where folks think the usage level would be. tim On Wed, Feb 22, 2023 at 3:46 PM Scott Antipa <[email protected]> wrote: > I was thinking this would be a single special email per domain, eg =E2=80= =9C > [email protected]=E2=80=9D or whatever. Does that address the scaling = problem? > > On Fri, Feb 17, 2023 at 6:25 PM John C Klensin <[email protected]> wrote: > >> >> >> --On Friday, February 17, 2023 17:30 -0500 tjw ietf >> <[email protected]> wrote: >> >> > Speaking as a simple dns person >> > >> > _role.example.com TXT [email protected] >> > >> > Is my fuel for the discussion >> >> Tim, >> >> There are at least three issues there (or with something similar >> using SRV records). >> >> One, which may not apply to the smaller, more personal, domains >> I think Scott is most concerned about, is that sometimes the >> process of modifying a DNS record involves different people >> and/or procedures than modifying an email delivery MTA. >> >> Second, it is typically going to means three DNS lookups to >> identify an email address and where to send it, one for the >> _role record as shown, one to get the MX record(s) for the >> target domain, and, unless one gets lucky and the addresses of >> the servers identified in the MX records show up as additional >> information, a third (or more) to retrieve the addresses for >> that server or servers. >> >> And third, as I think was mentioned in another context, every >> time that someone has proposed something that might involve a >> DNS entry per person rather than per host or pseudo-host, the >> conclusion has been that it would not scale properly. Now >> Scott's situation may be a bit different because I think he is >> thinking about one email address per domain (or, if there were, >> using the terminology of my earlier note, an "owner" and an >> "all" one, two). That might therefore not trigger the scaling >> problem. But, still... >> >> Whether one did it with a special name and DNS entry or a "role" >> email address, I think the problem is the same" either the user >> or the originating MUA needs to understand the naming or RR >> convention and how to use it. Then, with Scott's proposal, the >> delivery server and everything in between need to understand a >> now-prohibited address and the delivery server needs to >> understand what it means. With my "owner" suggestion, the >> delivery server has to have an alias for the correct/target >> address (not unlike the usual treatment for "Postmaster"); with >> yours the address on the wire is actually the target address. >> >> And, Scott, please pay attention to Nathaniel's comment. Many >> of us who "own" dedicated domains of which we are the only >> important user use a multitude of email addresses to organize >> materials, set up special security mechanisms, and so on. I >> don't know about Nathaniel, but I use subaddress mechanisms and >> probably use hundreds of different addresses. Some get special >> post-delivery routing, others don't, and the rules change >> frequently (in my case, it is rare for a week to go by without >> my making at least one internal or routing or classification >> change). For us, "[email protected]" or "[email protected]" >> would be just one more of those specialized addresses to put in >> the relevant tables, tables that we need to maintain anyway. >> Keeping in mind that "@gmail" would almost certainly either have >> to be rejected or treated as a synonym for something >> Postmaster-like and that at least some of the cases of >> @personaldomain.example would be used as Nathaniel and I use >> them, it is not clear to me that there would actually be >> significant demand for "@example.com" even if you could get it >> adopted. >> >> best, >> john >> >> --00000000000041a6c505f5501122 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac= e">Scott</div><div class=3D"gmail_default" style=3D"font-family:monospace">= <br></div><div class=3D"gmail_default" style=3D"font-family:monospace">I ha= ve some domains where I would not mind the *@<a href=3D"http://example.com"= >example.com</a>, but most of them I have a curated list of addresses I wan= t to receive mail to, and the rest can go away.=C2=A0 I'm curious where= folks think the usage level would be.=C2=A0</div><div class=3D"gmail_defau= lt" style=3D"font-family:monospace"><br></div><div class=3D"gmail_default" = style=3D"font-family:monospace">tim</div><div class=3D"gmail_default" style= =3D"font-family:monospace"><br></div></div><br><div class=3D"gmail_quote"><= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 22, 2023 at 3:46 PM Scott = Antipa <<a href=3D"mailto:[email protected]">[email protected]</= a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p= x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d= iv dir=3D"auto">I was thinking this would be a single special email per dom= ain, eg =E2=80=9C<a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a>=E2=80=9D or whatever. Does that address the scalin= g problem?</div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class= =3D"gmail_attr">On Fri, Feb 17, 2023 at 6:25 PM John C Klensin <<a href= =3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>> w= rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> <br> --On Friday, February 17, 2023 17:30 -0500 tjw ietf<br> <<a href=3D"mailto:[email protected]" target=3D"_blank">tjw.ietf@gmail.= com</a>> wrote:<br> <br> > Speaking as a simple dns person<br> > <br> > _<a href=3D"http://role.example.com" rel=3D"noreferrer" target=3D"_bla= nk">role.example.com</a> TXT <a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a><br> > <br> > Is my fuel for the discussion <br> <br> Tim,<br> <br> There are at least three issues there (or with something similar<br> using SRV records).=C2=A0 <br> <br> One, which may not apply to the smaller, more personal, domains<br> I think Scott is most concerned about, is that sometimes the<br> process of modifying a DNS record involves different people<br> and/or procedures than modifying an email delivery MTA.=C2=A0 <br> <br> Second, it is typically going to means three DNS lookups to<br> identify an email address and where to send it, one for the<br> _role record as shown, one to get the MX record(s) for the<br> target domain, and, unless one gets lucky and the addresses of<br> the servers identified in the MX records show up as additional<br> information, a third (or more) to retrieve the addresses for<br> that server or servers.<br> <br> And third, as I think was mentioned in another context, every<br> time that someone has proposed something that might involve a<br> DNS entry per person rather than per host or pseudo-host, the<br> conclusion has been that it would not scale properly.=C2=A0 Now<br> Scott's situation may be a bit different because I think he is<br> thinking about one email address per domain (or, if there were,<br> using the terminology of my earlier note, an "owner" and an<br> "all" one, two).=C2=A0 That might therefore not trigger the scali= ng<br> problem.=C2=A0 But, still...<br> <br> Whether one did it with a special name and DNS entry or a "role"<= br> email address, I think the problem is the same" either the user<br> or the originating MUA needs to understand the naming or RR<br> convention and how to use it.=C2=A0 Then, with Scott's proposal, the<br= > delivery server and everything in between need to understand a<br> now-prohibited address and the delivery server needs to<br> understand what it means.=C2=A0 With my=C2=A0 "owner" suggestion,= the<br> delivery server has to have an alias for the correct/target<br> address (not unlike the usual treatment for "Postmaster"); with<b= r> yours the address on the wire is actually the target address.<br> <br> And, Scott, please pay attention to Nathaniel's comment.=C2=A0 Many<br> of us who "own" dedicated domains of which we are the only<br> important user use a multitude of email addresses to organize<br> materials, set up special security mechanisms, and so on.=C2=A0 =C2=A0I<br> don't know about Nathaniel, but I use subaddress mechanisms and<br> probably use hundreds of different addresses.=C2=A0 Some get special<br> post-delivery routing, others don't, and the rules change<br> frequently (in my case, it is rare for a week to go by without<br> my making at least one internal or routing or classification<br> change).=C2=A0 For us, "<a href=3D"mailto:[email protected]" target=3D= "_blank">[email protected]</a>" or "<a href=3D"mailto:everyone@ex= ample.com" target=3D"_blank">[email protected]</a>"<br> would be just one more of those specialized addresses to put in<br> the relevant tables, tables that we need to maintain anyway.<br> Keeping in mind that "@gmail" would almost certainly either have<= br> to be rejected or treated as a synonym for something<br> Postmaster-like and that at least some of the cases of<br> @personaldomain.example would be used as Nathaniel and I use<br> them, it is not clear to me that there would actually be<br> significant demand for "@<a href=3D"http://example.com" rel=3D"norefer= rer" target=3D"_blank">example.com</a>" even if you could get it<br> adopted.<br> <br> best,<br> =C2=A0 =C2=A0john<br> <br> </blockquote></div></div> </blockquote></div> --00000000000041a6c505f5501122-- --===============6672073527339850220== 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 --===============6672073527339850220==--