On Saturday, July 16, 2022 11:56:04 AM EDT Alessandro Vesely wrote: > On Sat 16/Jul/2022 17:34:24 +0200 John Levine wrote: > > It appears that Scott Kitterman <skl...@kitterman.com> said: > >> I think the proposed change is incorrect. To pick a real example, gov.uk > >> is a PSD with a DMARC record. It's one that I expect will add psd=y > >> once the tag is assigned. > >> > >> There is no benefit from preventing gov.uk from sending mail and having > >> it pass DMARC. We have discussed this concept before. With the draft > >> as it stands, even if gov.uk had psd=y in its DMARC record, if the > >> 5322.From, 5321.MailFrom, and DKIM d= were all gov.uk, uk.gov would be > >> the organizational domain. With your change there would be no > >> organizational domain determined and so nothing would align. Why would > >> we want to do that? > > > > I agree with Scott, and considered scenarios like this when I wrote the > > current text. > > > > A better example is uk.com which is a PSD, and has MX, SPF, and DMARC > > records. It already has an np= tag so I expect they'll add psd=y once > > it's in the registry. > No. Since there's a record, a tree walk for d=uk.com will determine > the organizational domain correctly based on point 3, with or without > the change proposed. That change, therefore, does not prevent a PSD > from sending DMARC-compliant mail. > > Instead, a tree walk starting at d=com would determine that com is the > organizational domain unless my change is accepted. (Yes I know that > d=com won't verify, that's not the point.)
No. You'll never get to step 3. In step 2 it says to stop if you find a DMARC record with psd=y and that the organizational domain is the one below the psd=y domain. In the case of uk.com (or gov.uk) there is no domain one below the psd=y domain, so step 2 yields no result and you never get to step 3. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
