On Fri 21/Jan/2022 15:28:07 +0100 John R Levine wrote:
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.
Sorry, but that is simply false. The entire "private domains" part of the PSD
is self-appointed PSDs.
Not all of them have write access to https://github.com/publicsuffix/list
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.
Yes, that is the plan. Please go back and look at the discussion when we
talked about the tree walk in the first place.
I don't remember that we ever convene that subdomains cannot override the org
domain record.
That is, doing their own DKIM.
Sorry, that makes no sense. Everyone always does their own DKIM.
Nope. Lots of senders outsource DKIM signing. In the above example, it is
clear that c.example.com has its message signed by a.b.example.com. Let me
recall it:
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"
Now, since b.example.com needs to override the DMARC policy of example.com,
they also have to reconsider their mailout arrangements in order to DKIM sign
their messages by themselves.
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.
Um, the whole point of the tree walk is so we do not use the PSL, which has all
sorts of well known problems we've already discussed at length.
That's why I said "personally". I haven't yet thought how to modify my mail
filter (also because tree walk hasn't been specified yet). I don't think I'll
change policy discovery on the day the RFC gets published, and even if I did, I
don't think both users will immediately upgrade, and I guess several DMARC
filters are in the same condition. I hope the tree walk will be specified in a
compatible way.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
