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
