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

"Murray S. Kucherawy" <> Mon, 20 May 2019 05:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF6C312006A for <>; Sun, 19 May 2019 22:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 A3jebrRHVkEF for <>; Sun, 19 May 2019 22:32:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77A85120041 for <>; Sun, 19 May 2019 22:32:08 -0700 (PDT)
Received: by with SMTP id v18so9314209lfi.1 for <>; Sun, 19 May 2019 22:32:08 -0700 (PDT)
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=pZK4++LUBAvfq/V9hSe4kPetf+1ZoNwZfuHyHm/6fZU=; b=TjjSd8jMMG9eYTIQpx01rez/cvjKpGF1ajPiQJ8ihg25zYCOlVV5Z0pAbCEyHAOzsX oLEoRUptptvL2IZ6i8QO4R/PhO9MJIK9blkCGZE9vPh4qESGXg8O2K3PuH4NFCkuhu4S dgFW9G+xqicjsyVZGFxixUChcQmCAD2C1fnqKGRVa5oe+TOuXRBjvkTmQcZHwfG5k7mg EpWI7eYLzmVO9qa7GCB1ET4VscPdtGhFlIR0LUUxb/mVMXD/nuS6DoeKolbYTHWsgOmi fJsFQ4Hy3dCG1M+tem/U0Fz62W3h29+0RLfoVF8uucN/cnWg/uwqGziUyAeRJpSRXKoF cMBQ==
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=pZK4++LUBAvfq/V9hSe4kPetf+1ZoNwZfuHyHm/6fZU=; b=sviKVIXzneSU6GC6lPa3nHoG74FT5nIIlKsqrud0BJSi57+s98p+O39i07FO7SYAvd jME7NDjpnh6vZ8XJMgXSWxFkGPr6Mubc+qxUQ9ctJIhn9elJ8BvFIXPuDdYrT4g5I88N PUcJrlZhuJtRIR2iF2iWVwn2ZpiiDkw485hJS7o7Z8wyvPM9NXCwnOP94gxj6tWvh0KW wzdptpsDCwhFTtMGrOHXa0pUCtJt0aSlZ3uTyaoMiM+day0EFwQTnPLozS5oo22MTKdO YRh+PFiiPNk6eB+Xx1uwwkUTBNW0ZPETHclZ34LOBFUtpqFXDie72kLpSYDvaW5C25K0 tNCw==
X-Gm-Message-State: APjAAAWSA3R63OpG4RboA6r3fmMZKOg/RRDYSNLnwu610jfT/7pCdxrI gigS4TIQUwgaDJSnp0dgpbCyP8Pg+GR5UHu4MAs=
X-Google-Smtp-Source: APXvYqyblvsEnSRzUMeOxju2oYJQ33nwKC/mr/D6jbQd6usBwLRguZxUGkX3bQ5pHibRD3isrx1bw5HrJX/j/CMhArI=
X-Received: by 2002:ac2:5935:: with SMTP id v21mr24705810lfi.117.1558330326609; Sun, 19 May 2019 22:32:06 -0700 (PDT)
MIME-Version: 1.0
References: <> <2699063.PiBShnsfcX@l5580> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Sun, 19 May 2019 22:31:53 -0700
Message-ID: <>
To: Seth Blank <>
Content-Type: multipart/alternative; boundary="0000000000008f739e05894b0dca"
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: Mon, 20 May 2019 05:32:11 -0000


On Tue, May 7, 2019 at 7:30 PM Seth Blank <> wrote:

> 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.

I've read Scott's replies to this as well.  The question I have is whether
we have consensus to include this change, but that's hard to gauge when
there's been so few names offering comments.

I'm partial to using MUST NOT only where it goes to interoperability, so
I'm inclined to agree with Seth.  However, I've been nudged away from that
position on this in the past, i.e., that it can be used to encourage best
practices and there's ample precedent for such.  Still, given other replies
on the topic, especially the presence of "unless you know what you're
doing" in some of the dialog, I'm wondering why this isn't a SHOULD NOT
with an explanation of why, and in what circumstances one would deviate
from that advice.  There are aspects of the discussion in this thread that
would be valuable to implementers (summarized, of course).

I'm also inclined to agree with Seth on his points of complexity, and on
moving contrary to DMARC's tenets.

Having said all of that, I'm not firmly resisting given that the plan is to
send this up as Experimental, as its deployment and results could usefully
inform our choices with respect to standards track DMARC.

While you all stew on that, I owe the group a top-down review of it
and the start of a shepherd write-up, so I'll do both this week.