Re: [dmarc-ietf] Thoughts on choosing N

[Scott Kitterman <[e-mail]>]

On April 15, 2024 11:43:08 AM UTC, Alessandro Vesely <[e-mail]> 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