On Tue 25/Jan/2022 06:56:26 +0100 Scott Kitterman wrote:
On Monday, January 24, 2022 10:15:49 PM EST Scott Kitterman wrote:
On January 25, 2022 12:46:48 AM UTC, John Levine <jo...@taugh.com> wrote:
It appears that Scott Kitterman <skl...@kitterman.com> said:
What I implemented is roughly:
For policy determination, first check the From domain, if that has a DMARC
record, then that's the policy domain. Otherwise, tree walk up to the
apex
looking for DMARC records. First domain you find with a record is policy
domain, use the policy (p=, sp=, np=) from that domain's DMARC record.
This matches my interpretation of dmarcbis-04.
For org domain determination (for alignment), if any of the records
retrieved during the policy search have psd=y, then add one more label
and that's the org domain (as written). From there it's anyone's guess.
Unlike John, I continued down the tree and made the first match the org
domain.
Seems reasonable. What's the point of going more than one level below the
PSD? Make it look more like a pure tree walk?
Yes. For consistency. You'd walk down until you hit a non-psd record or
the limit. Stopping at one more after the psd=y record is an optimization
for a relatively rare case of a PSD record. Other than that case you have
to keep going until you find a DMARC record or hit the limit, since there's
no knowing what's a PSD otherwise.
The attached change would solve the problem, at least to a first approximation.
The wording could be tightened up, but this is at least a complete
description.
I don't think "in the reverse order" makes much sense. Usually, I
don't walk downward on a DNS, so the meaning of "reverse" is not clear
to me. Phrases like "toward the root" or similar might be clearer.
Then, may I insist on having role=psd rather than psd=y? It can
better the heuristic.
Thanks
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
