On Fri 21/Jan/2022 05:29:05 +0100 John Levine wrote:
It appears that Alessandro Vesely <ves...@tana.it> said:
On Wed 19/Jan/2022 19:38:15 +0100 John Levine wrote:
What I always intended with the tree walk is that you walk up the tree and if
you find
a DMARC record that isn't a PSD, that's your org domain. To see if two names
are in relaxed
alignment, do a tree walk for both and if they end at the same place, they're
aligned. As
a special case albeit a very common one, if one name is a descendant of the
other, and there
are no DMARC records in between, they're aligned.
Why would a DMARC record in between invalidate the alignment?
For the same reason the PSL has a lot of two- and three-label domains.
Except that the PSL is somehow vetted; that is, there are no self-appointed
PSDs. Anyway, b.example.com below exhibits no psd=y tag...
DKIM-Signature: d=a.b.example.com [...]
From: j...@c.example.com
_dmarc.example.com IN TXT "v=DMARC1; p=reject;"
_dmarc.b.example.com. IN TXT "v=DMARC1; p=none; inbetween=y"
Is that aligned?
No, the org domain for c.example.com is example.com, while
the org domain for a.b.example.com is b.example.com.
If we specify it that way, we need to warn users about the effects that
publishing a DMARC record involves. Users of b.example.com need to know that
they cannot override the DMARC policy of their org domain unless they want to
become the org domain of the whole subtree. That is, doing their own DKIM.
I suppose we could try and invent rules that say only records with
the PSD flag prevent alignment, but then the description of the tree
walk becomes much more complicated and the tree walk gets longer and
slower and I don't see what actual problem that would solve.
Or we could use a multi-valued tag instead of psd=. For example role=X, where
X can be any of psd, org or sub.
In your model, when doing a tree walk from a.b.example.com, how do you
know not to stop at b.example.com? Do you always do five levels and use
the one highest up the tree or what?
Personally, I'd consult the PSL if I find no role= tag. Or I could do one more
query for _dmarc.com to understand the role of the last record found.
Let's consider that we have a number of settled DMARC filters based on PSL,
along with an installed base of DMARC records, which we shouldn't throw away.
The specification of the tree walk has to strive for compatibility.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc