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

Dave Crocker <dhc@dcrocker.net> Sat, 26 September 2020 03:03 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 235A73A0F67 for <dmarc@ietfa.amsl.com>; Fri, 25 Sep 2020 20:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, 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 nwGsstLO9p0w for <dmarc@ietfa.amsl.com>; Fri, 25 Sep 2020 20:03:57 -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 8F5723A0F66 for <dmarc@ietf.org>; Fri, 25 Sep 2020 20:03:57 -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 08Q373wI007945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 25 Sep 2020 20:07:03 -0700
From: Dave Crocker <dhc@dcrocker.net>
To: Scott Kitterman <sklist@kitterman.com>
References: <20200815225306.967CC1E9E41D@ary.local> <6089649.VB6F1bvo3X@zini-1880> <159dc0da-0f34-fa71-e20f-89135f14182e@dcrocker.net> <6484002.GchzCIbhPQ@zini-1880>
Cc: IETF DMARC WG <dmarc@ietf.org>
Reply-To: dcrocker@bbiw.net
Organization: Brandenburg InternetWorking
Message-ID: <aa8eb7e5-e16f-e99d-2164-5654ed0024dd@dcrocker.net>
Date: Fri, 25 Sep 2020 20:03:51 -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: <6484002.GchzCIbhPQ@zini-1880>
Content-Type: multipart/alternative; boundary="------------39A102A1AAE52021B603A62B"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/_4C7uFHBb6ZnqDlrJjuij3qZ1T4>
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: Sat, 26 Sep 2020 03:03:59 -0000

On 9/25/2020 4:21 PM, Scott Kitterman wrote:
> On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker wrote:
> I think the obligation to justify is on the advocate for change. 

That means you are demanding I prove  negative.  Which, of course, is an 
impossible assignment.

Rather, the obligation is on the person claiming the affirmative, which 
in this case means the claim that this proposal somehow 'breaks' or 
otherwise hurts DMARC.


>      Because the current email protection behavior involves the
>     RFC5322.From field, and pertain to the human author, it is common to
>     think that the issue, in protecting the field's content, is behavior
>     of the human recipient.  However there is no indication that the
>     enforced values in the RFC5322.From field alter end-user behavior.
>     In fact there is a long train of indication that it does not.
>    Rather, the meaningful protections actually operate at the level of
>     the receiving system's mail filtering engine, which decides on the
>     dispostion of received mail.
>
> Please provide references for your long train of indications, speaking of
> making overly broad assumptions.  If that's accurate, I'd like to understand
> the data that tells us that.

I'm not going to do that, because there's a long history of that work 
being ignored, in spite of it being reviewed repeatedly in thse and 
related fora over the years.  It's gotten tiresome to have people 
claiming an effect that they lacks evidence for, and the data to the 
contrary that they are somehow unaware of.

Again, the real requirement is focus on the affirmative.

In this case, an affirmative claim that end-users are relevant to the 
efficacy of DMARC.  I don't recall seeing any research results 
validating such a view, but perhaps I missed it.

Well, ok, here's one that shows lack of efficacy, and it's a big one:  
EV-certs

/Google to bury indicator for Extended Validation certs in Chrome 
because users barely took notice/

https://www.theregister.com/2019/08/12/google_chrome_extended_validation_certificates/

"The reason is simple. "Through our own research as well as a survey of 
prior academic work, the Chrome Security UX team has determined that the 
EV UI does not protect users as intended... users do not appear to make 
secure choice..."


> If this is just an input into an algorithm, then your assertion that you are
> only providing another input is supportable, but that's contrary to the DMARC
> design.

Perhaps you have not noticed but the demonstrated field use of DMARC, to 
date, tends to be contrary to the design, to the extent anyone thinks 
that the design carries a mandate that receivers follow the directives 
of the domain owners.

So the text in the draft merely reflects real-world operational style.


d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net