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.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
