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

Scott Kitterman <> Thu, 05 September 2019 13:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1AA431200CD for <>; Thu, 5 Sep 2019 06:36:07 -0700 (PDT)
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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=pBFFBHRz; dkim=pass (2048-bit key) header.b=FNcoyxnv
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9Zz1oQPZGTFh for <>; Thu, 5 Sep 2019 06:36:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0EF87120026 for <>; Thu, 5 Sep 2019 06:36:04 -0700 (PDT)
Received: from ( [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by (Postfix) with ESMTPS id D08F0F8066A; Thu, 5 Sep 2019 09:35:32 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201903e; t=1567690532; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=fjnmWVqzvehF1o63CMmnkQP1x8n4c84y/uda7qgCOQQ=; b=pBFFBHRzPYJnoemLrAsigFT8t8vc4xvKVQXYyNbYQNFGOy2a1tk/uOsC e3vPneiRCUrzyaOX312zu+nojkUXCw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201903r; t=1567690532; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=fjnmWVqzvehF1o63CMmnkQP1x8n4c84y/uda7qgCOQQ=; b=FNcoyxnvLYl4Xu8vqMkI6MtPcm9gBMB43A60jdVQCNdDQtKYskJjDvX+ XrNIaw0nAYwI7HbwqSdYW+0U6s85soMlcJXpFAq2m7J+Y3qOtSFpWgFH7/ age+mjeT1mVpzo7l+dOlfGa9XzOlAv1g7RcksTS4Nt8k25NOhbdEx9CKDU LMJAlkX+mrzcmT8la24zeu8iO5AIgD4uzWk4D/mtuQEL6ZWW8ZN98gvWnW c2OUMUEV6PO66y5avkMVYhwyl6r0Zvfx50etWpW+fRNfdl51u0ORJvFWCc hGTaccKfYu2ZBSHegWy/Z2Ae9Se9nffWgmyHKmxK5hinWZ2PvdOdCg==
Received: from [] ( []) by (Postfix) with ESMTPSA id 50DE6F80284; Thu, 5 Sep 2019 09:35:32 -0400 (EDT)
Date: Thu, 05 Sep 2019 13:35:29 +0000
In-Reply-To: <>
References: <> <> <> <2922527.kgd3cNqxNO@l5580> <>
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: Thu, 05 Sep 2019 13:36:07 -0000

On September 5, 2019 8:28:05 AM UTC, Alessandro Vesely <> wrote:
>On Thu 05/Sep/2019 07:15:35 +0200 Scott Kitterman wrote:
>> On Wednesday, September 4, 2019 9:28:41 AM EDT Dave Crocker wrote:
>>> On 9/3/2019 8:57 AM, Murray S. Kucherawy wrote:
>>>> construction of an augmented PSL (i.e., the actual PSL coupled with
>>>> queryable registry described in Appendix B), which DMARC then can
>>>> consume to resolve the use cases that have appeared which now need
>to be
>>>> addressed.  The portion of the experiment comprising an
>augmentation to
>>>> DMARC’s algorithm would therefore not be part of DMARC permanently.
>>>> Then, if the experiment proves effective, that would become prima
>>>> evidence that the PSL, augmented with this additional information,
>>>> enable DMARC to resolve those use cases.  Such an augmented PSL
>>>> still conform to the desirable separation of functions to which you
>>>> alluded.
>>> With respect to the use of this work as a model for changes to the
>>> unfortunately the spec is not written in a fashion to support that.
>>> This really is a core concern, in my view: the work needs to have a
>>> basic model that really is expected to be appropriate for the long
>>> hence my suggestion to highly limit any changes to DMARC and,
>>> cast the bulk of the work as augmenting the PSL.
>>> That said, and as for getting changes to the PSL, based on my
>>> interactions with that community, I think it unlikely.  There does
>>> seem to be the interest or resources for such work.  Strategically,
>>> that's the biggest hurdle to overcome, IMO.
>>> ..
>>> Hence my current view that:
>>> 1. The change to DMARC should be limited to permitting the query for
>>> organization domain to be anywhere in the DNS tree, including a TLD.
>>> 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.
>> I think some related, but distinct issues are conflated in your
>> The core PSD check doesn't need a PSL change.  The current PSL works
>fine.  The 
>> sequence is:
>> 1.  Check at the From domain level.
>> 2.  If no record, check at the org level.
>> 3.  [New] if no record check one level above the org level (PSD).
>> That's all doable with the current PSL.  I don't think we want to
>> additional lookups between 1 and 2 for lower level domains. 
>Currently for 
>> something like:
>> where only example is in the PSL the queries
>would be:
>> 1.
>> 2.   org.example
>> 3.   example
>> As I read your proposal we've have to add in queries for:
>> I don't think querying anywhere in the DNS treee is an improvement
>> scalability of DMARC.
>Besides scalability, the question is whether b, c, or d have the right
>override the DMARC policy of org.example.  The current spec clearly
>says no.
>My reading of Dave's proposal differs.  Modifying the PSL has the
>objective to skip step 2.  That is, to limit queries to:
>3.   example
>Thereby slashing org.example's privilege to establish its own domain
>> Adding the single additional PSD lookup works fine with the existing
>> There are two reasons to go beyond this:
>> 1.  Since most PSDs won't publish DMARC records, as an efficiency,
>let's not do 
>> that third lookup unless we have to.
>> 2.  PSD DMARC without some constraints on the additional lookup
>> opts in all organizational domains that do not publish DMARC records,
>> has privacy implications.  This is discussed in Section 4.1 of the
>We should also consider updates:
>How often is/should be the PSL updated at average mail servers?
>How often would then the extra list at have to be updated?
>> As it says at the start of Appendix B, the options proposed there are
>> mitigate the privacy risks described in Section 4.1.  The related
>> discussion is in Appendix A, Section A.1.
>> It is a beneficial side effect that they also reduce the need for DNS
>> and thus provide an efficiency enhancement.
>> If we didn't care about privacy, this would be easy.  That's the hard
>> that does not have a clear solution.  One thing that is clear is that
>it's not 
>> the PSL.  PSL is a collector of assertions from operators, so it
>fails to meet 
>> the attributes laid out in A.1.
>Failure reports are considerably less implemented than aggregate ones. 
>current spec doesn't mention any privacy risk in its Security
>section.  However, some concern must exist, otherwise the difference in
>implementations cannot be easily explained.  The I-D at hand touches on
>point marginally.  A general consideration would better fit in

That's because there's an entire separate section on privacy considerations.

Scott K