Re: [dmarc-ietf] Thoughts on choosing N

[Todd Herr <[e-mail]>]

On Mon, Apr 15, 2024 at 7:58 AM Scott Kitterman <[e-mail]>
wrote:

>
>
> 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.
>
>
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: [e-mail]
Phone: [phone]


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.