Re: [dmarc-ietf] Header Rewriting

Laura Atkins <laura@wordtothewise.com> Wed, 06 January 2021 12:52 UTC

Return-Path: <laura@wordtothewise.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 0B25B3A0813 for <dmarc@ietfa.amsl.com>; Wed, 6 Jan 2021 04:52:40 -0800 (PST)
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=wordtothewise.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 bJ7pcN44Z5rc for <dmarc@ietfa.amsl.com>; Wed, 6 Jan 2021 04:52:37 -0800 (PST)
Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id DC5E93A0809 for <dmarc@ietf.org>; Wed, 6 Jan 2021 04:52:37 -0800 (PST)
Received: from [192.168.0.227] (unknown [37.228.231.27]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 6818E9F149 for <dmarc@ietf.org>; Wed, 6 Jan 2021 04:52:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1609937557; bh=pMupoUh4HPYFa0p9yMvFoHtJBdorhwmU0q/LhCNaqiw=; h=From:Subject:Date:References:To:In-Reply-To:From; b=f1j7xTLzKtkMITVCFO5d41Y4+uvknY53Njvc1bB4ppl5RCFDuDPsmhcAuhhOXvtbM vVCqZHn7MCoiW5EE8Yi2PvEbcwsWL4LwqYRItDtEC3tJgB+uz8mXEBRz+OpX8FWF6S 1Ltsrvnmu3/30ohRrxD03a0L5npIrt7d1LmmiVYI=
From: Laura Atkins <laura@wordtothewise.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A1B901DB-9765-4648-8D65-7DC05D705008"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 06 Jan 2021 12:52:33 +0000
References: <20210104174623.2545154CFF9F@ary.qy> <FD45F9FC-46B0-40A9-ADC6-DDD7650D62F2@bluepopcorn.net> <ae77d9f-6f63-16ca-903a-7cb463a7b58d@taugh.com> <CABuGu1o2t7WaEOh+nsx3_MRUGgGHqKHzQ9302FM9-HL0GxvJvA@mail.gmail.com> <f15c8f53-8075-99a1-83c7-f687200e6a94@gmail.com> <f640ee95-ba0a-6aa7-1a14-2af1db151e27@mtcc.com> <050e8614-c088-a165-a733-35c5eee52eed@gmail.com> <ECBF25D9-F05C-4DE9-AD97-6D4D01B01B57@wordtothewise.com> <CAH48ZfyTUNg2_PnHFHEtZFemfvBgWBMpGLphGTL=3mRvD9o==w@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
In-Reply-To: <CAH48ZfyTUNg2_PnHFHEtZFemfvBgWBMpGLphGTL=3mRvD9o==w@mail.gmail.com>
Message-Id: <D3A51087-6E1A-465F-89CD-63172E8075D4@wordtothewise.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/11pUrppM-XHee8HSkBbLxwrET1g>
Subject: Re: [dmarc-ietf] Header Rewriting
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: Wed, 06 Jan 2021 12:52:40 -0000


> On 6 Jan 2021, at 12:29, Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:
> 
> I am no fan of header rewrite, but...
> 
> If you are going to talk about "Trust Indicators", we need to define terms, which has not been done.   Here are my definitions:
> - The From header is an Identity Assertion.
> - DMARC is an Identity Verification technique.
> - A text message saying, "This message verified by DMARC", is a Trust Indicator.
> My definitions are consistent with the way that that one study used a trust indicator.   Using these definitions, From rewrite has nothing to do with Trust Indicator research.  If anyone wants to assert different definitions, please get them on the table.
> 
> The fact that users complain about From rewrite is proof that they look at the information.    This is because it is an Identity Assertion, not a Trust Indicator.

The header rewriting being proposed - that is header rewriting by the ESP so that the messages that go through their system are rewritten to point to the ESP and not the author of the message - means that the identity assertion is disconnected from the context of a message.

Want to know what mail goes through ESPs? Bank mail, social media mail, marketing mail. Billions of emails a day go through ESPs that you have and have not heard of. 

The proposal at issue is that these ESPs be allowed to rewrite the From  address any message they handle to point to an email address they control. This disconnects the identity in the 5322.from address from the actual sender of the message. 

Most users may know who constantcontact are or mailchimp because they advertise widely. Some might have heard of GoDaddy but do you know what the company name of the GoDaddy ESP is? I don’t off the top of my head. 

> I accept that actual Trust Indicators have a small effect, but rounding down  to zero seems like an overstatement.   When fighting malware, I will take all the help that I can get, even small help.

And now we have a malware company that rewrites headers to point to a domain they own and it passes DMARC and is given a Trust Indicator. Recipients are used to seeing domains they don’t know or understand send trusted mail from their bank, or their girl scout troop, or their social media company. They have no reason to distrust the unfamiliar identity assertion in the from address. 

> Lots of organizations use trust indicators and lots of organizations use DMARC for validating the From address.  Message annotation has gone up exactly because many MUAs are making the From address visible only on request.   Common tag lines are now of the form:  "This message is from an external source, so be careful."   I don't see that it is our job to tell domain owners that they are wrong,

This has nothing to do with header rewriting at all, which is the topic at hand. 

> Domain administrators are within their rights to block any incoming message for any reason.   Users routinely work with their domain administrators to ensure that the messages that they want get accepted and messages that they do not want get blocked.    If users and domain administrators cannot solve their differences, the user can communicate using a different domain.  If DMARC produces false positives that cannot be resolved by this process, we would do well to ask why.

Header rewriting doesn’t solve false positives, it increases the chances of them. Header rewriting for commercial messages by ESPs means that folks attempting to masquerade as a legitimate company have a RFC recommended way to evade DMARC and pretend to be the company they’re attacking. 

This isn’t random speculation, this is what is going to happen. We've spent the last 20 years watching spammers and phishers do everything they can to get mail out. If the DMARC RFC says ‘ESPs should rewrite headers to avoid DMARC policies on mail going through the ESP’ then we’ve just made DMARC utterly worthless. We’ve also set up every company that is currently using DMARC p=reject to be attacked in ways they cannot tract. 

> I see no relevance between the EV experience and DMARC.   EV is an identity verification technique, but it lacked a policy mechanism.   As a website user, I have no way of knowing whether a particular website MUST have an EV certificate or not.   If such a policy mechanism existed, it would have been automated and the site would be blocked.   DMARC has a policy mechanism, and it has been automated, so messages are blocked.

The whole point here is that header rewriting evades the policy mechanism of DMARC so that messages aren’t blocked.

> Forwarding hides information that the email filter needs to make a correct decision.   Header rewrite hides the problem, but does not solve it.   When we get the automation right, predicting user behavior will not be necessary.

You’re going to need to provide evidence this is the case.

laura

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
laura@wordtothewise.com
(650) 437-0741		

Email Delivery Blog: https://wordtothewise.com/blog