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

"Murray S. Kucherawy" <> Thu, 27 February 2020 05:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FB063A120C for <>; Wed, 26 Feb 2020 21:31:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DzKZNQWxG-sw for <>; Wed, 26 Feb 2020 21:31:14 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::933]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9F8CD3A1210 for <>; Wed, 26 Feb 2020 21:31:14 -0800 (PST)
Received: by with SMTP id w15so534539uap.0 for <>; Wed, 26 Feb 2020 21:31:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p+c/zh2fAI/SsiCXAps07qpOcCfjEhiyFpjJdS/YR9M=; b=vDZOHS3YHUpZrcdhB7P03h0gvx3gBpg/iZU3X9UBHUp+JH2yZCboHDWcuUxAL8ECmv JYwKXKVGDoq6SKg9hB/IIiyZtaO0SWtHD+0Rd1vT3x41IvtBUaLcr1BX9/xKLFxqZMRu buZL/fMba3CDwNEtDTFOcBOmj24vQtndDapyQMIbj/WiNF96aqQ7XMCQF4lu6ph8cF5B tZKpvUj77CWBUNO3bRzk5AjGEfnj2xudFcMLxZILTwuKY2D7ZK4Q5qdjh7j7BZ1Vm5H6 YEubaUAV68gWaWzZLdqFhjd+VR9qqzhSorvdK+NHRRkJesujQ5XjNY+Pk+HQvYq12yJ+ Jcew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p+c/zh2fAI/SsiCXAps07qpOcCfjEhiyFpjJdS/YR9M=; b=aRjMR8PdPaL/tVWy6zBUFhqvWGv8y+8yzCnXw16m3P1GaI2b4bAlTvXFHLVUc7OcrT /PTt6EOWsF2uQFkVDKPCoF4rWnFx1afcXeGYQMESayI1XKbEbDWJkGK3L+545dCV6pnA PS3GpWdCkFmmrHI1NQDzpXUDvhtonBwLP0BpRSF8DRHpaGWBojNZGHBRQMaS/aQhN/Bu ZZb9iJcyFIzzXyPbqxwUmuE8SjMUxyV8HXKgXLFPAwTMKDY1Ze9f7yVWCargE63HbFrV VcziHQzeQyjgJtptXFMPzMjT0pfZmJD1AR1WPKF7wrjrH7rLsz/CYH5QHdOcNCZalebm kiXg==
X-Gm-Message-State: APjAAAVl8fP/NlwJKahaXNHMe3n/0jCmsCM+Vv7gcyFVDNRpU8FdiKes SJ+wtjbo1UA4Wffg3jhLWESHHfoYm9z8IIC2klDi1g==
X-Google-Smtp-Source: APXvYqzkYg5hwBdhUgHNX2ffWJb8sD2N1/b6To5bplq4PHKsF+XErtk80twOCks6fH/vxKAeJGjKtzl8pxns3ncDM1k=
X-Received: by 2002:ab0:7358:: with SMTP id k24mr1525289uap.87.1582781473456; Wed, 26 Feb 2020 21:31:13 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Wed, 26 Feb 2020 21:30:59 -0800
Message-ID: <>
To: Craig Schwartz <>
Content-Type: multipart/alternative; boundary="0000000000007b8661059f880725"
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, 27 Feb 2020 05:31:17 -0000

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.