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

Dave Crocker <dcrocker@gmail.com> Mon, 27 May 2019 18:25 UTC

Return-Path: <dcrocker@gmail.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 9C40E12009E for <dmarc@ietfa.amsl.com>; Mon, 27 May 2019 11:25:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 dQJmHZyI9ROU for <dmarc@ietfa.amsl.com>; Mon, 27 May 2019 11:25:19 -0700 (PDT)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3792B120041 for <dmarc@ietf.org>; Mon, 27 May 2019 11:25:19 -0700 (PDT)
Received: by mail-oi1-x232.google.com with SMTP id t187so12451894oie.10 for <dmarc@ietf.org>; Mon, 27 May 2019 11:25:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tTvSm61Ms6YG64Bs8TbEGLMPS4SrNP8jlUP8tGD+/5g=; b=AJ7rAwvhX43ib4hPWS+bqVyxB/X9vCwmSTP5OrgJRwoScDszbRu4QJVIvrIASBfH3u AfWsBjNcHpsnzTD65fRpaaLRqT7vpSw0jwHmLLSWBXh9dsBhx4lT9q15KyJX4MRTMetz hKaTKFMQ4YLIxj+I1tqwqE7cosDS68SPai2Q3MUzmrxZxhnj0J5A1BjB5ERrUcNz7gDC 0NVUa/wmfjnu5YTagoNLAVl7IkkoTYZk4uMgNeyEJ97FLzKXpYJg5TYUG862oBAmoVkD S5q+oEC4JpUTRUYC10gXYwJWTC/5Z3PlxXzBxjqWPkmFvcYmHE8qexL9+M1KZhM2ribC NopA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tTvSm61Ms6YG64Bs8TbEGLMPS4SrNP8jlUP8tGD+/5g=; b=EPUv8+0ta5lghl/sLjW8Ru8+L3mViUFj+R4fbHZCLPTfjSlDSP3zb4G4u+NLRj2m8I dAAuJ66W3C7HZC4IKnUgowomNum2Rd4l+lP+Tu40T3MFalidJXdNjsGJEdSZP5NOAx7D dB0vwD//5s79JYenr8iiaL7up58eDHIkSBW0OTmVt+fPNK0tXi1XhBw+GRmoMhb5VS5C OK9brbwUE7/pWs8rr7eay13qHt2E3va1E9KLaeMb/+Wn2MCqV2aZxUfxNuGdIvSrScH0 Bj8pXJWJnik+5lRhW6tgKIFxPrXuSUjuWJ2kU2hWwNISN0JZz4wUPg+EiCEfp7an/l3h 3trw==
X-Gm-Message-State: APjAAAXGe6uZ6yjhgZqFrsWTvXaSCjHEvx+QrvmNSVT6EuRUQy4M1GKN thIwITbQf7UGVRUPW//NisWZrLRRVek=
X-Google-Smtp-Source: APXvYqzrwhrJdD971Ms19s7Ei9v+0ym63A7YuTo2kkuidBRxe6enLoNrUgvkv5FcvURzVaPkSCw72A==
X-Received: by 2002:aca:7549:: with SMTP id q70mr216542oic.58.1558981517639; Mon, 27 May 2019 11:25:17 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:cb:6602:ff02:8d00? ([2600:1700:a3a0:4c80:cb:6602:ff02:8d00]) by smtp.gmail.com with ESMTPSA id 62sm4396425oid.35.2019.05.27.11.25.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 May 2019 11:25:16 -0700 (PDT)
To: Jim Fenton <fenton@bluepopcorn.net>, 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> <5f12bf4f-ce25-c2d8-7cab-10eb41182eac@bluepopcorn.net>
From: Dave Crocker <dcrocker@gmail.com>
Message-ID: <b1192f9c-0816-c333-54bd-df2ad10c701b@gmail.com>
Date: Mon, 27 May 2019 11:25:14 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <5f12bf4f-ce25-c2d8-7cab-10eb41182eac@bluepopcorn.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/YsMs_JC_q1czaxx5TII9feSege8>
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 18:25:21 -0000

On 5/27/2019 10:23 AM, Jim Fenton wrote:
> 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, 

A section like that typically seeks to establish a basis for minimum 
capability of usable implementations.  It sets expectations for 
capabilities and limits.  An amusing bit about this particular one is 
that, in spite of having the word "requirements' in the section title, 
none of the content language is normative.


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

I don't understand how your last sentence, here, applies to the subject 
Section 8.


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

"to call yourself" is a perspective neither offered nor implied by the 
section.  A marketing goal might choose to use it for that purpose, but 
there's nothing in the language or substance of the section suggesting 
that use or designed for that use.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net