On Thursday, February 24, 2022 3:36:18 AM EST Alessandro Vesely wrote: > On Wed 23/Feb/2022 19:55:35 +0100 Scott Kitterman wrote: > > On Wednesday, February 23, 2022 1:25:50 PM EST John Levine wrote: > >> It appears that Scott Kitterman <[email protected]> said: > >>>Leaving that aside, then I think it's: > >>> > >>>1. Lookup DMARC record for the 5322.From domain. If found, that's the > >>>policy. > >>> > >>>2. Walk up from up to 5 levels in the DNS hierarchy and the last > >>> > >>> (shortest) non-PSD DMARC record you find is the org. > >>> > >>>I think that matches the RFC 7489 discovery approach, just not using PSL. > >>>Is that right? > > It looks right, except for non-flagged PSDs. > > However, what if you find no DMARC record at step 1? For compatibility with > RFC 7489, I guess you imply that the policy is taken from the org domain. > >> I prefer the first (longest) but could live with the last if people think > >> that will in practice be less surprising. I do worry about foo.us.com vs > >> bar.us.com. > > > > I think it will (less surprising). Currently if you have a.b.bar.us.com > > and "a" and "b" need different policies you can just publish them. If > > you stop at the first one, then b.bar.us.com would be identified as the > > org domain for a.b.bar.us.com vice bar.us.com. > > > > This could be problematic. The RFC 7489 definition of relaxed alignment > > says that the From org domain and the DKIM/SPF org domain have to be the > > same to be aligned. > > > > A specific example: > > > > A business (example.com) uses subdomains for particular business units and > > allows them to run their own email infrastructure if needed. One > > particular business unit (bu.example.com) uses a large number of third > > party providers with a dedicated mail from for each to avoid restrictions > > associated with SPF DNS lookup limits. It sends mail from (among others) > > ext1.bu.example.com and ext2.bu.example.com with from and signing domain > > of bu.example.com. Because this business unit has decided to accept the > > risks associated with a DMARC reject policy and the company as a whole > > has not, it publishes its own DMARC record at _dmarc.bu.example.com. Of > > course, .com is in the PSL, so the org domain is example.com under RFC > > 7489 rules. > > > > In this example, under RFC 7489 rules, ext1.bu.example.com, > > ext2.bu.example.com, and bu.example.com all meet the requirements for > > relaxed alignment because the org domain for all three is example.com. > > > > Using the proposed tree walk approach, it matters if you take the first > > DMARC record or the last one. > > > > ext1: no dmarc > > bu: dmarc, p=reject, sp=reject > > example: dmarc, p=none, sp=none > > com: no dmarc > > I like this example. Let's leave the alignment question for a moment, and > consider policy. Mail from [email protected], according to the plan > above, goes with p=none. That agrees with the PSL. > > Can we be more accurate than the PSL? Yes, we can, since we read the record > at bu.example.com. > > > If you walk up the tree and take the first DMARC record you hit, then the > > org domain for ext1.bu.example.com is bu.example.com and the org domain > > for bu.example.com is example.com. They don't match, so there is no > > alignment. > > > > If you take the last non-PSD DMARC record then the org domain for > > ext1.bu.example.com is example.com and the org domain for bu.example.com > > is > > example.com and they meet the requirements for relaxed alignment. > > Allowing bu.example.com to publish org=y would make both identifiers aligned > to bu.example.com. However, we could also devise flags so as to override > the policy but keep the alignment. > > I don't know why you dismiss possible enhancements as if psd=y were already > standard. Of course, users of legacy software won't deploy new > enhancements. That is, org=y would initially not be honored by the majority > of receiving servers. That's normal. OTOH, a change which implies issuing > more DNS queries just to get a slightly worse quality than the PSL —due to > missing psd=y flags— is not really so attractive.
I think using psd=n, so we don't need to define yet another new tag, as discussed in another branch of this thread, accomplishes what you are suggesting. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
