Re: [dmarc-ietf] ARC questions

Michael Thomas <> Wed, 25 November 2020 01:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CAA413A03EC for <>; Tue, 24 Nov 2020 17:27: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 1l0f_H-_o87l for <>; Tue, 24 Nov 2020 17:27:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED9C83A03F1 for <>; Tue, 24 Nov 2020 17:27:33 -0800 (PST)
Received: by with SMTP id w187so790434pfd.5 for <>; Tue, 24 Nov 2020 17:27: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=Z5pYGJnOa5E+sGRt3i61k4TCYsbN+a4LM0bPH1nGqNU=; b=ogsckW8fv/BFAixfp76l9Rj/82YXQtDjf06/dewriR5LwARUOvbMxf1fRSUZW2J610 nyPhQXRB0w4xN/cvAke4eGD6Uq7ur6kUzrgJCBuX7mJ7M5HdLkvd9macW0v8oT50lGAg +SuepNP2gkbECib9bDasZ/jlGeQhnqQtwei3DW7uDoi07WVysC5XuajakY+l8Ou+fKcV sttgVrsXbJZGBs1Z/CCZAtpFi906PVe3XuzU63bc+5IWekFeoicUlRZ5hMvAT2WgGaKr NUG/FwjK/dQtfIvJT2mg9a3bHe3vttNb77sCWcugCnC/QTMh0YIt60rVqO2BSLRoghvy /T6g==
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=Z5pYGJnOa5E+sGRt3i61k4TCYsbN+a4LM0bPH1nGqNU=; b=b2sV4p8cXgrewXf92ISFlZvYCpnMOO//pkfBPn2jt+Hth3bJuaWs3woQ4FvOARvB9q qdzYOQSpsrld7ZKHmFq9tCJUaDfD+/vBkhO8svSfBGX6Gbz+B6N/oSsLGuz39tdD4Gv1 ZPjbCcgYaGyFCuw+hrcrWmmr4ggRC9aWzimvbcIOB8KeIJEWt12nk4GqYmR7t8WXUsYx sul5PSYxV1H7N6jaOHKEBeMBb//V2MoLzJeZViJC4GjWwGDZttR1CDwNPYvsYudDbZLV O9v8aOz7JdMgMkcN+5Z1N+u8En42NeTj5ZtUdNJC8VKPn7QFsxjiYXVxzeNc5ZTZwGE4 mW7w==
X-Gm-Message-State: AOAM533ndt3GCZTWXiLT1DbDqTTFU9HABbIeF9s7dN/aSzqIxHOfVBWf CXMJJM1KRyEbQs979l0/cmNYgPYj2bt/yQ==
X-Google-Smtp-Source: ABdhPJzJaygIIFFRXkWbWirePk7LlCNIDqkmgDbDb/MmjV4sj4quV6tFULQiWB9s2EiC9VJUDHkrIQ==
X-Received: by 2002:a63:3d8c:: with SMTP id k134mr1019710pga.53.1606267652841; Tue, 24 Nov 2020 17:27:32 -0800 (PST)
Received: from mike-mac.lan ( []) by with ESMTPSA id na6sm437304pjb.12.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Nov 2020 17:27:32 -0800 (PST)
To: Brandon Long <>
Cc: John Levine <>, IETF DMARC WG <>
References: <20201124020453.AFDC027CE5C8@ary.qy> <> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Tue, 24 Nov 2020 17:27: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="------------B4B77474E010D665715C24D7"
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 01:27:36 -0000

On 11/24/20 4:56 PM, Brandon Long wrote:
> On Tue, Nov 24, 2020 at 3:57 PM Michael Thomas < 
> <>> wrote:
>>     Our experience also showed that more than one hop is quite common
>>     in enterprise deployments,
>>     and those are also the places where the most complexity arises. 
>>     Others shared our experience
>>     as well.
>     That's more than one modifying intermediary in *separate*
>     administrative domains? Within your own administrative domain
>     there shouldn't be an issue of trust since you can trust your own
>     servers auth-res and that they are not maliciously trying to forge
>     an auth-res for better treatment. and course it's best to stop a
>     bad message as soon as possible in the mail pipeline if for no
>     other reason than why waste the resources.
> The administrative domain in practice tends to be per-vendor and 
> multi-tenant.  Ie, gsuite/gmail is on <>, 
> various third party anti-spam gateways also different, on-premise 
> being also separate.  Passing that trust between domains is one of the 
> things that ARC can handle.

One of the failings of many, many ietf documents is to not tell the 
story of what exactly the problem is and why the protocol is needed. 
It's really frustrating to the reader to not have the context of endless 
wg list discussions distilled so that an outsider can understand the 
design tradeoffs. I still don't understand why a DKIM signature was a 
"poor choice". That's especially true when something is an experiment 
that assumedly has yes/no endpoint.

So is now hosted by gsuite (::sigh::), so you're saying that it 
would run into problems? I haven't put up a DMARC policy, but if I did I 
might run into issues with false positives? Like I said, I'm trying to 
get my head around what the actual problems are, and this is coming from 
a person who stressed mightily from the very beginning about the mailing 
list problem.

>     Well sure, I'm sure it can happen but is it common enough to worry
>     about? And I'm still not convinced that figuring out who signed
>     what and which auth-res it belonged to is in insurmountable
>     problem. for one, there are received headers which better not be
>     getting out of order to help correlate with the messages' path
>     through intermediary verifiers too.
> So, we do have some Received header walking code, and allow admins to 
> set up the list of IPs that are considered "internal" (beyond private 
> addresses)... but O365 uses public IPs internally and
> has a huge and unpublished ranges of them, making it nearly impossible 
> for admins to maintain a list.  Obviously we can all add code to 
> handle Microsoft specially... and whichever other ones come up.

But can't you trust the received headers once you have possession of the 
message within your domain? I'm sorry if I'm being dense here but 
received headers are definitely ordered and if you loan out a message to 
be processed by a different domain and they aren't trustworthy, that's 
the least of your problems. That's part of the overall problem though: 
it's really hard to understand what the problem here actually is. 
Explain it like I'm five :)