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? On Mon, Apr 15, 2024, 10:02 AM Todd Herr <todd.herr= 40valimail....@dmarc.ietf.org> wrote: > On Mon, Apr 15, 2024 at 7:58 AM Scott Kitterman <skl...@kitterman.com> > wrote: > >> >> >> On April 15, 2024 11:43:08 AM UTC, Alessandro Vesely <ves...@tana.it> >> wrote: >> >On Mon 15/Apr/2024 13:16:50 +0200 Douglas Foster wrote: >> >> Our original choice of N was based on the PSL. The PSL could not >> detect organizational boundaries could not boundaries below level 5, >> because it had no entries longer than 5 labels, and we determined that the >> 5-label entries were not used for mail. Therefore, any increase in N is >> new capability. That new capability is probably desirable, but need not >> be limitless. Using an N of 8 introduces a lot of new capability. >> > >> > >> >8 is not needed and not justified. A mail site using 8 labels would >> have troubles with the RFC 7489 version, which uses the PSL. They'd have >> to ask for PSL upgrades, right? >> > >> >Now, we can relax our ambition to be PSL-free and state N=max number of >> labels of public suffixes used by mail. Or we could put N in an IANA >> registry that can be updated by expert review. Such methods allow to have >> N low enough, yet upgradable and equal for all (compliant) implementations. >> > >> >Otherwise we can drop the requirement that N be equal for all >> implementations, and just make it configurable. After all, it is an >> anti-abuse measure, akin to SPF lookup limit. We can also keep it fixed at >> 5 and be sure that implementations will differ anyway. >> > >> Whatever we decide, I think it needs to be specified. If N is whatever, >> you will end up with difficult to troubleshoot interoperability issues when >> various sites pick different values. >> >> I don't think we need to worry about revising it later. In general, DNS >> is getting wider (new TLDs), not deeper. >> >> > An inspection of data collected by my employer reveals the longest > observed RFC5322.From address to include seven labels in the domain part. I > am not at liberty to reveal the specific domains due to customer privacy, > but they're there. > > For a domain with seven labels, a.b.c.d.e.f.g, the Tree Walk as currently > described would miss any DMARC policy records published at b.c.d.e.f.g and > c.d.e.f.g. > > I would propose the following first draft of expository text regarding > setting N at 8: > > The point of the Tree Walk is to allow for the publishing and discovery of > DMARC policy records at any level in the DNS hierarchy that strikes a > balance between what the domain registrant deems reasonable and what > operational needs deem reasonable. The setting of N is done with an eye to > putting a thumb on the scale on the side of operational needs, to guard > against the truly silly or abusive cases with domain names with label > counts in the dozens or even triple digits. Based on an observation at the > time of publishing that RFC5322.From domains with seven labels were in > active but uncommon use, eight was chosen as the value of N in order to not > only accommodate for current usage but also to allow for a bit of future > expansion of the depth of the name space used for RFC5322.From domains. > > > > -- > > Todd Herr | Technical Director, Standards & Ecosystem > Email: todd.h...@valimail.com > 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 > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
