Re: [dmarc-ietf] Thoughts on choosing N

Todd Herr <todd.herr@valimail.com> Tue, 16 April 2024 20:56 UTC

Return-Path: <todd.herr@valimail.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 C2DE4C14F749 for <dmarc@ietfa.amsl.com>; Tue, 16 Apr 2024 13:56:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=pass (2048-bit key) header.d=valimail.com
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 0MAm1jwsBHXK for <dmarc@ietfa.amsl.com>; Tue, 16 Apr 2024 13:56:07 -0700 (PDT)
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 1C800C14F707 for <dmarc@ietf.org>; Tue, 16 Apr 2024 13:56:07 -0700 (PDT)
Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-dcc84ae94c1so4660674276.1 for <dmarc@ietf.org>; Tue, 16 Apr 2024 13:56:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; t=1713300966; x=1713905766; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=+9bWioht/4jeyUP2wdw3sL9WpA5LlUKiS39qP+4sIEk=; b=T7xXFkeR3cFQaamIqcPAGJVyAopZSRCJKQsWRupaa0bKI/WV6J/Gvellr7GOZbCkY1 ViqBN/aawxsKXdZ1bt26uADuN0fbmNIMK6ug6R8b8T75AGBIFqD+ZJ+jL1CfPz94qzKg ZBQMWSR2SgNs9ZzBWiAR4ZQ+PM/dv0iTJdr9/3BFdtlka/9nGAbkZOg4DtoPUwyFGmXP /Gjf4KyiRgLhWMAqyYW0pOvfT4B+Ss7ZAY0eW4x49HgrL2sJliA+DbzkXEUks76pMvxN 47XoSFFqsL211aW8RTwS2qXBD4oaI8HDe/BLbaojhqMIChyjcI66+oPJe06TWePnL2n6 vHNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713300966; x=1713905766; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+9bWioht/4jeyUP2wdw3sL9WpA5LlUKiS39qP+4sIEk=; b=fXGLzzgIgdWBlxazoOKZBC/cdjXEM2xSDd0BorCHvi5fdptIJ5mRc66XsN7Uryx6xq WiHSdTsM8cI0TNucfmieRDUXB6f0EoPNz2cxplaf67M8fWF560o/u7G5B5ewedWApvyQ zrDfc9qQUsgW/Ncw5XTm0voX7EL/nkZvBEIYCjc3pIew2hai8PmUBJiWbrDg9WHfqpdF 41DruhJkuFCIWyQ9+2D1SX2MLxu96I4qx7Oma/D5XjUQeive2loCNZmlhs1a1WzftvKU 1Q+lrQZWY0XhV3BIjGfkRpcv6DTwOz5x9wBzBGIPZvRJZ5S2uv6NSQwz1z39H01arwtF SXPg==
X-Gm-Message-State: AOJu0YxOg24LAFCUI4e145oiLoNZodDVtofG9I0HBbmd1/Bck9u1aYpM kxUCtXxLsB9iwgpPf7CbaUMcg0xMmHNridqu3BgBl0JG+G+X3Pm2D+2aIwITcx+ZnCZHIOsEOpx FSV+sofujA0iiQxs1Ra7VhO0q84SNHp7DuVezlUJFV2vutu5BwXU=
X-Google-Smtp-Source: AGHT+IFrN2nX457vKJp4pqmROthWgoK1rsK72kK54wnxb6yO9aPsdeeLxazG0RgSmDeTz+oJ3hwBuF9WQ9zleHPAoRQ=
X-Received: by 2002:a25:20d5:0:b0:de0:d32b:52bf with SMTP id g204-20020a2520d5000000b00de0d32b52bfmr13277320ybg.39.1713300965979; Tue, 16 Apr 2024 13:56:05 -0700 (PDT)
MIME-Version: 1.0
References: <CAOZAAfPwJHKGyLjTkdGDqkMeK4RQX4Fj0rw-Upn0cLZ+cE74aA@mail.gmail.com> <2764165.rv8vZNihtd@zini-1880> <53f29df5-031a-8711-aed6-25c310f539a2@iecc.com> <8C54A48A-5665-41A1-B64F-93A39CF0B12C@kitterman.com> <CAL0qLwZ2TuV_EW6D9HZYwErmwL_n7q4ZKTEpHBZbyxnkKJ8m6w@mail.gmail.com> <CAH48ZfzckPscoSPUVEqy1WS71iAnKyj7gQVDOW4Hi=FXo0PzYg@mail.gmail.com> <a2bd52d6-7bb3-4526-a0d8-075f4ab44f33@tana.it> <92E339E5-0A4C-4929-A751-375B892C2C53@kitterman.com> <CAHej_8m8H2RRH2uMjtqgw7yf093a10do22swt0j0C-yCTNPL6A@mail.gmail.com> <CAH48Zfx-w5LWO5VuK2posywHRF8O1wijTk35H-01e3JaL=V5=A@mail.gmail.com>
In-Reply-To: <CAH48Zfx-w5LWO5VuK2posywHRF8O1wijTk35H-01e3JaL=V5=A@mail.gmail.com>
From: Todd Herr <todd.herr@valimail.com>
Date: Tue, 16 Apr 2024 16:55:49 -0400
Message-ID: <CAHej_8kEFqDax7hrSmiDodE-kQf4K6JvinKDqFtqTZXb+g-uzA@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000078923006163cf77e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/8iqxpyAGkTORLb6-E0923dkqx6E>
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: Tue, 16 Apr 2024 20:56:10 -0000

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
_dmarc.c.d.e.f.tld 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.

-- 

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.