Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

Scott Kitterman <> Mon, 11 November 2019 08:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E358120826 for <>; Mon, 11 Nov 2019 00:29:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=iE+g5Hnm; dkim=pass (2048-bit key) header.b=qmUcSs8O
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i5SehodD_H0w for <>; Mon, 11 Nov 2019 00:29:06 -0800 (PST)
Received: from ( [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7461612004D for <>; Mon, 11 Nov 2019 00:29:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPS id 6B2C1F8064C; Mon, 11 Nov 2019 03:29:05 -0500 (EST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201903e; t=1573460945; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=cYKRITtBpIXZYkuP+bJqgzi+dEW/AFcIFdDM4RJSews=; b=iE+g5HnmPek5BQ2sVasEl6TBhESt7TFZrYiETBIo07+HlXUfXkv5G1GF 9xmePM/hHQ8CXPugU+Jd6ZzfRo/+Aw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201903r; t=1573460945; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=cYKRITtBpIXZYkuP+bJqgzi+dEW/AFcIFdDM4RJSews=; b=qmUcSs8O+/4M7P7nxYvwoZyBsDy7A7anHQqLIk/PA6qyToFnYj4MBbaT J2mtAiNNl4vo8+GLEUelXwa+/xboyzMKYZKCLM+8yGofOcVTPTi7Lz2wDJ qykoQoFnTsODZFGpu0yRqPEiSYJOgzWpdseBbDSehXKSH9YTFXC/ZDGY9R eOCGQprbB97zsfkRYwi3FcudZdkvy+5EELFKcSJ19edxsWNUIPI8aWWGgO ysUCjifolxXxXYrQKaYphPnPrCrGsiPMVQf7WtKw0MYET9Bcztrc7LhBbA 6HhqywVnAmjCpzHxwfsSnRVzTmx3fGwKnrMZxtnVu/DsVAeHS/qpeQ==
Received: from [] ( []) by (Postfix) with ESMTPSA id 39528F805BD; Mon, 11 Nov 2019 03:29:05 -0500 (EST)
Date: Mon, 11 Nov 2019 08:29:02 +0000
In-Reply-To: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Scott Kitterman <>
Message-ID: <>
Archived-At: <>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
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: Mon, 11 Nov 2019 08:29:08 -0000

On November 11, 2019 7:34:39 AM UTC, "Murray S. Kucherawy" <> wrote:
>On Thu, Sep 5, 2019 at 1:22 PM Dave Crocker <> wrote:
>> > 1. The change to DMARC should be limited to permitting the query
>for the
>> > organization domain to be anywhere in the DNS tree, including a
>> > Within DMARC this would not look like 'extra' mechanism.
>> >
>> > 2. The mechanism that processes that query should be cast strictly
>as a
>> > PSL enhancement, independent of DMARC.
>> Trying to refine things further:
>>     DMARC does not care about the PSL.
>>     What DMARC cares about is the Organizational Domain (OD), as a
>> fallback when no DMARC record is found at the desired domain name.
>>     That is, PSL is literally outside the scope of DMARC.
>>     At the least, therefore, the DMARC specification should define a
>> distinct interface to the outside functionality that tells DMARC
>> the OD is, which will return what suffix of the full domain name is
>> OD --  eg, getOrgDomain(full-domain) -> org-domain-suffix
>>     The PSL-related side of that interface should be a separate
>> specification, so that changes to its behavior -- such as has been
>> happening with the introduction of ODs that are TLDs or are otherwise
>> 'above' where DMARC has been guessing the OD to be -- are isolated
>>     The current problems are that DMARC has embedded too much detail
>> about the PSL world, yet DMARC has no involvement in that world. The
>> current proposal embeds assumptions of PSL knowledge further, rather
>> than separating PSL knowledge out.
>We (the chairs) fully agree with all of this.  What we -- I in
>-- have been struggling with is to find a path forward so the PSD
>experiment can still take place without being blocked by the need to
>go back and overhaul RFC 7489 as you've described here, separating
>and the OD determination.  Because that'll take months.
>We are perhaps in the fortuitous position in our charter now that our
>next work item is to take up the task of reopening DMARC itself, and
>separation of function Dave is espousing could be made into a reality
>during that work.  Given this, we suggest that the PSD draft be allowed
>proceed as Experimental, but with appropriate preamble text added to
>Introduction explaining the deficiency Dave has identified.  So the
>of operations becomes:
>* add text to the PSD draft making it clear that what it's describing
>is an
>experiment whose outcome will be taken only as feedback to the revision
>the standard (i.e., this is not intended to be the final form of
>and it is not intended to be deployed outside of the experiment's
>* publish the experiment with those cautions and allow the experiment
>* while the experiment is running, spin up the work on two new
>track documents, in line with our charter:
>a) DMARC, with PSL references replaced by the abstract notion of the OD
>that's determined in some non-specific way, as Dave suggests
>b) a PSL document that satisfies the abstract notion of OD in the DMARC
>document, also as Dave suggests
>* when the experiment completes, either augment (b) if it's still in
>development, or publish a revision to it, based on what the experiment
>Can this be made to work?
>Honestly, the experiment could start anyway without an RFC published,
>but a
>formal record of the experiment and its caveats doesn't strike me as a
>wrong thing to do.

The current revision of the PSD DMARC draft makes no reference to the PSL in the body of the draft (it only comes up in Appendix A and C).    It seems like an odd choice to continue to insist PSD DMARC is specifically tied to the PSL when the text indicating so has been removed (Dave's email was two months ago and things have changed in the interim).

I don't think the proposed note says anything the status of experimental shouldn't already communicate.  Given the current state of the draft, I don't think it's necessary to have such a note.

Scott K