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

Scott Kitterman <> Sat, 29 February 2020 23:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B35C3A15F3 for <>; Sat, 29 Feb 2020 15:47:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=1mn8BnH+; dkim=pass (2048-bit key) header.b=aycc4bjS
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jtq7F3kvoCgq for <>; Sat, 29 Feb 2020 15:47:04 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 32D3D3A15EA for <>; Sat, 29 Feb 2020 15:47:04 -0800 (PST)
Received: from ( [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by (Postfix) with ESMTPS id 46E73F802C0 for <>; Sat, 29 Feb 2020 18:47:03 -0500 (EST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201903e; t=1583020023; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=pazNeS9cVELQWZgoWCL+xHEHYcJk/6SE0agL/PfOjVk=; b=1mn8BnH+QzCkrDxXkS5rfM4hZ21sbWDOjkcFOTThlgEPXYKiabuzC53IA7dZGdZMJFewY 5y1pcJ1CM9I2AxvAg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201903r; t=1583020023; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=pazNeS9cVELQWZgoWCL+xHEHYcJk/6SE0agL/PfOjVk=; b=aycc4bjSjmsjC4WwUL2nc4dw6RwzFrBNqisCMiwhbuCHBIKcqjxFEecv6VKEwaCywtJg6 zJTBTBVirGaT2JBJtVE7OvEUJWKKOYGSYO08IqsvUbq2ieflqdHL6W+6/T+PIEI//ZZqgHU HntkRYvSPhsH4tT7JkU98HQeuazFyafUxUIE0vsbHKaEVbWQowo+Rfc+tQ6NzWSCKmainNy oxjRhnUt66iiClJ6VlGt9QE2FvV4O3qtlyaOpLkJSRxUbD0Vupzt7LF7EglAmXbfYKBZD9b Y4LuA40+lq2EzuAQs097radgckfNJw73Y8vH1DdWw9o0OEjxW5G5huXv51/w==
Received: from l5580.localnet ( []) by (Postfix) with ESMTPSA id 1C7E0F801F5 for <>; Sat, 29 Feb 2020 18:47:03 -0500 (EST)
From: Scott Kitterman <>
Date: Sat, 29 Feb 2020 18:47:02 -0500
Message-ID: <12785741.3Xnv7X5PKb@l5580>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
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: Sat, 29 Feb 2020 23:47:06 -0000

On Thursday, February 27, 2020 12:30:59 AM EST Murray S. Kucherawy wrote:
> On Wed, Feb 5, 2020 at 3:02 AM Craig Schwartz <> wrote:
> > First, while I know you've said the needs of external actors won't weigh
> > on your decision about moving forward, I would like to mention that
> > having a stable reference for PSD DMARC will help us with working towards
> > policy changes that would allow us to participate in this experiment.  It
> > may not be important to the WG Chairs' decision on the draft, but there
> > are stakeholders for whom it is important.
> Just to be clear, I don't mean to suggest the restriction you're referring
> to is invalid.  I'm sympathetic to the idea that some potential
> participants in PSD are constrained by policies outside of their control or
> ours.  But I look at it this way: A series of "X can't happen until Y
> happens" assertions have been made over the last while, and the series is
> roughly circular.  I don't mean to be insensitive to the pain of you or
> others under external constraints, yet at the same time, from the
> perspective of the IETF, those constraints are very much external and thus
> are easier to disqualify as we try (sometimes desperately) to find a way
> out of this deadlock we're in.
> I will also be somewhat ashamed to hand Alexey a deadlocked working group
> in March.  :-)
> With my chair hat on, I'm leaning toward making the following consensus
> evaluation: With a completed (and now seven month old) Working Group Last
> Call on the PSD document, and as far as I can see no sustained objection,
> we should proceed toward publication.  Unless someone wants to argue that
> this is not the WG's consensus, we'll proceed at the end of next week.
> To be specific:
> Dave raised a post-WGLC concern that DMARC and its use of the PSL really
> ought to be teased apart.  I have heard no objection to that, and in fact
> have seen some support for it, so I consider that also to have consensus.
> The part that does not appear to have consensus is that it is mandatory for
> this to be done before the PSD work can proceed.
> Dave also suggested that Experimental status is not procedurally
> appropriate for this work, and stated some reasons.  There appear to be no
> others lending support for this assertion either.  However, while I
> disagree, and I believe I gave an existence proof to the contrary, I will
> put this question to the working group: Can we solve this problem by
> switching the document to Informational status, and can the working group
> accept that outcome?  That seems an easy compromise, and I saw it proposed
> but not fully discussed yet.  This seems quite reasonable as well when one
> considers that PSD's proponents could very likely get the thing published
> as an RFC via the Independent Stream if they continue to find no progress
> here.  So, please discuss this option on the list and I'll measure
> consensus on it at the end of next week as well when next steps are chosen.
> Mike objected to PSD generally, also long after WGLC completed.  This too
> does not appear to have swayed consensus.  (And he's been cogitating on
> that thread for a few weeks now...)
> As a reminder, we still need to do AD evaluation, an IETF-wide last call,
> directorate reviews, and IESG evaluation before it lands in the RFC
> editor's queue.

As editor, I'm happy to update the draft to match whatever the chairs find as 

Personally, I think informational is fine.  I'll wait for direction from the 
chairs before doing anything.

Scott K

Scott K