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

Neil Anuskiewicz <neil@marmot-tech.com> Thu, 18 April 2024 01:53 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 04F11C14F6B6 for <dmarc@ietfa.amsl.com>; Wed, 17 Apr 2024 18:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.193
X-Spam-Level:
X-Spam-Status: No, score=-1.193 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, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, 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=no 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 VWlGo-PD-hgR for <dmarc@ietfa.amsl.com>; Wed, 17 Apr 2024 18:53:49 -0700 (PDT)
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 76A06C14F708 for <dmarc@ietf.org>; Wed, 17 Apr 2024 18:53:49 -0700 (PDT)
Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-1e51398cc4eso3421285ad.2 for <dmarc@ietf.org>; Wed, 17 Apr 2024 18:53:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marmot-tech.com; s=google1; t=1713405228; x=1714010028; 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=e0fGr/RspPlOO1KWZO4ZfkHx9p1MmAzCpkOUpWOvhbM=; b=HDPdNrMwgyWLxDL/XJIa61S6VPmk/6vnG2aFIhebIbXHx1g8dzS4LBDNH8PsF+HLTl dKCQNr3ylufVADpYsF+2M2LIVYo1eFtNbixi2ATBLWJeGCz5onsFSVhOiyc22owZH0il 2X4zVRYYX9KucqF7ycptzD0onJfYgmshfdlzPOyXXePUICZxzRjsifQS+HFgjdWzrOsR m9k5OXe8oL07Vq9P6XguRS30ZKhyTeXipU2p6z8ui6Q9fB5sr/0YWCnfqJ8x/ggPb/Fu GWyD4YdjXAGtHAlvpIShjrGOCTXNZLYlQ1dhCs1GhoNjPpQ4RLFiQdtQ0gLVhflLWCEd HwVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713405228; x=1714010028; 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=e0fGr/RspPlOO1KWZO4ZfkHx9p1MmAzCpkOUpWOvhbM=; b=XhZgyuZ2tAwKkEEbOAapyjae2UHAEJ4xqvnfObcBqbODo3lSIxF0ivFfIdvkG63O2/ P12iTN3M7iUot+lyVmI8f+g/R+TZ7CCHq5k9pmz4zomTIcn4po0SQuTV2rlsqRMoHut+ AY7EFqYGD2GbHl/RXOfn6lfK8MfnQhirprym+bUzKx90stpc0BVyCU36wNJxsfWt+4bs eHGfstS4CCXLraQKQmzZaYhyfyOo+tu6j+Tkchz2Od7izsoL6KDzs3o3qQce9OYzJ7J6 ONN02p852qFxGSaWSjFTeNNEDqQgCiznJS4ax0iIa88sffJ64DOxOmkYvCqmpZvVs+Fq KC+w==
X-Gm-Message-State: AOJu0YzTr/O+Lbwyx0Q/msPchgIXSCfYTIyGF/MJUqKs7k2vnDlerEYq DmFbG5XQhecvgpQZ641FDcpnOtx5F6sqHWmEKvOdCOHVnKPvW2jysSYixEw835p/yvl3qy9B0pe P
X-Google-Smtp-Source: AGHT+IEZpBSkospsU0hti5gv39EQkPeCufa8UfJVN1lJQKmVh8GVgf/cpltZgsZCwQ01xLXWoJ4+tg==
X-Received: by 2002:a17:902:d485:b0:1e2:b4ce:4f8a with SMTP id c5-20020a170902d48500b001e2b4ce4f8amr1979570plg.53.1713405227765; Wed, 17 Apr 2024 18:53:47 -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 e11-20020a170902784b00b001e0bae4490fsm315758pln.154.2024.04.17.18.53.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Apr 2024 18:53:47 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-FC11F911-8BEA-4235-8C21-3C35166243CF"
Content-Transfer-Encoding: 7bit
From: Neil Anuskiewicz <neil@marmot-tech.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 17 Apr 2024 18:53:36 -0700
Message-Id: <DE6411C9-EDDE-4C44-9B5F-9FBCB2F8E908@marmot-tech.com>
References: <CAHej_8kA_BsnNNh9wFHd7EnoMt0jhZY=_oROa01P6NVbLimPYw@mail.gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
In-Reply-To: <CAHej_8kA_BsnNNh9wFHd7EnoMt0jhZY=_oROa01P6NVbLimPYw@mail.gmail.com>
To: Todd Herr <todd.herr=40valimail.com@dmarc.ietf.org>
X-Mailer: iPad Mail (21E236)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/LldUdPti_1jtK0sQXxVD5A2YfxQ>
Subject: Re: [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: Thu, 18 Apr 2024 01:53:54 -0000



On Apr 17, 2024, at 6:33 AM, Todd Herr <todd.herr=40valimail.com@dmarc.ietf.org> wrote:



On Wed, Apr 17, 2024 at 1:18 AM Neil Anuskiewicz <neil=40marmot-tech.com@dmarc.ietf.org> wrote:


On Apr 16, 2024, at 2:18 PM, Todd Herr <todd.herr=40valimail.com@dmarc.ietf.org> wrote:


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.

One of your concerns is that without a PSD tag, but I think the default is PSD=n. Does,that address that concern or did I misunderstand the concern?


The default for the psd tag is 'u', not 'n'.


Thank you and I’m not sure why I was thinking n. I guess I figured if it’s not a PSD which should publish an explicit y. My logic just looking at the tree walk makes no sense.