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

Alessandro Vesely <> Thu, 05 September 2019 08:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 965391200A1 for <>; Thu, 5 Sep 2019 01:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1152-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XTuWGU6Gpf6t for <>; Thu, 5 Sep 2019 01:28:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E09C7120058 for <>; Thu, 5 Sep 2019 01:28:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=delta; t=1567672085; bh=blO4uQPWSES/8lc8NJoxjFbD1uwumzCFaIZ6mIbxXgo=; l=4918; h=To:References:From:Date:In-Reply-To; b=DjMp61QrqFabDvFTLZLA+gutgUoDzJl/aVnaUVtLdNBLIc+J1vmk6GL267oTVadw/ nnhYC0U+bFkvooKZ+1Eby7Ce3IS+WT+dfUVgOkL1bGKlPyncNwSRw8dEg//21LKAuN fJnahFwu/UFnTXuimhGjm5sjs0ZTSYUIEffXCUVkgVIZsUgKxRDkgx6GI5uVj
Authentication-Results:; auth=pass (details omitted)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by with ESMTPA id 00000000005DC083.000000005D70C715.00004E1F; Thu, 05 Sep 2019 10:28:05 +0200
References: <> <> <> <2922527.kgd3cNqxNO@l5580>
From: Alessandro Vesely <>
Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00
Message-ID: <>
Date: Thu, 5 Sep 2019 10:28:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <2922527.kgd3cNqxNO@l5580>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
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 08:28:09 -0000

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 the
>>> 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 facie
>>> evidence that the PSL, augmented with this additional information, would
>>> enable DMARC to resolve those use cases.  Such an augmented PSL would
>>> 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 PSL,
>> 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 term;
>> hence my suggestion to highly limit any changes to DMARC and, instead,
>> 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 not
>> 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 the
>> 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 analysis.
> 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 force 
> 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 for 
> scalability of DMARC.

Besides scalability, the question is whether b, c, or d have the right to
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 implicit
objective to skip step 2.  That is, to limit queries to:

3.   example

Thereby slashing org.example's privilege to establish its own domain policy.

> Adding the single additional PSD lookup works fine with the existing PSL.  
> 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 automatically 
> opts in all organizational domains that do not publish DMARC records, which 
> has privacy implications.  This is discussed in Section 4.1 of the draft.

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 to 
> mitigate the privacy risks described in Section 4.1.  The related requirements 
> discussion is in Appendix A, Section A.1.
> It is a beneficial side effect that they also reduce the need for DNS lookups 
> and thus provide an efficiency enhancement.
> If we didn't care about privacy, this would be easy.  That's the hard part 
> 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.  The
current spec doesn't mention any privacy risk in its Security Considerations
section.  However, some concern must exist, otherwise the difference in
implementations cannot be easily explained.  The I-D at hand touches on this
point marginally.  A general consideration would better fit in DMARCbis.