Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

Jim Fenton <fenton@bluepopcorn.net> Mon, 27 May 2019 17:23 UTC

Return-Path: <fenton@bluepopcorn.net>
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 C95AB120006 for <dmarc@ietfa.amsl.com>; Mon, 27 May 2019 10:23:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net
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 seojxfv_LDbi for <dmarc@ietfa.amsl.com>; Mon, 27 May 2019 10:23:51 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6068E120043 for <dmarc@ietf.org>; Mon, 27 May 2019 10:23:51 -0700 (PDT)
Received: from [IPv6:2601:647:4300:2290:62a4:4cff:fe65:83dd] ([IPv6:2601:647:4300:2290:62a4:4cff:fe65:83dd]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x4RHNleq031322 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 27 May 2019 10:23:49 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1558977829; bh=kG3s3ycQCRvD78oMtt2wxC1wMljOkvuwSg6iKwYvgJI=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=jzgikz/Kkx65O0tPZIpFg5LqAISiI1XVNZUXUVofbQf7fOm7kfMMAJcltj7HFMIoC ST9V/SLZnUVMki75NUYnz+hQH/qr/d8NBzc3JHuJbjqO3Ey25JvkXg9sJJ4NOZ7Jbx bWoXxQJXOZybrAXGthPvomx+ZvFvckTCKLnZ/c5A=
To: Dave Crocker <dcrocker@gmail.com>, John R Levine <johnl@taugh.com>
Cc: dmarc@ietf.org
References: <20190523225213.C214620147B780@ary.qy> <ab587c42-dd2f-2403-999a-c7d559764726@bluepopcorn.net> <alpine.OSX.2.21.9999.1905241036450.50141@ary.qy> <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> <789c58b1-7b45-3af0-dd1b-aca0c415db02@gmail.com>
From: Jim Fenton <fenton@bluepopcorn.net>
Message-ID: <5f12bf4f-ce25-c2d8-7cab-10eb41182eac@bluepopcorn.net>
Date: Mon, 27 May 2019 10:23:42 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <789c58b1-7b45-3af0-dd1b-aca0c415db02@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/5LyyidE1g5xvUUDsG8BUq4il8vI>
Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy
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: Mon, 27 May 2019 17:23:53 -0000

On 5/25/19 1:53 PM, Dave Crocker wrote:
>
> Ultimately, you are asking marketing questions, not technical ones.


OK, so let me ask a technical question: What is the technical 
justification for the requirements in Section 8? For other protocols, 
there are mandatory-to-implement requirements (RFC 6376 section 3.3 for 
example) that exist in order to ensure interoperability between senders 
and receivers. But implementation of DMARC policy and DMARC reporting 
can separately be useful without the other.

Aren't the requirements in Section 8, which effectively say "you need to 
do this and this to call yourself a DMARC implementation" really a 
marketing, not a technical consideration? Does this belong in the spec?

-Jim