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

Alessandro Vesely <vesely@tana.it> Mon, 28 September 2020 12:02 UTC

Return-Path: <vesely@tana.it>
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 CDA043A1097 for <dmarc@ietfa.amsl.com>; Mon, 28 Sep 2020 05:02:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level:
X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 aiFsgnYmaVps for <dmarc@ietfa.amsl.com>; Mon, 28 Sep 2020 05:02:46 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 35C1A3A107E for <dmarc@ietf.org>; Mon, 28 Sep 2020 05:02:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1601294561; bh=ZxEymcwSax9TBmaFGAbbh/89IkXV6g0puFAujzw2QQg=; l=4268; h=To:References:From:Date:In-Reply-To; b=CR3SmaHwwux2jLULkmYnkX3KjYphg8eWGZdo6fUqAUZpMNgMHffkQ0Uqd+BV0PyqS PRSMi0D6ILCbsu6dcbefykfq3030sXHTNYKYc5Wrhr36Tdxyx3Qz4GheVJaQg0s1E+ ZcxdwYmDkdQ6QGOx0F1LhQtupor7T4tv5aRHxMNhWC34Hsm+KpBgnu87aG9+I
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005F71D0E1.000040D3; Mon, 28 Sep 2020 14:02:41 +0200
To: Dave Crocker <dcrocker@bbiw.net>, dmarc@ietf.org
References: <20200815225306.967CC1E9E41D@ary.local> <6089649.VB6F1bvo3X@zini-1880> <159dc0da-0f34-fa71-e20f-89135f14182e@dcrocker.net> <6484002.GchzCIbhPQ@zini-1880> <aa8eb7e5-e16f-e99d-2164-5654ed0024dd@dcrocker.net> <af165f28-fab7-c339-1808-4c14e21631b4@tana.it> <12885242-5aed-ebba-644c-f629aac798ed@dcrocker.net> <52e6d0a6-3997-761f-b1b1-85420812691c@tana.it> <6a1198c4-9b2e-e812-4833-79b52b13e04b@bbiw.net>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <5272a624-12ac-4bc0-d6f9-5b5daad3346c@tana.it>
Date: Mon, 28 Sep 2020 14:02:41 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <6a1198c4-9b2e-e812-4833-79b52b13e04b@bbiw.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/dsMBEOdHggVamsT6KXV7YU9ykyM>
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 12:02:48 -0000

On Sun 27/Sep/2020 15:06:24 +0200 Dave Crocker wrote:
> On 9/27/2020 2:20 AM, Alessandro Vesely wrote:
>> On Sat 26/Sep/2020 15:06:54 +0200 Dave Crocker wrote:
>>> On 9/26/2020 3:31 AM, Alessandro Vesely wrote:
>>>> A pointer to a better aimed report circulated on this list:
>>>
>>> An unrefereed presentation (not paper) about a single experiment is better 
>>> than a summary of an industry-wide effort that failed?
>>
>>
>> I meant aimed at email rather than web browsing.
> 
> So?
> 
> If you think the industry-wide experiment that focused on signalling a trust 
> indicator and failed is less relevant than a small, single, unrefereed paper 
> about a preliminary and poorly-design research project is somehow less 
> relevant, please explain.


I think an industry-wide experiment on petrol consumption has nothing to do 
with email protocols, however refereed.  Web browsing has a minor share with 
email, as some people use browsers instead of MUAs.  Browser security concerns 
are rather oriented toward shopping and EV certificates, than email phishing.


>>> And, for the current discussion, there's the troublesome summary the they 
>>> give about their own study:
>>>
>>>> 1. Warning only slightly lowers the click rate
>>>> 2. The absolute click rate is still high
>>>
>>> The key words there are "slightly" and "still high".
>>
>>
>> "If one person eats a chicken and another person doesn't eat anything, on 
>> average they both ate half a chicken".  That's how statistics distorts reality. 
> 
> The fact that you think this statement is somehow meaningful suggests a 
> rejection of an entire, established field of study based on not understanding it.


Statistics can easily be misused.  Distinguishing a cluster of overweight 
people from starving communities doesn't reject statistics as a whole.


>> I'm sure there are users who watch authentication results, and usually take 
>> no bait.  For them,  "slightly" and "still high" don't hold.
> 
> Except that individual cases are not the basis for establishing industry-wide 
> practice.  Industry-wide behaviors are.
> 
> An occasional example simply isn't relevant.  That's the difference that 
> legitimate statistical analysis provides.


The statistical aspect of email is that it is mostly spam, at varying shades of 
gray.  Meaningful messages can be regarded as occasional exceptions in this 
respect.  Nevertheless, they are important.


>> And, there's increasing activity about anti-phish employee training.  As a 
>> consequence, the importance of visual hints is bound to increase.
> 
> Excellent.  So that means you can point to studies that show how effective such 
> training is.  Because the general sense is in the anti-abuse community is that 
> it has little effect.  But if you know of studies to the contrary, it would 
> very useful to hear about them.


Google Scholar shows me 83 results about anti-phish training effectiveness. 
Just talking about human-oriented solutions for phishing entails that users 
need to interpret visual cues.  Hence visual cues have some effect, however little.

Discarding the importance of of users judgement provides for a skewed vision.

Filtering out obvious spam can be considered a favor to users, to keep their 
mailboxes cleaner.  Yet, a deterministic protocol which determines what to 
reject and what to quarantine would relieve MX operators from the 
responsibility of arbitrary filtering based on obscure secrets.


>>> Prompting the question of why anyone would think this study serves as
>>> demonstrating strong support for the role of end-users in abuse protection?
>>
>> That wasn't the goal of the presentation, AFAIUI.
> 
> However it /was/ the apparent reason it was cited.


Yup.


>>> All of which demonstrates a basic problem with efforts to discuss 
>>> human-related work: difficulties in understanding how to evaluate research 
>>> and research patterns, with a tendency to instead lean on confirmation bias.
>>
>>
>> That's why it is important to enable each and every soul to exert their own 
>> judgements.
> 
> Actually, it's not.


Why have elections at all if the result can be forecast before the votes are 
counted?


Best
Ale
--