On Mon, Apr 15, 2024 at 8:08 PM Douglas Foster <
[email protected]> wrote:

> Todd, can you clarify this?
>
> N is not concerned with maximum labels on a subdomain.   We are interested
> in the maximum length of an org domain used for relaxed alignment.
>
> If this client wants to use level 7 as an org domain and apply relaxed
> alignment for 8-label domains, then N needs to be 7.   If the client's
> lowest-desired org domain is at or above 4-labels, then N=4 is sufficient.
> Similarly, if the7-label domain only needs strict authentication, then N=7
> is not needed.
>
> Has this or another client genuinely chafed at the insufficient
> granularity of the old PSL?
>

My understanding of the Tree Walk is that in DMARCbis it is the defined
method for performing two separate jobs:

   - Discover the controlling DMARC policy record for the RFC5322.From
   domain in a given email message; this controlling DMARC policy will be
   found at either the RFC5322.From domain, the organizational domain for the
   RFC5322.From domain, or the PSD of the RFC5322.From domain.
   - Determine the organizational domains for the SPF domain,and the DKIM
   domain in a given email message, in order to determine whether the domains
   are in relaxed alignment with the RFC5322.From domain

As I wrote in an earlier message, we have data showing use of seven label
domains in the RFC5322.From domains; it's not a lot of data, but it's there.

So, in my current scenario with an RFC5322.From domain of a.b.c.d.e.f.tld,
DMARC Policy Discovery would be done by querying for these five (5) records:

   - _dmarc.a.b.c.d.e.f.tld
   - _dmarc.d.e.f.tld
   - _dmarc.e.f.tld
   - _dmarc.f.tld
   - _dmarc.tld

Let's imagine that the Domain Owner for f.tld publishes this DMARC record:

   - v=DMARC1; p=none; psd=n; rua=mailto:[email protected];

but they allow for distributed, rather than central, administrative
control, and therefore those who manage c.d.e.f.tld publish a DMARC record
like this:

   - v=DMARC1; p=reject; psd=n; rua=mailto:[email protected];

Perfectly valid configurations as DMARCbis is currently written. The
plausibility of same is unknown, but because RFC 7489 didn't contemplate
organizational domains as anything other than domains one level below the
domains on the PSL, it's not likely anyone ever tried to publish a DMARC
record at c.d.e.f.tld.

If we leave N at 5, the organizational domain and thus the intended DMARC
policy for a.b.c.d.e.f.tld won't be discovered, as it's published at
_dmarc.c.d.e.f.tld and that query will be skipped by the Tree Walk.

My argument therefore for N=8 is to support distributed policy settings for
RFC5322.From domains with eight or more labels and therefore organizational
domains with seven or fewer labels, with 8 chosen to allow for one more
label than has been currently observed.

I will post a separate thread about the meaning and usage of the 'n' value
for the 'psd' tag, because regardless of where we land on N for the tree
walk, I think the description of the value of 'n' for the 'psd' tag is
inadequate, a conclusion I've arrived at during the writing of this reply.

-- 

Todd Herr | Technical Director, Standards & Ecosystem
Email: [email protected]
Phone: 703-220-4153


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to