Re: [dmarc-ietf] ARC questions

Todd Herr <> Mon, 23 November 2020 15:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDFA53A07A0 for <>; Mon, 23 Nov 2020 07:39:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id igY8iuXtNRjv for <>; Mon, 23 Nov 2020 07:39:05 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9DE233A0779 for <>; Mon, 23 Nov 2020 07:39:05 -0800 (PST)
Received: by with SMTP id ec16so9003135qvb.0 for <>; Mon, 23 Nov 2020 07:39:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dxyl3bEq3wDGRejOn2DrhVkxE6WfWGAaLflq1KjBEMc=; b=CQVIKZH/fVtH/dSDgCm9hxpjGFmuFLCVEyPAJPDRrimHMfGDNG1SSIwEdVuq0EMQkx 9cbWQmmix8tq1/WKydt0HK7+vDXPUVGY8V0wtXrJn5DaHNo91+AI8UzjDoT+FNGVMckb 18NCMhou1dYSKvPvMiR5hNBTuH/7kmdnMD7t4m9WKmN7iKO8+GgAH9ajAosrXyzAOniZ nJ/MmERPPreMnUxo1txkDCJH+cPI5tXXpiNFJ77vF3K+/XpinVdVcRjHFu11tORa4KNQ bN3Wig2UTvBya6TrziM/dm93ZCpgNcLFtHh/QF+Q2+qnyeN6Vy+hovCWtmOkOdv6z9dp 1nXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Dxyl3bEq3wDGRejOn2DrhVkxE6WfWGAaLflq1KjBEMc=; b=TsHYGLdm0v7YhugiZBWpOBWab31A18gcXHD1hh5UZR/inarpXEJ9/Y3iJU+YD2PZTd BgZRsqZ8Rjvn7WBCWqi2/wyZWczBZ2vMf9PoH+Gr3boy7MUQECBFd102awXgmpxKOOAs LCfbPDYpGmXUDHMNlAjHi0oQf9JpFYPX9fVeK2EUE+DCJ/H4AiCITA1d5xznvjMZBajn NhTfCRkg0J2Cx8nqzky68NowPlDDJm+peoDgi8nMEnE2U8fUiu+1ahGQC4YYUzJkbE1T sOWJ9VhTl6rSyHJ4iFpZwf2Zo5FxdJrxigRJxg/NikKU+a7ioHx+c7wmYryB28VXDN72 DK3w==
X-Gm-Message-State: AOAM531FDUDBzWmG8iphV6N0e4JrkRFEnDD9AICBaoHmjk+t+tHtDiDW 0Vfkf0d85Y/F1YPWum5eJ4c1QSaNWjPmbE9TBaWVWA==
X-Google-Smtp-Source: ABdhPJyT4PFv5ipgRxAWQgrMQrvxY7zPH1/SwSeOJFuPR8g37IIMlQqRJGu76QXvKhj63/e00bC4ZI0iCNfG/9TAOW4=
X-Received: by 2002:a0c:db11:: with SMTP id d17mr29880471qvk.39.1606145944575; Mon, 23 Nov 2020 07:39:04 -0800 (PST)
MIME-Version: 1.0
References: <> <20201122021417.B5E6E27B3E59@ary.qy> <> <>
In-Reply-To: <>
From: Todd Herr <>
Date: Mon, 23 Nov 2020 10:38:48 -0500
Message-ID: <>
To: Joseph Brennan <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000007bf99505b4c7fecd"
Archived-At: <>
Subject: Re: [dmarc-ietf] ARC questions
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Nov 2020 15:39:08 -0000

On Mon, Nov 23, 2020 at 9:50 AM Joseph Brennan <> wrote:

>> On Sat, Nov 21, 2020 at 7:14 PM John Levine <> wrote:
>> This also means that ARC isn't useful if you don't have a reputation
>>> system to tell you where the lists and other forwarders that might add
>>> legit ARC signatures are.
> And if you know which hosts are legit mailing lists or forwarders, you
> already know what ARC would tell you.
I believe, though, that the intent of ARC is that it be scalable in ways
that manual enumeration of known legit mailing lists and forwarders is not.

Standard authentication protocols (SPF, DKIM, DMARC) are fine for direct
mail flow. When the message arrives at its destination, the receiver can
check authentication protocols and apply handling rules for a message based
on its past history with the authenticated identities associated with that

For indirect mail flows, messages might not pass such checks at their final
destination, but it's possible that they did pass those checks on an
intermediate hop. As Michael said in his original post,  ARC 'allows
intermediaries to say "this is
what it looked like to me at this point [and before i messed it]".'

The question with ARC then becomes, does the final destination trust the
results reported in the ARC header set(s), and it's kind of a complicated
question. If I as the final destination trust the ARC header set(s), I'm
saying that I believe the reported results with no real way to
independently verify the results, meaning that I can't do direct DKIM
validation or SPF checking using standard tools; if I could, there'd be no
need for ARC.

I suppose that an approach to building up an ARC reputation might be one
where over time a receiving site can compare indirect mail flow that is
purported to have X as an authenticated identifier with mail that comes
direct to the receiving site with X as an authenticated identifier. That
is, if direct mail with X as an authenticated identifier generally hits Y
on my internal reputation scale, does indirect mail that is ARC-signed by Z
to have X as an authenticated identifier also generally hit Y on my
internal reputation scale? If so, great; I can trust Z as an ARC signer.

The devil is in the details, though. If mail through Z doesn't generally
hit Y, then what explains the variance? If it's for most or all values of
X, then it's probably because Z is a bad actor. If it's hitting Y for most
values of X but not for all, is it because those particular mail streams
are ones that are still legitimate from an authentication perspective, but
aren't of the same quality due to reasons, or is Z engaging in some
elaborate scheme using valid mail as legit shields to get its nasty payload
through in the noise? If variances can be dealt with in a way that doesn't
require too much manual intervention, then perhaps there's hope here. Even
at that, such a system would need to be bootstrapped with some list of
manually enumerated known good intermediaries, but over time it could
theoretically grow organically based on data collected.

I don't believe the above challenges are insurmountable (says the guy who
hasn't had operational responsibility for a mail system in over a decade)
but I'm not in a position to assign the necessary resources to solve this
problem at each site that has an interest in doing so.


*Todd Herr* | Sr. Technical Program Manager
*p:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.