Re: [dmarc-ietf] Domains and tree walk

John Levine <> Wed, 02 December 2020 02:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C9A13A0F5E for <>; Tue, 1 Dec 2020 18:50:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=sZ+n/Ld7; dkim=pass (2048-bit key) header.b=MnBhyAX3
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j8WEDDCfzksn for <>; Tue, 1 Dec 2020 18:50:29 -0800 (PST)
Received: from ( [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0750F3A0F4D for <>; Tue, 1 Dec 2020 18:50:28 -0800 (PST)
Received: (qmail 43669 invoked from network); 2 Dec 2020 02:50:27 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=aa91.5fc700f3.k2012; bh=36TjZ7qwbeZKxXMphifSdjcwKl7zLQ1FL+TY+y3X55Q=; b=sZ+n/Ld7pXVXMKlS8mRc+Pg7CuK2G98K2jVshIu3yqafaigDp0b0rpiwgGpQ412CM6d8wWs1CPoPqP7cfjRjh/4nqHO6k1djbkgkk/iBir3q6E0Gd++l/x1sQMpA34mZYhkH5tBC2SK2YktbW8t2/1zoFEd7QT+ozac9TVMh1o613sEW6bcTSLEJIlLDpbXbkc/ZXEntJc0hz8a3q/kA4ojluvBv8AT+fPVbkB8VGFMwksAS2tVAfXGDf14joD6kEIaUETsZoZxQiSrhzuNN7B0gC+3e33QwyKACUOY/E8kzIn2O4tdB5Ij2NuGWPFxVD/8kdDDmN7Ca6eUwS6mPKQ==
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=aa91.5fc700f3.k2012; bh=36TjZ7qwbeZKxXMphifSdjcwKl7zLQ1FL+TY+y3X55Q=; b=MnBhyAX37/oje8Ze80ATBRcAMf9HTpGRVFZVBWBSV0NEvO6BRNPO+OEUhM9pP9E2ea3rBLGznW97mF+DXAIkXz+ZYwi1C0D2S4l0RS6eFLlfIebEUtleO+qFvpqZ1dHGQYnYd84kzxf8RPFEBgoso0FQZ44JrcVKt9whyBaMC7b7BhfDjJ2t3/EXh+OhMS7HN5zFSVchETFDuaYxikUYRrmuPRc8sPAfeBPo41ICIXH099KLALkUFGiEAw9wqIFCIGOmuBhdgJjVq1Fj75thxX8Tsh2l/6Fsb8PMHLZ7xkzrN7m6o/12c/BQ7+sOZWfmvY/+HNolmZFDPHwK480RTg==
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 02 Dec 2020 02:50:27 -0000
Received: by ary.qy (Postfix, from userid 501) id F16E128C5FDE; Tue, 1 Dec 2020 21:50:26 -0500 (EST)
Date: 1 Dec 2020 21:50:26 -0500
Message-Id: <20201202025026.F16E128C5FDE@ary.qy>
From: "John Levine" <>
In-Reply-To: <>
Organization: Taughannock Networks
X-Headerized: yes
Cleverness: minimal
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <>
Subject: Re: [dmarc-ietf] Domains and tree walk
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Dec 2020 02:50:31 -0000

In article <> you write:
>I know of no other
>standard that requires this type of relationship.

Here at the IETF, the CAA DNS record that specifies which certificate
authority can sign for what domains does a tree walk. If there is a
CAA record at it controls signing of and and so forth unless they have their own CAA record.

Every applicaton of the public suffix list implicitly does something
akin to a tree walk. Its original application was to control
cross-site web cookies, to say whether can drop a cookie at (yes) or (no).

> This is something new. It will require administrators to continually check what their
>sub- and supra-domains are doing in order to escape interference by
>DMARC records they did not create. I think this is unreasonable. Only
>domains interested in applying DMARC should be involved with DMARC. ...

Well, it's not that new since we published the DMARC spec five years
ago, but this is what I have referred to as the Holy Roman Empire
problem. In organizations that are not universities, the entity that
is responsible for the registered domain generally sets policies for
the whole organization, and a good deal of the DMARC design is there
to let them figure out who is sending mail with their name on it from
any of their subdomains and identify and adjust senders whose mail
doesn't match the policy.

We realize that universities are different, organized along the lines
of the Holy Roman Empire, and the Elector of Central Asian
Cross-Disciplinary Studies feels very strongly about any incursion on
their autonomy including their mail setup.

On the other hand, I observe that Brown, Cornell, Dartmouth, U Penn,
and Yale, whose situations are not altogether unlike Columbia's, all
publish DMARC records. Closer to home so do NYU and CUNY. They all say
p=none with rua= to collect reports. You might give them a buzz to see
how it works for them.