[dmarc-ietf] DMARC and ARC

Douglas Foster <dougfoster.emailstandards@gmail.com> Sat, 05 December 2020 03:58 UTC

Return-Path: <dougfoster.emailstandards@gmail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7DA683A0962 for <dmarc@ietfa.amsl.com>; Fri, 4 Dec 2020 19:58:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id TfyBzj7rYBRW for <dmarc@ietfa.amsl.com>; Fri, 4 Dec 2020 19:58:41 -0800 (PST)
Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 B91683A095F for <dmarc@ietf.org>; Fri, 4 Dec 2020 19:58:41 -0800 (PST)
Received: by mail-vk1-xa33.google.com with SMTP id v185so1769888vkf.8 for <dmarc@ietf.org>; Fri, 04 Dec 2020 19:58:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=965ONkz/m8iGzCXrj4yfegq/N+72AkAX92ukM8F/sfo=; b=M2ngiWnn03CehFyOER5By9d+ZPdEIIx/wjMhNTNplJC9w96ZySYhcv3bbVo1LHMaNc FvbUxjuQTGVcBce+OjRQmYWxNuqNY8q1cPUhibqgAtur2byrRFJo3MQfZNoXMwkcorc9 SrbcT9GzErlcvOkXw9yfwYZQ4Yg9dLpr85TUj80So34AhFrI8utB+g9T6QH3S9tayTQ1 kOOutLbtQ1Aa7QT8G7PiH5bZUb5iPYLQgyUQ2Je1gZBI57S2FwxIWR8y85piLVavKSrx O0PUM1nWNrsZPgsvkIudZdzysQmz0NquidUnCVVOAUiyK97IOY6g/o3RHI90VJKkzmGa qAEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=965ONkz/m8iGzCXrj4yfegq/N+72AkAX92ukM8F/sfo=; b=CqJ+NiNR5h8hsqm0+r07PhGyS/Hl79Oe3hOOESm2gZ0CuUhVOW5erpzgvHtrlWVBIF R9x++lde4z7SRQbT1pgP/AG5SUgRmLBt7XyFTNSVh62jDvy0oJgJpH+GGfThfgyN7VOI P3oLpEnWBs/a4OpQNbuIpC98T2tyWT0SoFQdaWNXvag0EooWOESd+CT43owRJrFt5b3Y ebPYzOLKSQbYPDyfr/Cb/hlhHnUFM/5SdrMKKlROl1kplm32JBpav9g7l6MFS5/WZk2l 3SEjt3sLl+mL3AWRJTdPweq+OKm3qy69DzFdQlLfpC5IrIXR1/bf++rLnDDBDFLFTy7j p5Og==
X-Gm-Message-State: AOAM531bO/M2oK0Nv2KT6OJ26KCEKtcoAzG4rTFWGOzDvfH9e65njHdu SGmAtOuxwVwUadtNbh9774hV4pm/pNbmHye+Eu8h/upiyJE=
X-Google-Smtp-Source: ABdhPJxGb74atHFBG/+aCiKoJg5JY3XVLu1peSqM+tjVj4Ks0+ENBNC2ZOt1grt46dKeTCAL1snhdawbGPOzaohHHVk=
X-Received: by 2002:a1f:9f04:: with SMTP id i4mr7486366vke.7.1607140720522; Fri, 04 Dec 2020 19:58:40 -0800 (PST)
MIME-Version: 1.0
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Fri, 4 Dec 2020 22:58:30 -0500
Message-ID: <CAH48Zfx1gL-rnqWWaJODi72Sgp6F70Bm_kAYL5rwSmVmopQ9qg@mail.gmail.com>
To: dmarc@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c03c6805b5af9b59"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/1BC7qQoZ21wAyvu0GkWq4pEapHI>
Subject: [dmarc-ietf] DMARC and ARC
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: Sat, 05 Dec 2020 03:58:44 -0000

Michael Thomas has asked some questions which have stimulated my thinking
about how to describe the big-picture questions here.

I suggest that too much attention has been focused on solving the “mailing
list” problem, and too little on the “message receiver” problem.
Forwarded email creates big problems for message receivers.

First, lets begin with the obvious:   malicious messages come from
enterprises that are in the malicious message business.   They rarely send
just one message, and their content changes continually.   Therefore, my
priority is to block malicious sources.   Messages that are correctly
blocked on content, rather than source, are the canary-in-the-mine which
warns me that my sender blocks need to be tightened.

I currently use 5 identifiers to apply a reputation, and therefore a
disposition, to a message source:    Source IP, HELO name, ReverseDNS name,
SMTP Address, and From Address.   These identifiers are combined with the
available verification methods:   Forward-confirming the two DNS names to
the source IP, SPF PASS, and DMARC-compliant.    On any specific message,
some of this information is not required to assign a reputation and
disposition, but across a day’s messages, each of these identifiers and
attributes are needed at some point.

If a message is not forwarded, every organization involved in its delivery
is assumed to have a relationship to the sender and therefore a shared
responsibility for the final product.   DMARC, SPF, and many spam filters
assume that the adjacent MTA is the only source that needs to be evaluated.

Forwarding introduces an intermediary organization which presumably
operates on behalf of the recipient, rather than the sender.   It is not
involved in the creation of the message and has no economic relationship
with most of the message sources.   More importantly, because it will be
forwarding messages from sources with a variety of reputations, the
forwarder will be perceived as having a very unreliable reputation –
sending both very much unwanted content and very much wanted content from
the same or overlapping identifiers.   SPF and DMARC force the forwarder to
reliably identify itself, but in this process, they force the forwarder to
hide information that the receiving MTA needs for proper message
filtering.  This aggravates any effort to filter based on original-source

Consequently, both the recipient MTA and the forwarding MTA need for the
recipient MTA to evaluate a message based on the true source, the entity
(or entities) prior to the forwarder.   Unfortunately, we have no reliable
way to know if a message has been forwarded, although some guessing
strategies are available.   Even when forwarding is presumed,
reconstructing the 5-identifier / 4 verification dataset is nearly
impossible due to data loss.

Any attempt to evaluate prior sources requires evaluating the entire
Received chain, and the supporting data, including ARC, which goes with it.
ARC begins to give us a way to trust parts of the Received chain, and this
moves us toward the possibility of evaluating the Received chain
effectively.   But it does not meet my needs, because it does not ensure
that I can use any specific ARC Set to reconstruct the 5 identifier / 4
verifications dataset needed to evaluate the source correctly.

Additionally, evaluating the Received chain is a huge increase in
complexity, for both the code to implement an algorithm and the run-time
processing needed to execute the algorithm.    Processing power and coding
sophistication keeps getting better, so perhaps the main problem is getting
the data set right.