On Fri 11/Feb/2022 19:25:15 +0100 John Levine wrote:
It appears that Alessandro Vesely <[email protected]> said:
I think it is already clear to the WG that the tree walk is screwed up.
Yes, we know we have to rewrite sections 4.5 and 4.6.
I think there are 2 1/2 situations we need to look at.
The first is finding the policy record for a domain that does not have its own DMARC
record. That seems easy, walk up five levels and stop at the first DMARC record,
which is your policy record. For this purpose it doesn't matter whether the domain
says psd=y. I suppose that it if doesn't have psd=y, you can call the domain with the
record the org domain.
More or less agreed.
The second is deciding whether two different domains are in relaxed alignment. This has
an easier case and a harder one.
The easier case is when one domain is a subdomain of the other. You look at the domains
between the two and they are in relaxed alignment if one of these is true but I'm not
sure which one:
a. there are no DMARC records at all
b. there are no DMARC records with psd=y
I don't think there is a lot of practical difference between the two. If you don't find
a record, there is no policy and no org domain.
Yes, I think we can relay on PSD domains not publishing DKIM or SPF stuff.
The harder case when the domains are siblings, or maybe a great aunt.
Possibilities:
a. they are never aligned. This would be the easiest, but would in principle be a significant
change from the current spec. Does anyone know in practice how often mail uses sibling alignment?
b. walk up from both, stop at the first DMARC record. If they're at
the same name and it's not a PSD, they are aligned and that's the org domain
b+. walk up from both, if the DMARC records are at the same name, it has psd=y, and they have the
same name below the PSD, they are aligned and the name below the PSD is the org domain
c and c+. like b or b+ but allow other non-PSD DMARC records below the org
domain.
I'd avoid walking up from both, because there are likely multiple identifiers,
typically SPF and DKIM. Walking up from each becomes burdensome. This leaves
pretty much only a. However, why not continue the walk upward? The topmost
domain having a DMARC record is the Organizational Domain.
In a few cases, the domain thus found can happen to be a PSD. If there is
psd=y, the plan in Section 4.6. works fine. Until that flag is not reliable,
we need to apply specific knowledge. To this end, note that the list of
domains at psddmarc.org is much much shorter and more easily maintainable than
the PSL.
If flags are not reliable, a tree walk without extra knowledge or heuristics is
not going to work in any case. OTOH, if one day flags become reliable, we will
have put a mark where DBOUND failed.
I lean toward "a" if we believe that sibling alignment is rarely used, otherwise b. I don't like b+ or c+ because
I think it is reasonable to expect mailers who depend on an org domain to publish a record there, although I do not
think an org=y flag would be useful, since it would break existing org domain records that don't have the flag.
Finding org=y saves one or more extra lookups. The org domain is determined
even without that flag, albeit at an extra cost. Perhaps more importantly,
org= allows a subdomain to claim independence from its parent domain.
To put it more analytically, psd= and org= correspond to different ways to
apply DMARC, with respect to both determining the alignment and feedback
reporting. Mail filters must ascertain which role a domain plays, whether
declared or not. Then, it is false to assume that psd=n ==> org=y, as org's
subdomains may exist. It could even make sense to define sub=y.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
