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

Scott Kitterman <> Tue, 04 February 2020 22:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C8B6120130 for <>; Tue, 4 Feb 2020 14:05:29 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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=pj26Idgx; dkim=pass (2048-bit key) header.b=FAW7LNOT
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fQJXAJaMVxBa for <>; Tue, 4 Feb 2020 14:05:27 -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 B4A7912003F for <>; Tue, 4 Feb 2020 14:05:27 -0800 (PST)
Received: from ( [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by (Postfix) with ESMTPS id 6A1F8F80308 for <>; Tue, 4 Feb 2020 17:05:25 -0500 (EST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201903e; t=1580853925; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=h0tjKz2spg4MrlL88POFBnqCHqlo5V5F18fLigLGVk0=; b=pj26Idgx8P6+N1ASQcRTGzzTi5jjQKZJhyxfnqd/urr3U73RjsoK8ZYk hpUa711X/AHZWHgc6sua1MXoaOztCQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201903r; t=1580853925; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=h0tjKz2spg4MrlL88POFBnqCHqlo5V5F18fLigLGVk0=; b=FAW7LNOTdJI/Avh/1661QRQvAAf6eJ9wP7/4E/wNM8IR+Rwuuf7B7vDv mkVbQbjK83KX1MPNfW+XMgt/sZMfEupJzxoewfldYbxCcfXkZa943PUlBc WfjBffwzvtTb07Ff9OlodpN/nk+XNuOqxfFw2+Lu32M4eh1C/NO0lCMrPb y7OC28imIBjl55PiPjX2yzdsFdKv76LpeRcb6hCv15Le5vKywJpkFK8CAM Dn0l8x39lOeF+OvxkWxdP7udnj9zzouKQaBjxuDqSwKGggSR1V2knkOXdg d2Er8vOus2GFCuHwzGECR5rSz98Ldx7Q/nBodjP1p1Zd+Y7I4Z+osg==
Received: from l5580.localnet ( []) by (Postfix) with ESMTPSA id 2CC2DF801EA for <>; Tue, 4 Feb 2020 17:05:25 -0500 (EST)
From: Scott Kitterman <>
Date: Tue, 04 Feb 2020 17:05:24 -0500
Message-ID: <1992438.9lekWDq1mR@l5580>
In-Reply-To: <>
References: <> <9467613.0cjHueyR6G@l5580> <>
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: Tue, 04 Feb 2020 22:05:29 -0000

On Tuesday, February 4, 2020 4:26:30 PM EST Murray S. Kucherawy wrote:
> On Tue, Feb 4, 2020 at 1:20 PM Scott Kitterman <> wrote:
> > I agree on DMARCbis.  I don't think advancing this draft has a significant
> > effect on that.  Worst case, if DMARCbis is done before we can reach any
> > conclusions about PSD DMARC, then we publish DMARCbis without PSD DMARC in
> > it.
> I think we've always been assuming that PSD DMARC would be input to
> DMARCbis, so we were planning to start the latter but not close it until
> the former was completed.  This is the first time I've seen a different
> suggestion.

I think DMARCbis will take long enough that that is how things will work out, 
but if there's working group consensus to eventually proceed without it 
because it's not ready, that may well be a reasonable course of action.  
Proceeding with DMARC PSD doesn't tie the working group's hands.  I agree 
that's been the plan, but if the situation changes (and DMARCbis is ready, but 
PSD DMARC isn't ready to be included) then we can change it.

It does occur to me that a more relaxed approach to the question of if PSD 
DMARC will be included in the working group DMARCbis deliverable would be much 
easier to sustain if there was a stable reference for it (i.e. we publish the 

> I'd love to hear more opinions about ordering of the work here.  This seems
> like an ideal time to review and update our milestones.

I think it's not predictable when DMARCbis will be mostly complete and it's 
also hard to predict how long it will take to resolve the open questions in 
the experiment.  They can run in parallel for some period of time and we can 
make a decision when there's one to make.  There's none needed now.

> > I don't see anything about PSD DMARC being inherently on the critical path
> > for
> > DMARCbis.  I suspect the current major obstacle to DMARCbis is that the
> > question of how to take the PSL out of the equation is unsolved, despite
> > one
> > IETF WG that was supposed to be dedicated to the question.
> > 
> > I don't think not publishing PSD DMARC helps move DMARCbis forward, so I
> > think
> > it's a false choice.
> I think what Dave proposed about PSL separation from DMARC is entirely
> appropriate and pragmatic, and in fact probably easy enough: DMARC is
> changed so that it says the organizational domain is determined using some
> process [currently] external to DMARC, and then a second document explains
> how that process is accomplished using the PSL (and/or PSD, depending on
> when the experiment result comes in).  That's a fairly simple edit overall,
> and is actually probably minor and non-controversial compared to some of
> the other surgery that I believe is in the queue.

That's exactly the approach PSD DMARC takes about organizational domain, so 
I'm even more confused how that's problematic for PSD DMARC but doing the 
exact same thing solves the problem for DMARC?

I also don't see how that actually helps.  It seems to be something along the 
lines of claiming DMARC no longer relies on the PSL, but telling people to pay 
no attention to the man behind the curtain [1].

Scott K

> Seth, our illustrious WG secretary, has been compiling that list, and
> perhaps can give us some idea where it stands?
> -MSK