On Tuesday, April 16, 2024 4:55:49 PM EDT Todd Herr wrote: > 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 > 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.
I am confused. Under the current (7489) rules a record for _dmarc.c.d.e.f.tld won't be found either in this case. Why do we need to support something that is currently unsupported? We picked n=5 to allow the current org level record to be detected by the tree walk. It's true that the tree walk provides some additional flexibility for subordinate organizations within what we would call a DMARC org domain based on RFC 7489, but that was by no means anything we ever described as a feature or a goal. Even if some organizations have very deep DNS trees, the fact that some entity uses a.b.c.d.e.f.tld doesn't affect DMARC. The record for the top level of their organization will still be found. In any case, any domain, at any depth in the tree can publish their own DMARC record if they need some special thing. The value of N does not affect that at all. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
