Re: [dmarc-ietf] Thoughts on choosing N

Alessandro Vesely <vesely@tana.it> Wed, 17 April 2024 15:29 UTC

Return-Path: <vesely@tana.it>
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 3B0F9C14F69F for <dmarc@ietfa.amsl.com>; Wed, 17 Apr 2024 08:29:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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 (1152-bit key) header.d=tana.it
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 BzQ126RfA_Dh for <dmarc@ietfa.amsl.com>; Wed, 17 Apr 2024 08:29:20 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [94.198.96.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B278DC14F69C for <dmarc@ietf.org>; Wed, 17 Apr 2024 08:29:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1713367752; bh=xS6h0Vez1/Gykgwyq1L5m+/pkEa07S17t1vg8whhztY=; h=Date:Subject:To:References:From:In-Reply-To; b=DT3Capy8msgHE0A2A2IA9/8wje37VAXyKdA1D/96N9U2MLsRanMNvQBx4vLar8D1I kOZf9xp3vwPONtLZriK3XqTT/oQ/pkb54zi5RuCZE/4Ok9KyqPEoEFC4md3gl0epjb Dmpu6Zxl2keYAkfDie6FbX05KH3rWHUHRRpBvfyOjNX7kBO2brZ37SvNhgDsV
Original-Subject: Re: [dmarc-ietf] Thoughts on choosing N
Author: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.120] (pcale.tana [::ffff:172.25.197.120]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC042.00000000661FEAC7.000075BC; Wed, 17 Apr 2024 17:29:11 +0200
Message-ID: <6e6b517c-24d4-455c-a50a-6a052b4cda43@tana.it>
Date: Wed, 17 Apr 2024 17:29:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: dmarc@ietf.org
References: <CAOZAAfPwJHKGyLjTkdGDqkMeK4RQX4Fj0rw-Upn0cLZ+cE74aA@mail.gmail.com> <CAH48Zfx-w5LWO5VuK2posywHRF8O1wijTk35H-01e3JaL=V5=A@mail.gmail.com> <CAHej_8kEFqDax7hrSmiDodE-kQf4K6JvinKDqFtqTZXb+g-uzA@mail.gmail.com> <2109607.sSyRYrMuh2@zini-1880> <CAHej_8kHJU9_T4sf7aMAiD-qzmpH8KBOeN=fBawHCBNk2N5y3g@mail.gmail.com>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
Content-Language: en-US, it-IT
In-Reply-To: <CAHej_8kHJU9_T4sf7aMAiD-qzmpH8KBOeN=fBawHCBNk2N5y3g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/QpbYegUTQAGZjhQrwMrx0MUKuMg>
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 15:29:26 -0000

On Wed 17/Apr/2024 15:42:23 +0200 Todd Herr wrote:
> On Wed, Apr 17, 2024 at 1:06 AM Scott Kitterman <sklist@kitterman.com> wrote:
> 
>> 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. >
> I don't share your understanding here. I interpret some of the text of 
> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/79, "Do 
> away with the PSL and Org Domain entirely; just walk the tree" to at least 
> imply that the tree walk was designed to provide this flexibility [...]


If we wanted to provide high flexibility, then we'd have designed an 
inheritance system whereby, for example, policy or rua address can be inherited 
from parent domains.  John would 've called it mission gallop.


>> 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 >
> Fair enough. You're correct that a DMARC policy can be published for any
> specific domain used as the RFC5322.From domain, so perhaps a bit of text
> in the Tree Walk section describing the really deep use case and
> the solution for it might be a compromise.


We may say the system is harsh by design.  You can rely on the org domain 
settings or define your own in the From: domain.  Flexibility to fetch values 
from intermediate domains is not provided.

Indeed, even if we had N=8, DMARC records at b.c.d.e.f.g and c.d.e.f.g would be 
discarded unless they contained psd=y or psd=n.


Best
Ale
--