Re: [dmarc-ietf] ARC questions

Michael Thomas <> Wed, 25 November 2020 19:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BCF643A15D6 for <>; Wed, 25 Nov 2020 11:03:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V94-fA1awwa6 for <>; Wed, 25 Nov 2020 11:03:41 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 026673A15D4 for <>; Wed, 25 Nov 2020 11:03:40 -0800 (PST)
Received: by with SMTP id t18so1586520plo.0 for <>; Wed, 25 Nov 2020 11:03:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=NWFEklCqrB6b/pmPp5BLuLth9RSW5uYfNCa+1tjhh48=; b=TdNhgenGRHGDW0FpXbC3xkOF5I17vCy22j/oiVXUh02LenrXJup3muKonKdFaZ61m2 iUxflgsimNjATd7UhDWOzoHl+alNQyXcf0cp9gdzmjzKblv1x7YYRKEYshUwyqEQWRSn DnN9L1///nXBwRhawsbC/atgp/A4+ZxoLST0+rVae7Eynbwv9C5JYSceS8lqi6v9GQt9 6+jPTv9vmtnGncOBYmKpS0/1kfVuVA2Ama29KRNjaiSnK7+i81Q7Cb6oP5WyVI8mQJVH 7tP2/e8Jzu2ClWV1HbapWQWLHOwhyIp2+oZox0eQbkbK+4lEB6/yXfmU96DuUBFxJlY8 zm0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=NWFEklCqrB6b/pmPp5BLuLth9RSW5uYfNCa+1tjhh48=; b=Bu+mKJmpAEuKa4CQmNTopNCBlp8/arJANrR6BF75RCCQQyUcRqbw/WMW3S7zoRZ5jK XQH9yZVFIO3CAfreclVeOUfQ87aOihe+NxjxZZkWsK3DlMKXwGIN0MMCr4dNblsf2Aj3 +NtfgTGVF0X3FC6c7MmVfVLrlvzrDoxSRBtqb6WGEUn7Wosj8jt5CxcMWT6gVA7htOuT nNuA+g/xP9aXVSzc8oPxQz5vjBVH61fqC/2q7C5GQODhsI4aRovCGvApvolCAczRN2cr kokLx+SF0E/uF+/AQyvQC7XdDcmfj2t01e0bdcPkRUHS+Dd3Y3YrxO9+Mow7Vc9YNiUy lmgg==
X-Gm-Message-State: AOAM530QJ4+TP7VdiG6LoJXeyRrG0jzeFsbYWDmQSF4U6OgF30UDX40F 21X2f8MtWvheNoS2XfNUxX5rVuM7QJSovw==
X-Google-Smtp-Source: ABdhPJxuyxFWewU1Tmzy5RR3p17B+r5SZeuAzWfGFwQMT82rVfywLopGQ7nIthtTjjcjzU+e1goukQ==
X-Received: by 2002:a17:902:b192:b029:d7:ca4a:4ec1 with SMTP id s18-20020a170902b192b02900d7ca4a4ec1mr4181072plr.76.1606331019720; Wed, 25 Nov 2020 11:03:39 -0800 (PST)
Received: from mike-mac.lan ( []) by with ESMTPSA id y24sm2515934pfn.176.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Nov 2020 11:03:38 -0800 (PST)
To: "Murray S. Kucherawy" <>, Douglas Foster <>
References: <20201124020453.AFDC027CE5C8@ary.qy> <> <> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Wed, 25 Nov 2020 11:03:37 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------6811A00D5C25A237C051A44A"
Content-Language: en-US
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: Wed, 25 Nov 2020 19:03:43 -0000

On 11/24/20 8:19 PM, Murray S. Kucherawy wrote:
> On Tue, Nov 24, 2020 at 7:27 PM Douglas Foster 
> < 
> <>> wrote:
>     Michael, I think the purpose is stated well enough:   Mailing
>     lists want to keep adding their content to messages, without being
>     blocked by recipients.   This means that they have to provide
>     recipients with enough information for them to accept the
>     forwarded content.  Google and Microsoft seem to be on-board with
>     this project, so it seems pretty successful already.   This train
>     is not easily stopped.
> That sounds about right.  Put another way: DMARC's success is at least 
> in part stymied by what MLMs do that invalidates DKIM; ARC is an 
> attempt to carry forward from the MLM, in a credible way, an 
> indication of what the MLM saw in terms of DKIM results when the 
> message got to the MLM.  So then, although an author signature will 
> fail post-MLM, the MLM signature will pass, and the ARC data will tell 
> you that the author signature was good when the MLM got it.  If you 
> trust the chain, then that can be an alternative to the DKIM input 
> when the final recipient performs a DMARC evaluation.

That's been known for over 15 years. I'm still trying to understand the 
assertion that DKIM signatures are a "bad fit". I just looked at a 
random message off of this thread and they look identical except for the 
i= field. another field could trivially be added to DKIM and auth-res -- 
since unknown fields are supposed to be ignored -- if this binding 
property is absolutely needed, which I remain unconvinced by as well.

> Sections 1 and 7.2.1 of RFC 8617 do say all of this, though perhaps 
> not as concretely as one might like.
>     In my opinion, ARC does leave a lot of unanswered questions about
>     how you use the data that ARC provides.   Again, the big
>     organizations have the brain power at their disposal to figure
>     that out for themselves, later.
> This is why it was published as Experimental.  Its efficacy is not 
> (yet) known, nor are any side effects. Although, now that you have me 
> thinking about it: It's been a year; have we any meaningful data about 
> this yet?

If you ask me, part of the experiment should be able to show use cases 
that DKIM + auth-res (or maybe old-auth-res if needed) CANNOT address 
that ARC can, and most especially what percentage of email traffic we're 
actually talking here. As far as I can see ARC doesn't bring anything 
especially new for the mailing list kind of use cases since it really 
easy to see who the intermediary was that broke the signature. I have 
been told there are some vague other kinds of use cases but is unclear 
whether those use cases actually happen before or after the message 
arrives at the front door of the final receiving domain. Yes, i read 
section 7, but it doesn't tell me why this can't be handled with current 

It seems to me that the lynchpin is whether I trust the domain that 
broke the signature and resigned. That's either a previously solved or 
unsolved problem depending on your perspective. If I trust the 
intermediary domain to not send me spam via reputation, I forward it 
along to be delivered and ignore the DMARC record. Why do I care whether 
it originally validated from the sending domain or not? If you ask me, 
that's the intermediary domain's problem since they have an incentive to 
keep their reputation and not send spam through.