(Not about Phill's message in particular: his is just the most recent one to reply to.)
This was a fine topic to ask about, and the early discussion answered the initial questions -- and pointed out, correctly, that this isn't a DMARC issue. The continuing discussion is definitely out of scope for the working group. While I'm reluctant to ask people to stop a discussion that's relevant and interesting to some participants, and while I am, for now, not setting any hard lines, I'd like people to wrap this up and not prolong discussion on this list, so that we can get back to the work the group is chartered for. Thanks, Barry, as WG chair On Wed, Jun 1, 2022 at 11:17 AM Phillip Hallam-Baker <ph...@hallambaker.com> wrote: > > It looks like VeriSign has hit on the same solution to the personal PKI > problem that I have in the callsign registry and for the same reason: To get > around the problem that a certificate for al...@example.com doesn't work to > authenticate Alice unless she is the holder of example.com. > > Building out the registry co-extensive with the PKI removes the need to > validate the certificate requests for holdership of the domain because this > is established by definition. > > It also looks like they have hit the inevitable constraints from trying to > engage with the legacy SMTP installed base to make it do something different. > And I can't see that problem as having a good solution. SPF was not designed > to support the case where al...@example.com was in a different domain of > control to b...@example.com. The .name use case is not going to have nearly > enough of a user base to cause deployment of a proposed change to SPF to > solve the problem. > > The only approach I can see working is for .name to provide the inbound and > outbound mail services. Which given how SMTP works for inbound they must > surely do anyway. > > > > On Tue, May 31, 2022 at 11:14 PM Douglas Foster > <dougfoster.emailstanda...@gmail.com> wrote: >> >> 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 > > _______________________________________________ > 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
