Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.txt

Scott Kitterman <> Thu, 09 May 2019 16:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E7DF12006B for <>; Thu, 9 May 2019 09:39:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=/mc9lDz9; dkim=pass (2048-bit key) header.b=pWuB2y4/
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uwHXBKYdtz1y for <>; Thu, 9 May 2019 09:39:25 -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 823F312016A for <>; Thu, 9 May 2019 09:39:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 39676F8074A for <>; Thu, 9 May 2019 12:39:14 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201903e; t=1557419954; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=HdNVemkGC8x0lkJtY5lXZfTNV4tWERkYbm1vBYLHmWs=; b=/mc9lDz9PLDf1/XbQZC5MY+jOTcESgF8XdyZDTpGMWvQXBzvMo+i+KyT NZp5Drrvqb/LC+YvN6nLD8JmNjpRCg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201903r; t=1557419954; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=HdNVemkGC8x0lkJtY5lXZfTNV4tWERkYbm1vBYLHmWs=; b=pWuB2y4/wBGWnT0uPlxiQZdHEhk2lxeot/FA/p1iVcSMXE+1KCsX5qwd QHdtE+bDQyBSrQvRqqQLpnC4sZ6yiFPUGRvOZ+lGmYTRbFp0Ih1v+Ula8i 3XkKtQ/ljJ6GgAeN7zIfcWoctGoSas4gM8F7Z6DJ74d7uhWJormm1Sc9xL arVPHVzK0W5NkQ4jOXZsMsjkV8erWf+vgzeBptesPhxr7pxF0x09qRWqft DuFLN8EkMuTfENwmFUmtT6wOCEDPizIyd8SNybLlltPuI3DtxzIe9mhvhg fm2knr6H56YRwV1h0ueHhcvMYuVw5gLAZ+z8PI0XISms5GOdRleqOA==
Received: from l5580.localnet ( []) by (Postfix) with ESMTPSA id 05D03F80721 for <>; Thu, 9 May 2019 12:39:13 -0400 (EDT)
From: Scott Kitterman <>
Date: Thu, 09 May 2019 12:39:13 -0400
Message-ID: <12992594.LUNhQVcRDa@l5580>
In-Reply-To: <>
References: <> <2699063.PiBShnsfcX@l5580> <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <>
Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.txt
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, 09 May 2019 16:39:27 -0000

On Tuesday, May 7, 2019 10:30:25 PM EDT Seth Blank wrote:
> Thanks, Scott!
> To me (as an individual) this seems ready for last call.
> A few items:
> 1. In the new paragraph in section 1 clarifying requirements, you have an
> open parens that is never closed.

Fixed locally for the next revision.

> 2. In Section 3.5, I'm concerned with the normative MUST NOT. This would
> mean .example couldn't receive failure reports the way does.
> For something like .bank or .com, this is a feature. But for a .google,
> this is a bug. I really think this MUST NOT is, while well advised, delving
> into policy and not interop.

In theory, I agree, but in practice, I think the new MUST NOT is a great 
change to promote implementation simplicity.  Recall that the failure reports 
we are discussing are not commonly sent even for regular DMARC due to privacy 
concerns, so there's almost no loss of feedback as a practical matter defining 
it this way.

Consider what implementers would have to do in the alternative.  In order to 
treat failure reports differently for single and multi-organizational PSDs, one 
would need to know which is which.  While some, like .google are relatively 
obvious, other are much less so.  It is much better to give clear guidance 
than to be handwavy.

> I really think the guidance in 4.1 is the best way to approach this.
> Speaking of which, with the normative MUST NOT that's been added, now 4.1
> no longer makes any sense.

Only if you assume that there are no privacy risks associated with aggregate 
reports, which I don't believe is accurate.  I certainly wrote 4.1 on the 
assumption that it was mostly about aggregate reports, since failure reports 
are not commonly sent.

> My recommendation would be to roll this change back, and perhaps replace it
> with a reference to 4.1 and a "if you're a PSD, don't ask for RUF unless
> you really really know what you're doing."

I disagree.  That puts the (potential) fox in charge of the hen house.

> 3. - I think we need a brief paragraph outlining the
> experiment, and in it need to explicitly call out that a permanent solution
> needs to be determined for answering the "what's a PSD" question - which
> may or may not be

I thought I'd done that in Appendix A.  Please review and provide specific 
recommendations as I don't really know how to address this general comment.

Other than the typo, I'm going to leave my local copy as is while we wait and 
see what others think.

Scott K