Re: [dmarc-ietf] Thoughts on choosing N

Scott Kitterman <sklist@kitterman.com> Wed, 17 April 2024 05:06 UTC

Return-Path: <sklist@kitterman.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABF3C14F615 for <dmarc@ietfa.amsl.com>; Tue, 16 Apr 2024 22:06:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b="U+YIYT3I"; dkim=pass (2048-bit key) header.d=kitterman.com header.b="XdULc7ec"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zi5kl_r5cbGN for <dmarc@ietfa.amsl.com>; Tue, 16 Apr 2024 22:06:20 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6C9C14F5F1 for <dmarc@ietf.org>; Tue, 16 Apr 2024 22:06:20 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id B8E6EF80240 for <dmarc@ietf.org>; Wed, 17 Apr 2024 01:06:07 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1713330351; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=ln0AnBdyxHZBCjjualQ3fJa91OQqVRNSXkWZK+oQ3BM=; b=U+YIYT3IDPuMIWYta283pBHEJ6CAa2qSV2Y8lmRevngHLc77lILvGucWUoH1Ra/GTBbf9 X3JmByWDLALxr+PCA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1713330351; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=ln0AnBdyxHZBCjjualQ3fJa91OQqVRNSXkWZK+oQ3BM=; b=XdULc7ecHHLtMWqMYICF2hlCEbMHtuTrU0Lh2zkEpyIpVjniY4DQ3OhGfYgl6Da94Fe+S XflJ7zzEefuKJNQbgYjPeEdzK7VcrMR2QkfNaoPEkhBEjAj6B28XmCaebSXvorJe4QlVp4J QQW8SKdasxF/tm5L0IizYt1AKGlytMiRdv2bh3YJojUIIttAPC4sw/eDi2DLk+EK3ZNIDOo /l9EERL2FjfX4YXA7XfCfZ2SeFFK6bnH/ACNAxLsK0D+xyloaIjC+ChNv99lIj1Ww5FNFc0 ZXBBL2LxJq0An6yuasS5DyA2uLAQEZhREcPMPSbeUSItQqe63QIwYb58UAbw==
Received: from zini-1880.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id BED82F8008E for <dmarc@ietf.org>; Wed, 17 Apr 2024 01:05:51 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Wed, 17 Apr 2024 01:05:40 -0400
Message-ID: <2109607.sSyRYrMuh2@zini-1880>
In-Reply-To: <CAHej_8kEFqDax7hrSmiDodE-kQf4K6JvinKDqFtqTZXb+g-uzA@mail.gmail.com>
References: <CAOZAAfPwJHKGyLjTkdGDqkMeK4RQX4Fj0rw-Upn0cLZ+cE74aA@mail.gmail.com> <CAH48Zfx-w5LWO5VuK2posywHRF8O1wijTk35H-01e3JaL=V5=A@mail.gmail.com> <CAHej_8kEFqDax7hrSmiDodE-kQf4K6JvinKDqFtqTZXb+g-uzA@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/Q7_cYFr1OP0HQtAHxlvejwaLDVs>
Subject: Re: [dmarc-ietf] Thoughts on choosing N
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2024 05:06:25 -0000

On Tuesday, April 16, 2024 4:55:49 PM EDT Todd Herr wrote:
> On Mon, Apr 15, 2024 at 8:08 PM Douglas Foster <
> 
> dougfoster.emailstandards@gmail.com> wrote:
> > 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?
> 
> My understanding of the Tree Walk is that in DMARCbis it is the defined
> method for performing two separate jobs:
> 
>    - Discover the controlling DMARC policy record for the RFC5322.From
>    domain in a given email message; this controlling DMARC policy will be
>    found at either the RFC5322.From domain, the organizational domain for
> the RFC5322.From domain, or the PSD of the RFC5322.From domain.
>    - Determine the organizational domains for the SPF domain,and the DKIM
>    domain in a given email message, in order to determine whether the
> domains are in relaxed alignment with the RFC5322.From domain
> 
> As I wrote in an earlier message, we have data showing use of seven label
> domains in the RFC5322.From domains; it's not a lot of data, but it's there.
> 
> So, in my current scenario with an RFC5322.From domain of a.b.c.d.e.f.tld,
> DMARC Policy Discovery would be done by querying for these five (5) records:
> 
>    - _dmarc.a.b.c.d.e.f.tld
>    - _dmarc.d.e.f.tld
>    - _dmarc.e.f.tld
>    - _dmarc.f.tld
>    - _dmarc.tld
> 
> Let's imagine that the Domain Owner for f.tld publishes this DMARC record:
> 
>    - v=DMARC1; p=none; psd=n; rua=mailto:foo@f.tld;
> 
> but they allow for distributed, rather than central, administrative
> control, and therefore those who manage c.d.e.f.tld publish a DMARC record
> like this:
> 
>    - v=DMARC1; p=reject; psd=n; rua=mailto:foo@c.d.e.f.tld;
> 
> Perfectly valid configurations as DMARCbis is currently written. The
> plausibility of same is unknown, but because RFC 7489 didn't contemplate
> organizational domains as anything other than domains one level below the
> domains on the PSL, it's not likely anyone ever tried to publish a DMARC
> record at c.d.e.f.tld.
> 
> If we leave N at 5, the organizational domain and thus the intended DMARC
> policy for a.b.c.d.e.f.tld won't be discovered, as it's published at
>  and that query will be skipped by the Tree Walk.
> 
> My argument therefore for N=8 is to support distributed policy settings for
> RFC5322.From domains with eight or more labels and therefore organizational
> domains with seven or fewer labels, with 8 chosen to allow for one more
> label than has been currently observed.
> 
> I will post a separate thread about the meaning and usage of the 'n' value
> for the 'psd' tag, because regardless of where we land on N for the tree
> walk, I think the description of the value of 'n' for the 'psd' tag is
> inadequate, a conclusion I've arrived at during the writing of this reply.

I am confused.

Under the current (7489) rules a record for _dmarc.c.d.e.f.tld won't be found 
either in this case.  Why do we need to support something that is currently 
unsupported?

We picked n=5 to allow the current org level record to be detected by the tree 
walk.  It's true that the tree walk provides some additional flexibility for 
subordinate organizations within what we would call a DMARC org domain based 
on RFC 7489, but that was by no means anything we ever described as a feature 
or a goal.

Even if some organizations have very deep DNS trees, the fact that some entity 
uses a.b.c.d.e.f.tld doesn't affect DMARC.  The record for the top level of 
their organization will still be found.

In any case, any domain, at any depth in the tree can publish their own DMARC 
record if they need some special thing.  The value of N does not affect that at 
all.

Scott K