On April 15, 2024 11:43:08 AM UTC, Alessandro Vesely <[email protected]> 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. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
