[dmarc-ietf] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk

Todd Herr <todd.herr@valimail.com> Tue, 16 April 2024 21:18 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 085FFC14EB17 for <dmarc@ietfa.amsl.com>; Tue, 16 Apr 2024 14:18:05 -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_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 EXFrY3z9osTt for <dmarc@ietfa.amsl.com>; Tue, 16 Apr 2024 14:18:01 -0700 (PDT)
Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 66178C14E513 for <dmarc@ietf.org>; Tue, 16 Apr 2024 14:18:01 -0700 (PDT)
Received: by mail-yb1-xb30.google.com with SMTP id 3f1490d57ef6-dbed0710c74so4225735276.1 for <dmarc@ietf.org>; Tue, 16 Apr 2024 14:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; t=1713302280; x=1713907080; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=2V/RBIy2TWjyy99+Rb4MRbvbQUbkZsiPMlc0s0ZsKJQ=; b=JTAoMHHo0/uNXo1+AiQiQWwE7AK8IegY2Pe1f50iQnxHdHUtzBzVD40rkNVhPI5APe yEYLKow50dK3sr7mmEf806dL4/GK2pNhxSiOog2LebeauuaEQ1Aig6p1T3VfChVpqgKp fo/Z/QNsu3aJrU6VhxIumdtHXDL6k2+bpwt6yjWA7W3OzYZWQHf5Fx9mzDuHFDhy54FZ VyqCFTaAxcMQXHLIo6WBjGWT3tbHxLbousZ+/Dw17TvSUQbCnUboiuIBhpSa1/U3eEhk x3W7VuCdzo7HP4Yy4cRRlKdYiUnuA8jqmaFpQ+yJ5f0AaI8SScKhP5Nia5Th1XshZMKp xzjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713302280; x=1713907080; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=2V/RBIy2TWjyy99+Rb4MRbvbQUbkZsiPMlc0s0ZsKJQ=; b=A684ttpLAL6xvDmbC1ep+nmLePDgvo6hbhYyiHoMy7jQHbPRDQUrujvtR++u/iG2oY BAmPACSP24TofZpQ8hICk/w9ixS/3Q3vWULVz2AmoPdeCYqixQT4+k6+HbQjR1nvGIXe MxmKGe2FG4d0wqJw3+bSHiLwDJzJxJBhtGpbpzLz/TlJIpgi/OEq7N7Jyr+LOrRRgxEc tuc7fbA9KE86c39joo5mKTz86DdIm6NDtmAz4+FGOvAIfppC5Sphd78W9iaZ9N94fBy8 NuHEmr1iCyTclNVGmzD7taC164C9YPUiF+gkyJIaDD/NNsZ63gFtZKQUkC/+7BzGp91d HbhA==
X-Gm-Message-State: AOJu0YyY0FyjbKLLsEVUjmwBR7m6v18WCMl6RKnVrFmUryoFvk6itKuw wb822qHY2DXrDf2svoKfEa45pMd/fMVlVXckgvHHD4lbI1QqsY7Em/eIoPgYpYKLBrtXFpWD/2v xzlXBj7qRHLDJgJ7O1U6fEbKaNnSlYH97PAFXTHvJX+BrHF5lkOw=
X-Google-Smtp-Source: AGHT+IEsMmbum/oRcmiRig7/qPdx6dYlbvcW3nAh8KgUgRJe9FO1IxznANha7WADTtmQBwORKxYwCU2iK7/6EjIEWVo=
X-Received: by 2002:a25:a227:0:b0:dc7:3165:2db1 with SMTP id b36-20020a25a227000000b00dc731652db1mr13674821ybi.49.1713302279952; Tue, 16 Apr 2024 14:17:59 -0700 (PDT)
MIME-Version: 1.0
From: Todd Herr <todd.herr@valimail.com>
Date: Tue, 16 Apr 2024 17:17:44 -0400
Message-ID: <CAHej_8mTh4XVZH7tsdaTyri_dUE65TW3992Y=B-0Gy7vyGDw4Q@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ca384a06163d45b9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/kqK43YZb0I6092u_640xSbqiEts>
Subject: [dmarc-ietf] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk
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 21:18:05 -0000

Colleagues,

DMARCbis currently describes the value of 'n' for the 'psd' tag in a policy
record as follows:

The DMARC policy record is published for a PSD, but it is not the
Organizational Domain for itself and its subdomain. There is no need to put
psd=n in a DMARC record, except in the very unusual case of a parent PSD
publishing a DMARC record without the requisite psd=y tag.
I don't think this is entirely accurate, especially the second sentence
("no need ... except in the very unusual case"), and here's why. Either
that, or the description of the Tree Walk needs to be changed.

The Tree Walk is intended for both DMARC Policy discovery and
Organizational Domain discovery, and section 4.7 (DMARC Policy Discovery)
says the policy to be applied will be the DMARC record found at one of
these three locations:

   - The RFC5322.From domain
   - The Organizational Domain of the RFC5322.From domain
   - The Public Suffix Domain of the RFC5322.From domain

Meanwhile, section 4.8, Organizational Domain Discovery, gives the
following three options for where the Organizational Domain is:

   1. DMARC record with psd=n
   2. The domain one level below the domain with a DMARC record with the
   tag psd=y
   3. The record for the domain with the fewest number of labels.

The Tree Walk, as described in section 4.6, defines two explicit places to
stop, both of which rely on discovery of a DMARC policy record with a psd
tag defined:

   - Step 2, if the DMARC record has psd=n
   - Step 7, if the DMARC record has psd=n or psd=y

There is no other stopping place described, and no instructions to collect
DMARC policy records that don't have the psd tag defined during the walk,
and while Organizational Domain Discovery speaks of records retrieved
during the Tree Walk, there are no instructions in the Tree Walk steps
themselves in section 4.6 to put all the DMARC records with no psd tag in a
basket somewhere for later usage.

So the questions I have are...

   1. Should the description of the 'n' value for the 'psd' tag be updated
   to discuss its usage in a decentralized control model (e.g., seven label
   RFC5322.From with DMARC policy published at a five label name to allow for
   "local" control, with said policy being different from the policy published
   at the "traditional" org domain leve)?
   2. Should the description of the Tree Walk in section 4.6 be updated, to
   mention that valid DMARC records with no explicit psd tag might be found
   during the walk, and these should be preserved for later comparison to
   determine the organizational domain?

I look forward to the discussion.

-- 

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.