Re: [dmarc-ietf] Header Rewriting

Douglas Foster <dougfoster.emailstandards@gmail.com> Wed, 06 January 2021 12:29 UTC

Return-Path: <dougfoster.emailstandards@gmail.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 59AE73A046A for <dmarc@ietfa.amsl.com>; Wed, 6 Jan 2021 04:29:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 hBIJZhJ9zYXB for <dmarc@ietfa.amsl.com>; Wed, 6 Jan 2021 04:29:56 -0800 (PST)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 A23113A045E for <dmarc@ietf.org>; Wed, 6 Jan 2021 04:29:56 -0800 (PST)
Received: by mail-vs1-xe32.google.com with SMTP id z16so1674043vsp.5 for <dmarc@ietf.org>; Wed, 06 Jan 2021 04:29:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gHaSMAwWOVaZyywPIdDy2wX4iv5qGOPS9UlwUqG4oMs=; b=SfyQ+YHqLIzgil58sfAB0/K2mOdI9KNZQBRDd1HaIoxsD7TQSQO2UnAcrp6eW8M6Ua BTbg2fOHY+iJXkVBATSrSclXPyVGhhJzXNHemqMHgTiFHdySErPTWbfKyxjnfjwjL4dW KqqMVbuf9Ld2N2YFXO1pCnaVhA0boTtWs2OiGIycFFpRsFNqPf62FLo3gE3sxc0/yvVG IzZCljk1SIzLo2MZBAkFs0X+jZ5VZEfWEFBJGrmCSJV7PYVGYtd7jBSk5j+6anaIrcZI YbA8CD25+wwSTcxOVPEada2ZDGO0gDlYiivZMYWNZ/Bu7hhZux7CS2xunODtYY0ja3Dh 8aEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gHaSMAwWOVaZyywPIdDy2wX4iv5qGOPS9UlwUqG4oMs=; b=U/WzvrucIVnMonmhdu2i58Q3BRzV72ZDU+yUJtt9Du+KTvx4v9wgmcBmx4qu3JwtuE L3Dx32tS1c3A+Q2zus+ck47nGQDnJyrqb5Q5RZ0X2G+90UdP6oICDFI+z42vK47Rj6Uk LaBtxW3MgSPx/sTBkPWCUrrFSEmIvC0WPUNPJVjx0teCMqGwNYcTkUUO2CBEWKMYsW/Z jT6/gGokx+lZ5aHJA1R+WczLeDtCMfUhi4tMqVIq6QFr7/KwWDtTjNcUbYhOb2WXvR+o efePD2bhruJkifTbYxvMPULgGQb++ZzaFBi908EPIj0qiiJafYhUqRbr10Dm/RrUsw1I 4q0g==
X-Gm-Message-State: AOAM530fjal7Bv8IRb+HHoHyGG+rHqGsj1PDduK0FSKRPWJyelKlaTY1 NRKX1oBcbNnBxLDYW5RbJyCoEtfjmXcbdfaFteE=
X-Google-Smtp-Source: ABdhPJyO0gzCF37VgYzSqKvajXpZK7ZghpwAO6xwy0YF95e2FNqhG9kqDkYMkI6d7pBMpTIheUaq+L2Cw6rtqwtiPBQ=
X-Received: by 2002:a67:c983:: with SMTP id y3mr2678616vsk.59.1609936195444; Wed, 06 Jan 2021 04:29:55 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <ECBF25D9-F05C-4DE9-AD97-6D4D01B01B57@wordtothewise.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Wed, 06 Jan 2021 07:29:44 -0500
Message-ID: <CAH48ZfyTUNg2_PnHFHEtZFemfvBgWBMpGLphGTL=3mRvD9o==w@mail.gmail.com>
To: Laura Atkins <laura@wordtothewise.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000a62bc05b83a7b2b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/iuFZTkkqEMANdbM8i-ze2OM3njQ>
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:29:58 -0000

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.

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.

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,

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.

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.

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.

Doug Foster


>
>