On Wednesday, March 16, 2022 11:02:00 PM EDT John Levine wrote:
> It appears that Scott Kitterman  <[email protected]> said:
> >It took a fair amount of editing and I expect you all will have further
> >suggestions, so instead of getting up to my elbows in XML, I took the
> >published DMARCbis-05 text and updated it directly.  The modified version
> >and an rfcdiff are attached.
> 
> It's closer, but I think it still needs some reorganization.  I think this
> is where we want to end up:
> 
> Policy domain: if a domain has a dmarc record, that's the policy, otherwise
> use the org domain's policy or if no org domain policy, PSD policy.
> 
> You need to find org domains if
> a) the domain has no DMARC record so you use the org domain's instead, OR
> b) the DKIM domain doesn't match the from header domain and policy adkim=r.
> OR c) the SPF domain doesn't match the from header domain and policy
> aspf=r.
> 
> To find the org domain for a domain:
>   chop the domain to the last five labels and walk up the tree.
>   stop when you find a DMARC record with psd or you hit the root.
>   if a record has psd=n, that's the org domain
>   if a record has psd=y and it isn't the original domain, the org domain is
> the one below it otherwise the org domain is the last (highest) DMARC
> record you found
> 
> Relaxed alignment doesn't change, if two domains have the same org domain,
> they're aligned.
> 
> Minor nit: if a name has two or more DMARC records, that's invalid so
> pretend it had none.

Thanks.  I think that makes sense.  Based on an offlist comment I got, I think 
it needs to say has an explicit psd=n in the record or something like that.  
Since psd=n is the default, it's implicitly true for any record that doesn't 
have psd=y in it.

I'll take another shot at it, but I'm unlikely to finish it tonight.

Scott K


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

Reply via email to