Re: [dmarc-ietf] Thoughts on choosing N

Neil Anuskiewicz <neil@marmot-tech.com> Thu, 18 April 2024 02:18 UTC

Return-Path: <neil@marmot-tech.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 191A9C14F71C for <dmarc@ietfa.amsl.com>; Wed, 17 Apr 2024 19:18:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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=marmot-tech.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 bCV0Pc_E1z3f for <dmarc@ietfa.amsl.com>; Wed, 17 Apr 2024 19:18:00 -0700 (PDT)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 8A3FCC14F5EB for <dmarc@ietf.org>; Wed, 17 Apr 2024 19:18:00 -0700 (PDT)
Received: by mail-ot1-x329.google.com with SMTP id 46e09a7af769-6ea0db2727bso185412a34.2 for <dmarc@ietf.org>; Wed, 17 Apr 2024 19:18:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marmot-tech.com; s=google1; t=1713406679; x=1714011479; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=8H1MM8xbBVRVkrTQUW6ChIM+ktKp+QRpMOHDgSixoo8=; b=I/RdoCbiWhmEU4OGDYXdMU2lGeo6BNh5U9DGZOO+HvcQqcwaubmRIZlWiwqdI694jx mrFc3ZBcqr6XkLKXULjRiqPwAI0Ru9l3FJ9p1l3MKA7ZF7vCNjLaQLUMnvl0iYgjB7FM OIBr0KXW6GlF6xm72pp9+NPM3zjIZGAt/5NNHAI2qhY9ZYDfjgy2bcK/y1luJwaSb2Ge hJPZgNFKhC9gNQagTjbLNc/lOc7/fNPmEgyRd0JlyorVFNEKB5IXI/0n9KG7A8lyLkhx ZlMssmIbxqzcOZ3/GGDZX3cau0xHwaMzULLZovm5ygC62Nce/M62diY/OHouefWg+5r2 xjFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713406679; x=1714011479; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8H1MM8xbBVRVkrTQUW6ChIM+ktKp+QRpMOHDgSixoo8=; b=ZHRYPvXBi3ChtlQRe2CrnKQ14HzwV8BEaxTU/E5idmNpdRAcebkYP0NiaeKW+4NAN3 0J1BKHjSkl0W3HrtcGHkV4S8obJjNApgkqar09YS1Egfg/CKqUxG40Tzfsv8a9l1dAKX vVqw7RPQztwFm6WDHQmPYVaV/Fut02Vswp7SlUEPZac9oWZDSn8NriQFlahxhBIYfbcB a/Z9d7qfSpK9hQyNtnlS9cdRyT5MpYc4HlHcVoCdyo/KLkWsL3skncps0HQ+Rzc+OdKc dRcDUWC1dcEwWwi7L0FSJUjZJ+rcKCUUIEyr2rSvMzvuAI0u+WwoeixL7teHvV9jkVuV 3ooQ==
X-Gm-Message-State: AOJu0YzROdO5Rppeq5dS9NqkK3MqG42E+samQCBqRGV1CZ9bhmaWoh1w 8Ki0ZRwYnmGSWi698Zguv/Hlqp6VHeiwiMokJ2bTyIE3HCHiJMy1Z6PbcC3ROVYtSt7BvvE2oMJ W
X-Google-Smtp-Source: AGHT+IENlcJXWU5BM8u86TGwnBtzNc4tLtDqYl7bbIlyKiNVCgclx3H2/CFzkMZSsZDu7KCpREUJgQ==
X-Received: by 2002:a05:6830:1e44:b0:6eb:90d5:5517 with SMTP id e4-20020a0568301e4400b006eb90d55517mr1441052otj.14.1713406679084; Wed, 17 Apr 2024 19:17:59 -0700 (PDT)
Received: from smtpclient.apple (c-73-96-89-175.hsd1.or.comcast.net. [73.96.89.175]) by smtp.gmail.com with ESMTPSA id g21-20020a63e615000000b005f75f325db4sm304508pgh.29.2024.04.17.19.17.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Apr 2024 19:17:58 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Neil Anuskiewicz <neil@marmot-tech.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 17 Apr 2024 19:17:47 -0700
Message-Id: <3A977511-E5F1-4B1B-80B8-ECDE38FC36D3@marmot-tech.com>
References: <6e6b517c-24d4-455c-a50a-6a052b4cda43@tana.it>
Cc: dmarc@ietf.org
In-Reply-To: <6e6b517c-24d4-455c-a50a-6a052b4cda43@tana.it>
To: Alessandro Vesely <vesely@tana.it>
X-Mailer: iPad Mail (21E236)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/2XVfwXNvWY1LiGer9Ing7evIIAA>
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: Thu, 18 Apr 2024 02:18:05 -0000


> On Apr 17, 2024, at 8:29 AM, Alessandro Vesely <vesely@tana.it> wrote:
> 
> 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.

I’m imagining a little chaos if such flexibility were shoe horned in. Rare, sure, but frantic, baffled stress for a few unlucky souls.