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?
> 
> 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.

DKIM (7489 3.1.1):

>    In relaxed mode, the Organizational Domains of both the [DKIM]-
>    authenticated signing domain (taken from the value of the "d=" tag in
>    the signature) and that of the RFC5322.From domain must be equal if
>    the identifiers are to be considered aligned.

SPF (7489 3.1.2):

>    In relaxed mode, the [SPF]-authenticated domain and RFC5322.From
>    domain must have the same Organizational Domain.

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

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.

This may seem convoluted, but I have seen pretty much this exact setup in use 
by large organizations.

We could fix this by changing the definition of relaxed alignment to be is the 
same or one is a subdomain of the other, but I think it's better to take the 
last DMARC record and leave the definition as is.

Scott K




_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to