David's goal for the name registration is different from what Verisign intended. Here is what I have inferred:
Verisign wants to sell personal identity PKI certificates to the masses, for use with S/MIMIE. A personal PKI certificate requires a subject name and an owner email address. "first.last.name" becomes the subject name, and "fi...@last.name" becomes the email certificate. This is a much better solution than requiring the consumer to get a different PKI certificate every time that they change hosting services. It also gives Verisign a name space under their own control, so that the certificate's legitimacy is easier to protect. S/MIME signatures do not have to match the From address or Mail From address of the email message that contains, they just have to be recognizable and trusted by the person receiving the message. This allows the "first.last.name" certificate to be used inside a message from " someb...@hostingservice.com" So the fi...@last.name email address is just part of the control system for the PKI certificate, and is not intended for general use. As John observed, there is no way to provide outbound authentication for these addresses, because authentication is based on domain name (and changing that would take 100 years to deploy.) m...@smith.name and jos...@smail.name are likely to be using different message sending systems. So any SPF or DKIM mechanism used to authenticate Mary's mail could be used as a weapon to attack Joseph's mail. Since the addresses cannot be authenticated, they should not be used for outbound mail. A recipient who understands this situation would be wise to block any incoming messages coming from the .name TLD. Doug Foster On Tue, May 31, 2022 at 3:51 PM David Bustos <da...@bustos.name> wrote: > On Tue, May 31, 2022, at 1:33 PM, John R Levine wrote: > > On Tue, 31 May 2022, David Bustos wrote: > >>> Forwarding is pretty broken these days. Even if you had perfect SPF, > a lot of your incoming > >>> mail would fail DMARC because a lot of DMARC policies depend on SPF > and SPF can't deal with forwarded mail. > >> > >> I'm talking about outgoing mail, not incoming mail. > > > > Are you talking about mail you send, or mail sent to your bustos.name > > address that's forwarded to a mailbox somewhere else? > > Mail that I send to other people, with da...@bustos.name as the from > address. Yahoo and Gmail sometimes direct it to spam. I presume it is > because bustos.name doesn't have an SPF record. > > >>> I'm not surprised. The registry contract with ICANN forbids it. > >> > >> Is the contract available for me to read? > > > > It's the standard registry contract on the ICANN web site. > > Does the contract forbid publication of MX records? Verisign does that. > > >> This special case was committed to by TLD regulators back in 2002 and > it is a problem for everyone with a third level .name domain. That's > probably not many people, but the current situation is inconsistent so I am > trying to figure out if any increases in consistency are possible. > >> > >> Yes, if no changes are possible then I may need to abandon > da...@bustos.name . > > > > Looks that way. > > Is your position that Verisign should publish SPF records for the .name > domains? > > > David > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
