Re: [dmarc-ietf] Thoughts on choosing N

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.com@dmarc.ietf.org> wrote:

> On Mon, Apr 15, 2024 at 7:58 AM Scott Kitterman <sklist@kitterman.com>
> wrote:
>
>>
>>
>> On April 15, 2024 11:43:08 AM UTC, Alessandro Vesely <vesely@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.herr@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
>