Re: [dmarc-ietf] ARC questions

"Murray S. Kucherawy" <> Thu, 26 November 2020 09:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E35D3A0FFD for <>; Thu, 26 Nov 2020 01:56:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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, 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 12SrTGfDAY_r for <>; Thu, 26 Nov 2020 01:56:44 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB5C13A0FFA for <>; Thu, 26 Nov 2020 01:56:44 -0800 (PST)
Received: by with SMTP id b190so347155vka.0 for <>; Thu, 26 Nov 2020 01:56:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3IHNin2SqjRcKVYR5kjZam/+TtdMzP8N5/rtgMPpE+Q=; b=otE8lpaMlJqBoqxe2MbJZnw4SuiEfH2t4Tb2k9TidJJ8CY8mSSvAGTEbBypZxhP09C pVR+sRJCcyE+jdDWdSi8ADCS7OvepsVtzxVqBNmENLzWEsxEwWLJfIyuAe5jEyphplIr NVgW4NuNNiJc81Y90AAl1r7UXrN6+InqiC4ls3lT1WGs0ZcSUkJ9tPMzafN9qx+wgmeW KdmfKVlgBb3MKoVKYscHFn+e1qzib1mq7iy76NsHgvGcY6mu+28yM1XPGRHpfY+3F2M3 bL/w43y4rbBwt7nrr909zeoQSPqylRgXNQLVRHVK5VpTjZRqUfZYQB+0P9o163EQOrZ6 mzbA==
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=3IHNin2SqjRcKVYR5kjZam/+TtdMzP8N5/rtgMPpE+Q=; b=S34FgKiL0ZUWbfQQfbqNglNT3qkuX+ui6iga64a7Ft2Nca0s0MzYU/n74I1Y7ddxFa rsrSINe4MsPzQVmvyVWr3mNDeIOO9uu4lV0/p9oEASxV6GoGF15fP1O5qVV1RUGXrO1y j0Jr28o++VBuiMb9K7R+HKGBIyLUrlEYhqgQvQYiztEmzVpU7w0zXz98HB9uwuUXPgnM kQmIFC5JLuMc1y4D6a0ll0zIRJ/pvmQcce79QbSIBoZKHrbKrLRM8MtHUCa9go3IwtzK pqBShV8zhWEwkWLwtYVm2B1XbcflousySa8r5+pDOQb+mcVbDmCY+qJrDuONX7BnqntQ D6iQ==
X-Gm-Message-State: AOAM530iLK/IsCqufkKwIqV0TCYX4PrQ3s7lqiwIC4k8use6tKiM6ZTu mXjl8jqXJaKNN1prvaxTt7yFSHkosOeyGU8IgesV49S1
X-Google-Smtp-Source: ABdhPJycQ0lGo6sQTjur+CcvsXk+E/pkhaFNMHtXAVu6oaVHnR8aYCYeAgNB/Y8L/Sac9NurczVXtpPAoL/gamnXWpQ=
X-Received: by 2002:a1f:d907:: with SMTP id q7mr1153876vkg.14.1606384603693; Thu, 26 Nov 2020 01:56:43 -0800 (PST)
MIME-Version: 1.0
References: <20201124020453.AFDC027CE5C8@ary.qy> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Thu, 26 Nov 2020 01:56:32 -0800
Message-ID: <>
To: Michael Thomas <>
Content-Type: multipart/alternative; boundary="000000000000ad052105b4ff8f15"
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: Thu, 26 Nov 2020 09:56:47 -0000

On Wed, Nov 25, 2020 at 4:52 PM Michael Thomas <> wrote:

> But what about DKIM? And why do they need to be processed differently?
> When I first saw this, I looked at the ARC-Signature which looks identical
> to a DKIM signature (i didn't notice the i= at the time), and am like what
> is this? The i= counter could be trivially be grafted onto DKIM if it were
> needed, which I'm still sort of dubious (though it is a nice to have
> feature, I admit). That way you only need a single DKIM signature with the
> OAR's signed. As far as I can tell, that would fall back gracefully for
> non-implementing DKIM verifiers. Do you disagree?

ARC was developed over months, even before this WG started, and I remember
all of these conversations happening involving the questions you're now
asking.  We landed at what became ARC.  I suppose an appendix might've been
nice enumerating everything that was considered and discarded, but that
record doesn't really exist.

What that means is that I couldn't tell you now why we rejected a pure
DKIM/OAR solution to this specific problem, but I know it was considered.
Maybe others who helped with RFC 8617 remember.

> Yeah, quantifying the problems kinda seems like the first order of
> business if you ask me. I mean, how many of these scenarios are in reality
> goofy self-inflicted wounds? I can't say but there seems to be a lot more
> "this can happen" than "this is how often this happens" from what I've see
> thus far on this thread.

Where do you suggest we go from here?

> When you say "easy to see", do you mean for software or for humans?
> Software. Only software can pry apart that ball of header spaghetti. But I
> think with the simple a mailing list it is pretty easy to determine, which
> now that I think about it I actually did back in the day when I was
> experimenting with recovering mailing list modifications. It didn't occur
> to me that that was supposed to be hard.
I haven't put hand to coding keyboard on this problem yet, but I'm trying
to imagine how it would be easy to determine (a) that Subject had been
modified (for example), (b) what the specific modification was, and (c)
which hop did it.  You could say a message failing to validate an author
signature with "[...]" at the front of Subject was likely tagged by an MLM,
or that everything after "--" should be ignored, or that those probably
happened at non-submission hop #1, but those are heuristics, and I think
we're hoping for something more deterministic.  The 80/20 rule isn't

But it's late and maybe I'm missing something.  What did you have in mind?

> Sure, but the easier answer: to use my mailing list, you must have either
> DKIM, SPF or both. Sounds like a good way to not be essentially an open
> relay. Don't mailing lists have those sorts of policies these days? I would
> say that ones that don't probably shouldn't have good reputations since
> they are, in effect... open relays.

That requires MLMs to change their behavior, which I believe is something
all of these protocols are hoping to avoid (or, at least, MLMs should
decide that on their own, not because the IETF forced them to by wielding
DMARC and ARC at them).

> Mike
> PS: it's been, what, 15 years since our interop, partner? :)
2007.  Still got the t-shirt.