Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?

"Douglas E. Foster" <fosterd@bayviewphysicians.com> Tue, 21 July 2020 11:06 UTC

Return-Path: <btv1==4718526a20d==fosterd@bayviewphysicians.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 2F0043A0A55 for <dmarc@ietfa.amsl.com>; Tue, 21 Jul 2020 04:06:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.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 GaLlvGYjc6ac for <dmarc@ietfa.amsl.com>; Tue, 21 Jul 2020 04:06:06 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B03A3A0A50 for <dmarc@ietf.org>; Tue, 21 Jul 2020 04:06:06 -0700 (PDT)
X-ASG-Debug-ID: 1595329565-11fa3107a82d9e0001-K2EkT1
Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 4eUJYT3bPGY9o4hp (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Tue, 21 Jul 2020 07:06:05 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=BTKO3TgagYwY8Fe52StIveBFoUFwO/sbDO/KuKWkPUY=; b=SQpwaU7+p8/vG0B7K7jfAugKyIJQrGwpe2r7NVY4AFSAMeTUfKOvXgmS+Zry0xZsd cXpiUYlyikPgOUKa4iAX2VljnGkHq7b9pShTr91keqxUf5vvspZGipfDt+k9tnLgA PbRLmyZtv0vUpruWzrsa/to/dqMQKpCvg9c6JkucY=
From: "Douglas E. Foster" <fosterd@bayviewphysicians.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>, Laura Atkins <laura@wordtothewise.com>
CC: IETF DMARC WG <dmarc@ietf.org>
Date: Tue, 21 Jul 2020 11:05:55 +0000
X-ASG-Orig-Subj: Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?
Reply-To: fosterd@bayviewphysicians.com
Message-ID: <74a6fb5f7578452f9080cddb8ebbc8f5@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="21ff3b34e8174c76868031889a61971c"
In-Reply-To: <CAL0qLwZRYb4yk_WJKizR0UA97XK3VedfZw73YgyTPHuOpxZQhQ@mail.gmail.com>
References: <cd9258e6-3917-2380-dd9b-66d74f3a64d3@gmail.com> <20200717210053.674D61D2C431@ary.qy> <CAL0qLwbkhG-qUyGqxaEjcFn2Lb7wPMhcPFEMA8eqptBJpePPxA@mail.gmail.com> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <CAL0qLwbK7GQXkiS+H8GtsvHMzWr4o431Shc7Cc9MhqsTiHfzFw@mail.gmail.com> <bc7ed18c-8f1d-b41b-0a4b-3aa180a63563@gmail.com> <CAL0qLwYgs7py1aTQ87pykNT_0dpnrKz=+1DxMMSQMgbwz4XZDg@mail.gmail.com> <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> <CAL0qLwZRYb4yk_WJKizR0UA97XK3VedfZw73YgyTPHuOpxZQhQ@mail.gmail.com>
X-Exim-Id: 74a6fb5f7578452f9080cddb8ebbc8f5
X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1595329565
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 5081
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83353 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/fh-gyYke-_QfjJpdxj0hCAQxBGk>
Subject: Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?
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: Tue, 21 Jul 2020 11:06:08 -0000

I would like a better understanding of why MUAs are hiding or removing the FROM address.

I have one mail store that formerly used hover-to-view, but recently changed to always-show.   This was done in response to a client request on their support forum.  I have never seen a user ask for the From address to be hidden or removed.  I wonder if this trend is driven only by attempts to optimize display space.   It would be a shame to weaken our protocols in response to this trend, if the trend lacks a theoretical foundation.

I also wonder if the trust indicator research is being over-applied when it is applied to the From Address.    From Address is a unique identifier, while Friendly Name is not.   A trust indicator is like putting a green check mark next to the From Address as a trust indicator.   They have different levels of relevance.   

One attack method steals a contact list, then emails people in that contact list using friendly names of others in that list.   Hiding the From Address plays into that attack.

This trust-indicator research also promotes despair.  The conclusion is that users process information poorly.   This result then becomes an excuse to withhold information from those users, or to allow misleading information to be presented to them.    I am not convinced that those are appropriate responses.   "Never" is a hard thing to prove.  So it is risky to say users "Never" use available information correctly, and "cannot be taught" to do better.

Attack filtering is designed on a layered defense and a sequence of probabilities:
What is the probability that this attack will get through my spam filter?What is the probability that the user will read the message?What is the probability that the user will click on the hostile link?What is the probability that my web filter will allow access to the hostile website?What is the probability that the web filter will allow the attack to be downloaded?What is the probability that my antivirus program will allow the attack to proceed?
The goal is to decrease the probability of a wrong decision at each point in the process.   All I need is for some people to act smarter on some occasions in response to some available clue.   But this cannot happen if the clue is not provided..

Doug Foster