Re: [dmarc-ietf] ARC questions

Michael Thomas <> Thu, 26 November 2020 00:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0DDE3A0E49 for <>; Wed, 25 Nov 2020 16:52:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Status: No, score=-1.65 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, URIBL_BLOCKED=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 BDel_ml9l2X7 for <>; Wed, 25 Nov 2020 16:52:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 020193A0DE0 for <>; Wed, 25 Nov 2020 16:52:33 -0800 (PST)
Received: by with SMTP id r2so286422pls.3 for <>; Wed, 25 Nov 2020 16:52:33 -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=j5+eOemBCuD4uNdQ9bS2v2DmwQX6DGtB9IAFI/Q2xbk=; b=XaR0VL44CXcohbBoDfBsHqBt3Rn77O6k9Dt5DXAQyxpkwBLTw1HtlPQ/Fq0KGhD4Vp ceQBNi+txYvksdUJSnFrVOmS1XrFjPBMxw0SlojekHzS1POiUYyQATFGLFAGKpeNNUv4 w5MfjUOHCOj2jHVtN5VDRcUHyglYY+3mlJfK6yS87jr8Kcvh6f+c9zwr/4s23m8Zi+FH 1O1yYMp0vyjiJOj2TTC8EDlGILIqJPqHIUo3RJM1WydiP7nzpFWt1yAmWtGYrp7eSb2f wzr/WdGWgOPd6/OYaalRz5C9jOwaQ/unOK8FIwKTYvHjno1IdOdgyPdugAUZro7nOy4S Mafg==
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=j5+eOemBCuD4uNdQ9bS2v2DmwQX6DGtB9IAFI/Q2xbk=; b=Dj0km2xJ55MoPv/HvQiCoOYVUb+AOswYLlqZeGRHYIpUBcc1JQ2s2mi17fxbfY5aeG WaFcZJK+JFZ7HxUf8RIWplbZV1HOEuwGTPLB05msG38EYMPsWuw5Mo96acJIw+D7x68j hycDdhc4NSRhDRIzPxlP+Qp0xkXhKYEYftOangzhLdn8ksMXCN/AYe2w/3H7FIDRnhT9 KtYS9531vuzpFJxB7nFSjtcbo9LZE/YWzHbNgSiQGTQWX4qg/adYzt6UB5P9WPDdxdYE t3UoD04kSLpEgsCdr1eHLZjTR0HPd8n/kqVr7TTvjk6w8nxVA7RoWQEO+dwYNWqsUmgL KOxA==
X-Gm-Message-State: AOAM532hOTZItRw0vuVELDlIO87iCR+57poH8Ujl9aFbtOANzzS3/gLL u/ttdqf6IMvCkw4fEqsSXO1NXBz3UsMczA==
X-Google-Smtp-Source: ABdhPJym2buVXTiahURVz4Jmz90Hp0KzjTO2CCGcB0SfnOPdjkeIAYM2JxKSmgpHvVGjZQih1DDxHw==
X-Received: by 2002:a17:902:b90a:b029:da:655:4208 with SMTP id bf10-20020a170902b90ab02900da06554208mr555804plb.30.1606351952927; Wed, 25 Nov 2020 16:52:32 -0800 (PST)
Received: from mike-mac.lan ( []) by with ESMTPSA id y5sm4153018pjt.42.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Nov 2020 16:52:32 -0800 (PST)
To: "Murray S. Kucherawy" <>
Cc: Douglas Foster <>, IETF DMARC WG <>
References: <20201124020453.AFDC027CE5C8@ary.qy> <> <> <> <> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Wed, 25 Nov 2020 16:52:30 -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="------------AE311FBA35222659A57C80E4"
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: Thu, 26 Nov 2020 00:52:36 -0000

On 11/25/20 4:14 PM, Murray S. Kucherawy wrote:
> On Wed, Nov 25, 2020 at 11:03 AM Michael Thomas < 
> <>> wrote:
>     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.
> I'm not sure about "bad fit".  The original plan was to have an 
> Authentication-Results (AR) clone called 
> Original-Authentication-Results (OAR) which was specifically the AR 
> content generated at the first non-submission MTA. There was some 
> friction (mostly from me, as I recall) about having two header fields 
> with identical syntax and nearly identical semantics.  There was 
> further complication in the fact that one ADMD could apply multiple 
> ARs on a single message (for multiple methods, or multiple instances 
> of the same method, or a combination of those), or they could be 
> reordered, etc.  To make it more resilient, things like instance 
> numbers were added.  The work was eventually generalized to be a 
> "chain of custody" sort of model, and in doing that I think the 
> decision was made to make a new name to ensure ARC and DKIM would be 
> processed differently.

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?

>>     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 technology.
> Obviously it's too late to include this in RFC 8617, but those would 
> indeed be interesting data to have.

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.

> 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.

>     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.
> Suppose you're sending to a list that I'm on, I enforce DMARC, I trust 
> that MLM not to send spam via reputation, you have a good reputation, 
> and you publish a DMARC "reject" policy.  That means if a bad actor 
> sends a message to the list as you but doesn't sign it at all, I'll 
> still accept it because I trust that MLM even though according to your 
> policy request, I should bounce it.  ARC provides the missing data I 
> need to enforce your request.

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.


PS: it's been, what, 15 years since our interop, partner? :)