Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

Dave Crocker <dhc@dcrocker.net> Mon, 28 September 2020 03:44 UTC

Return-Path: <dhc@dcrocker.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 349F93A0D46 for <dmarc@ietfa.amsl.com>; Sun, 27 Sep 2020 20:44:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.112
X-Spam-Level:
X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 nqlDv1FaQA6g for <dmarc@ietfa.amsl.com>; Sun, 27 Sep 2020 20:44:18 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 0B2D13A0D42 for <dmarc@ietf.org>; Sun, 27 Sep 2020 20:44:18 -0700 (PDT)
Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 08S3lOLT019916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 27 Sep 2020 20:47:25 -0700
To: Scott Kitterman <sklist@kitterman.com>, dmarc@ietf.org
References: <20200927171611.838B321D9BAD@ary.qy> <5069099.lO0Lvmlme3@zini-1880>
From: Dave Crocker <dhc@dcrocker.net>
Reply-To: dcrocker@bbiw.net
Organization: Brandenburg InternetWorking
Message-ID: <a4e016ba-673a-81f0-829b-b3b7adb6fcac@dcrocker.net>
Date: Sun, 27 Sep 2020 20:44:11 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <5069099.lO0Lvmlme3@zini-1880>
Content-Type: multipart/alternative; boundary="------------BABE150033EAE10E656F749C"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/2unkSIxFfwV7InouBmJe0ZW0w_g>
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
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, 28 Sep 2020 03:44:19 -0000

On 9/27/2020 11:22 AM, Scott Kitterman wrote:
> This seems to me to be an odd view because no RFC is needed to use From and
> it's relationship to either DKIM signing domain or SPF validated Mail From.

The DKIM d= value establishes no relationship with any other identifer, 
such as the From: field.  At all.  None.

DMARC establishes the relationship. DMARC does other things, but for the 
above suggested alternative, this is the functional difference that 
requires DMARC.

To reiterate: Among currently published specifications, without DMARC 
there is no relationship between DKIM's d= value and the rfc5322.From 
domain name.


> Feeding data into an algorithm has no interoperability requirements.
>
> That doesn't mean one can't use the data this way, because anyone can that
> wants to can.  That doesn't make it the specified protocol.

It's not clear what your point is.  It's clear you believe it's a 
fundamental point, but I'm not understanding it's import.


> ...  Maybe it would help if someone who takes the latter view would
> explain what they think RFC 7489, Section 6.6.2, Step 6 is for:
>
>>     6.  Apply policy.  Emails that fail the DMARC mechanism check are
>>         disposed of in accordance with the discovered DMARC policy of the
>>         Domain Owner.  See Section 6.3 for details.
> I don't think that says "then toss the results into your classifier".

The issue is not what it says -- though it worth considering whether 
that's what it /should/ say.

The issue is how receivers actually /use/ DMARC.

There has always be a tension about how to write these statements 
seeking to affect receiver behavior.  The natural tendency is to write 
language of simple directives, such as Step 6 -- after all, that's 
common language for basic protocol behavior.

However Step 6 moves from protocol into policy.  It is based on the myth 
that receivers will blindly follow the instructions that are provided by 
sites with which the receiver has no relationship, never mind a 
contractual one.

The reality is that Step 6 results in a mandate that often produces 
unacceptable results.

Receivers, having their own quality assurance models, immediately 
adapted their actions to their own operating criteria, rather than 
following the simple, blind directives of  random DMARC publishers.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net