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

Scott Kitterman <> Thu, 09 May 2019 22:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A3E6120128 for <>; Thu, 9 May 2019 15:03:19 -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_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=zeXaUxIZ; dkim=pass (2048-bit key) header.b=FSEr9CfN
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tm59QkQ1i6SY for <>; Thu, 9 May 2019 15:03:17 -0700 (PDT)
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 2BA7B12008A for <>; Thu, 9 May 2019 15:03:17 -0700 (PDT)
Received: from ( [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by (Postfix) with ESMTPS id E4B57F8074A for <>; Thu, 9 May 2019 18:03:14 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201903e; t=1557439394; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=5vuQere448l87zkiN5aCO5ffWk0sKXapEceBeQKyJZ4=; b=zeXaUxIZ29L95zJkR+xCObglDn1Pz3jIm+Sh77a1Ki5+FF5GxWOsSRWy oMc+iyUsbDBDstoliV9RdzWZXKQZBg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201903r; t=1557439394; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=5vuQere448l87zkiN5aCO5ffWk0sKXapEceBeQKyJZ4=; b=FSEr9CfN/pgkL4q2GzEvbkDs/8xylJqJzxGYokgwdTlXb9O+U3X5MLeM ZZJQsPj/0j4w1eslcehDhfKmyS7vIxWNlY10dNISzpnjvsHtkbiNFL+bdp 5UXmyaejB/NqJ/Bj86lUI4qL4advd/7tQd6TLce+dKt32RlGMUyAwYEEM2 putyiWpeRbfw2NKsLLwZXjcbZQg8uN6+eD3qvWJu5pHl888e2QDEbogldw e6pkddc4NUekTBzsG1cC3BsKdFMj6namulMCE+/nEd4IJvzhJCortwxyr/ jQHtrRXPiPZTYVmVppGLADiB3ZyJA8L25Hlbix7ez8enPnSj+YabOg==
Received: from l5580.localnet ( []) by (Postfix) with ESMTPSA id ACB9AF80721 for <>; Thu, 9 May 2019 18:03:14 -0400 (EDT)
From: Scott Kitterman <>
Date: Thu, 09 May 2019 18:03:14 -0400
Message-ID: <1694180.CbOjR3XESQ@l5580>
In-Reply-To: <>
References: <> <12992594.LUNhQVcRDa@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 22:03:20 -0000

On Thursday, May 9, 2019 1:35:28 PM EDT Seth Blank wrote:
> On Thu, May 9, 2019 at 9:39 AM Scott Kitterman <> wrote:
> > In theory, I agree, but in practice, I think the new MUST NOT is a great
> > change to promote implementation simplicity.
> This increases complexity. With this normative requirement, we're adding a
> third lookup that behaves differently than the previous two. This
> complicates the experiment and solidifies a (good) policy consideration
> normatively.

Either way there's a consideration.

If there's no MUST NOT, then any entity that does failure reporting needs to 
consider if they should do it for PSDs and if so, which ones.  That's a 
question that, at best, has a squishy answer.

If the MUST NOT is present, it's a straightforward processing change to not 
apply failure reporting if you got the result from a PSD lookup.

Either way, entities that don't do failure reporting now, won't be affected 
(which is almost everyone).

The changes to add PSD DMARC to an existing DMARC implementation are not 
complex, but they are required.  A clean implementation requirement while 
you're updating related code it, IMO, much easier to deal with than vague 
policy guidance.

> > > 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.
> The first bullet of 4.1 is incorrect if RUF is MUST NOT for PSD.

I agree a small change is needed.  If we leave it the way it is (with the MUST 
NOT), then it would be appropriate to add that the MUST NOT requirement fully 
mitigates the privacy concern as it relates to RUF.

> > 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.
> You're absolutely right, you did.
> I do, however, think there's more to the PSD experiment than just deciding
> where a PSD list should live - the crucial bit is if this actually
> addresses and demonstrates value (i.e. stops spoofed email) for the use
> cases discussed in Section 1.

I don't think so.  We know technically that it can do so.  There is no 
technical question in that regard, so nothing to experiment over.  Will people 
use it isn't really the proper basis for an IETF experiment.  The IETF 
publishes non-experimental RFCs all the time without any particular data to 
suggest the RFC will get implemented and deployed.

I think how to get the privacy issue mitigation correct is the only technical 
issue that needs experimentation, but I may have missed something.

Scott K