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

Jesse Thompson <jesse.thompson@wisc.edu> Tue, 21 July 2020 21:45 UTC

Return-Path: <jesse.thompson@wisc.edu>
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 96FD53A0AC2 for <dmarc@ietfa.amsl.com>; Tue, 21 Jul 2020 14:45:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-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=wisc.edu
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 XMiMGVYdvSfd for <dmarc@ietfa.amsl.com>; Tue, 21 Jul 2020 14:45:12 -0700 (PDT)
Received: from wmauth2.doit.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (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 07F763A0969 for <dmarc@ietf.org>; Tue, 21 Jul 2020 14:45:11 -0700 (PDT)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2044.outbound.protection.outlook.com [104.47.66.44]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QDU00JH29R9T8A0@smtpauth2.wiscmail.wisc.edu> for dmarc@ietf.org; Tue, 21 Jul 2020 16:45:09 -0500 (CDT)
X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU=
X-Spam-PmxInfo: Server=avs-2, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.7.21.213917, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.7.21.5750001, SenderIP=[104.47.66.44]
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D96iNa9z+HEg+dfWwfgVv3ytzC9AEE3vB9u8qcuHZ1zmnVapE5OFxfuzcm+aYyvuwU52sZx0XGeUuBrzNQNVdiarkxOU7X36ItmzAiPGm0WWMkXYpCpkbtNqujAJNMXJd9v6VLVl2jiWcmw7zw4GHMLS3gcxnFJgYwsQZONZQlkJqFYGHifLyJDOFDxa38lNxRAKO7IdrtI1eMsTE3Alt7QxKp2KUKvRsbJQwpWxmpRP0ml2MDstitB9x5GQbmgaTZCpBT7wcbQtSMln4mlJTVCkbmfTcab1vbYdKh/fbc4ZUluvA/L6gmMwzWBI/tnu0XF0JtEb3xhccAv8b6f66w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ORNNzckZrT/xaG9fUe7nkFh3/fbkAS66jLYq4M51CCo=; b=Dq41I1ecegHVEqc42pz9HH1VEXZ06QPAu+7As3jH/1VnsN3BSy70Wkv8ORXKqUX+yu6jVnQkYN+aOgp3yDrTdrapUAPp17p067E8e4KrTSrUAwYCQcvT+/M1puLrhjpZSqPPUgsH6kynxBA4Bqt/hHHqrUciA0hxqoCv/uE39K5SmD2Fo3Y+UEhp+9uujFkAVHAyXwEzWzA/tM1LeUpml4u0svlE5O68hzbgKGsIhBNBt8emYdeLO30VFDaNbI7KNe0aK2g3w3/3gqPcJF6rMgRBouqXKxY9DPGGHgIPANhGmAV/kebDZukl/tj3AsGWl/+b8+6hGnDPq4mmYP8LYQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ORNNzckZrT/xaG9fUe7nkFh3/fbkAS66jLYq4M51CCo=; b=hEymQxkUYqylAsSBv6WeBqesrxeEbRDRMrF3VdJpAp7cU1fZApXif+hBP4Ah4dcj5QWjVkN8NtFYRFnB5FbQgcEe4z8kDAQdMlZyf+tBgBMGRMIggtoKgIzjhpDYczeaeHQTAZ1V6+myybOwG86jmx+zSlQ/PfrSLVDrhV5JRM0=
Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM5PR06MB3130.namprd06.prod.outlook.com (2603:10b6:4:3e::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.23; Tue, 21 Jul 2020 21:45:08 +0000
Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3195.025; Tue, 21 Jul 2020 21:45:08 +0000
To: dmarc@ietf.org
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> <74a6fb5f7578452f9080cddb8ebbc8f5@bayviewphysicians.com>
From: Jesse Thompson <jesse.thompson@wisc.edu>
Message-id: <adcc1359-6bb6-1237-2967-307b49557cf4@wisc.edu>
Date: Tue, 21 Jul 2020 16:45:04 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Thunderbird/80.0a1
In-reply-to: <74a6fb5f7578452f9080cddb8ebbc8f5@bayviewphysicians.com>
Content-type: text/plain; charset="utf-8"
Content-language: en-US
Content-transfer-encoding: 8bit
X-ClientProxiedBy: CH2PR04CA0004.namprd04.prod.outlook.com (2603:10b6:610:52::14) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16)
MIME-version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [10.0.2.111] (47.12.96.133) by CH2PR04CA0004.namprd04.prod.outlook.com (2603:10b6:610:52::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21 via Frontend Transport; Tue, 21 Jul 2020 21:45:06 +0000
X-Originating-IP: [47.12.96.133]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: b9ab6afc-879f-4494-a80b-08d82dbf5563
X-MS-TrafficTypeDiagnostic: DM5PR06MB3130:
X-Microsoft-Antispam-PRVS: <DM5PR06MB313094FF2AE3A464748684FFF6780@DM5PR06MB3130.namprd06.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: I67piowZPaBgAaFFxfVvDU0fCoJvmbzr7zEmnZJw7R04RycTkejdT/UHdwm3SjTCb+n4xGx0FaYFIqd4tFcFDtt1sQonuR9q2sSx5lscwgZtJGfw/UYasXmdaqDUDi3h+BaYuI0LK/HQXEIjekvDc1hKFlvhg0oa7ZM2JW6+grKfqeOg2g+toPFXAiqv4RFoqzfMeu4H17lYPlgfA0+SnIR4V/l6AymZBfudYfyg/vgJ1NJmj3AYIB6Hjc48DE/4RaSV8DTeGiHXlkCXCrPmsn9YB5Gdb2ny2kkJc1E1MFRVFx84IrnDkmvnUNLeDxRrv4rhjlBXVCUJhbFbvgPu3XfZlxEAtPjcsRwG0mpnh/fr3bi0aPzVyj0pRt+7oBXx
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR0601MB3671.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(396003)(366004)(136003)(376002)(346002)(39860400002)(66946007)(66476007)(83380400001)(66556008)(75432002)(5660300002)(36756003)(6486002)(2906002)(316002)(8676002)(8936002)(2616005)(31696002)(31686004)(956004)(478600001)(16526019)(44832011)(26005)(186003)(53546011)(45080400002)(86362001)(786003)(6916009)(16576012)(43740500002); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: +sD3I9Wv8Ug5obayw7waAQfNigTETyUma+laCZR1S3tTqIsofHIv3+qpsE9lOJm1VaWrGAG33jO5830HVZBmNQrSDNmP38V1SkXZKDswqeGeacnwVrqEQn7Haehqlspg/dynCLTLrun1xPNJNVGaagWGXD/hxXZrfHITLpMtxM3XHzEsIRCCIdgUNvz43ZQL7/ADXzrfyBdL0C2A2blgq2dbdashMYaO2x+sdRvEqfsHEyISWrlGbaeCIgh9RWANkL3mSefYLGhKavWkyK9QPXue4VrTPp5ZrJ/IIFKFr8knWuh1jqG93xlLHh6TyEUHP8Qzz3XdgoEsiEsiu9IUAgrN2NVWXekqJ8Gj2RDBKgyZx1R88CSiriAQKV3SM7CapMWYXhpUdakTD8D633WYFo3VL2ufcb8GCzPo/VnwMtmKSwf4bTqPkOHt60yr7BgHi00AAQOrBJpvobW1s8f7axSdGOrtVAELI67ObadT9YE=
X-OriginatorOrg: wisc.edu
X-MS-Exchange-CrossTenant-Network-Message-Id: b9ab6afc-879f-4494-a80b-08d82dbf5563
X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jul 2020 21:45:08.3923 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: y8T0xYhTfJe4Y7PF5d7MGUNo07GGjlp0zVWwtMeFf2VfLHzQ0h4tkGJ1CGQaLgB+RkTuWbML2gU6S8I+gcbkwA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB3130
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/QJMITd5G-CjX8cUZksochRgB7kM>
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 21:45:14 -0000

On 7/21/20 6:05 AM, Douglas E. Foster wrote:
> 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..

I like this way of thinking, and it seems like a good time to mention the following anecdote for the sake of the "end-users can't make security decisions" argument...

Specifically to address BEC we strip the friendly from (at our MTA gateways prior to ingestion to O365) conditionally (one example: from domains of free email providers) to force the MUA (Outlook and everything else) to show the From address.  

It works because now the victims just see "wisc.edu.provost32@gmail.com" instead of "Office of the Provost" and are more likely to consider the message hostile, less likely to click on the weird link, less likely to buy gift cards, and so on.  

I can count on one finger how many people have noticed that we're doing it (it wasn't an end-user, but it was our CRM team who uses friendly from to soft match on contacts) for a population of 150,000 mailboxes.  Meanwhile, we get very few people claiming that we aren't somewhat mitigating BEC scams.

Note that other institutions are tagging Subjects and bodies with EXTERNAL warnings, either to all external sourced email or based on some conditional rules, but they are not directly addressing the display name spoofing itself.  I suspect that people learn to ignore those warnings over time and still fall victim to some well crafted scams from a spoofed VIP in their organization.  

I can't say with certainty which tactic works better (DKIM signature breakage is a wash), but I think forcing the MUA to reveal the sender's identity is more effective, less disruptive, and dovetails nicely with DMARC and the security marketing of the DMARC vendors.

Jesse