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

Scott Kitterman <sklist@kitterman.com> Tue, 21 May 2019 04:40 UTC

Return-Path: <sklist@kitterman.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F2412011C for <dmarc@ietfa.amsl.com>; Mon, 20 May 2019 21:40:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=7vRfw5ml; dkim=pass (2048-bit key) header.d=kitterman.com header.b=CCjG2aeo
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQK6o2REY0SH for <dmarc@ietfa.amsl.com>; Mon, 20 May 2019 21:40:13 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826DD12004B for <dmarc@ietf.org>; Mon, 20 May 2019 21:40:13 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 66E61F8080B for <dmarc@ietf.org>; Tue, 21 May 2019 00:40:12 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1558413612; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=nghFTBU7TT0LSkRZp+Ck0VpraqrDEEgUumyj8FLJUIA=; b=7vRfw5mlbtR/3qffVOJ65jfGp23rKsnihdmITiIJLNbVwRLzMsBx/tHg 9ec0Xs1O3zLMPB2haVfArfYUcW6zCQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1558413612; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=nghFTBU7TT0LSkRZp+Ck0VpraqrDEEgUumyj8FLJUIA=; b=CCjG2aeoDS2lNgtqHuEadoSxw+Ig7BEdGu3902LLMK8gr8DLuN2j0Pl3 dYhteAYrYFHh/J8MFhCHit6hR7pNBbKCZTyn4Nun1z34Yn/05e6epWqrgX x7IipjTjHGP5EVW5/uuJnWEjNGzFH+zYbbxBSWgd85+Hr+DrFivtArHEXg qgUPXN2DJu897znfNkWENwjkP+B4xoLIDe3ksSUgdjXDFGrUUR/n4BU22P bD6w3jh8OVsUGrllu3/KN9cnM1bmSEhQ8pt1uCQk45RI9y7zNNAanbzIk4 LqR3wGyzo5AtrU50HbX5qJqHYeo7PbD/HfwuLIm0634Ogbwdqer1tQ==
Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 3354FF800DE for <dmarc@ietf.org>; Tue, 21 May 2019 00:40:12 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Tue, 21 May 2019 00:40:11 -0400
Message-ID: <389606103.N89IVunuJi@l5580>
In-Reply-To: <CAJ4XoYePshwHbG5XSttOpbPYtBPkEHJkk-G3o6k6-bK8fKJXnQ@mail.gmail.com>
References: <155728145158.24534.10112720017814447505@ietfa.amsl.com> <CAL0qLwaVXXuwUdF3LCshERTeqT20XYdXicFac_Ed-s6L5nogJQ@mail.gmail.com> <CAJ4XoYePshwHbG5XSttOpbPYtBPkEHJkk-G3o6k6-bK8fKJXnQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/hMd0tcjN9Dvjl6YXSYf24iFNTg8>
Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.txt
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 May 2019 04:40:16 -0000

On Monday, May 20, 2019 4:39:39 AM EDT Dotzero wrote:
> I also lean towards Seth's perspective. Additional comments in-line.
> 
> 
> On Mon, May 20, 2019 at 1:32 AM Murray S. Kucherawy <superuser@gmail.com>
> 
> wrote:
> > Hatless:
> > 
> > On Tue, May 7, 2019 at 7:30 PM Seth Blank <seth@sethblank.com> 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 example.com 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 agree with avoiding MUST NOT in this case for the reasons given (policy
> vs interoperability). I think SHOULD NOT with explanation of why might be
> acceptable.
> 
> > 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.
> 
> Michael Hammer

Having read the feedback from a number of people, I am inclined to revert the 
MUST NOT that I added in the last revision.  "Don't unless you know what you 
are doing" pretty generally applies to RUF, so I can see it being reasonable 
to not special case it here.

I'll wait to see if anyone else has any other changes we should make before 
posting an updated draft.

Scott K