Re: [dmarc-ietf] ARC questions

Michael Thomas <mike@mtcc.com> Tue, 24 November 2020 22:57 UTC

Return-Path: <mike@fresheez.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDC73A07DB for <dmarc@ietfa.amsl.com>; Tue, 24 Nov 2020 14:57:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Level:
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, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPpzTZO9G0HT for <dmarc@ietfa.amsl.com>; Tue, 24 Nov 2020 14:57:45 -0800 (PST)
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E81F3A07D3 for <dmarc@ietf.org>; Tue, 24 Nov 2020 14:57:45 -0800 (PST)
Received: by mail-pf1-x42e.google.com with SMTP id q10so512381pfn.0 for <dmarc@ietf.org>; Tue, 24 Nov 2020 14:57:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=dChT9mInGD32S8kkDlaGO/jlD0cO5koPuFgkfXxgYrc=; b=cmWnkQmB9ZxENXVrjc/3pxEDCW5qF+l+GFymSHSnVxdyotbX9pIlmqGSxXKMYUVgVj 7ZBAHrFpN2m5fYBGUkvVSrVsDeiqr986h2+FG2X7bdGJvCWZbDJGJ0AL9ck84ISAX63K HyZfAN7fouxNShTBhM8+5LmUIkJxdcx7ljqI9IOI8+H5prZfemzl6FUROJTS/OcXGdM0 j10YW64bE8KFQH2NzZy44E7kX/fcSdW73XsgBJKjr2M/3JxibqqDy9+rHKIGmGK8LP8K ZFy6t0bD4NxmlpZv9cBpsjv9Nz1BWpaiyWTD3PYXIu1oLYlaW6+f5fu456+gYPYXPLK6 eCtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=dChT9mInGD32S8kkDlaGO/jlD0cO5koPuFgkfXxgYrc=; b=Fk9hM6rjfdireFkSHZaewXlyZF0OTbUHwKuiz7Pgbiwjy8vHyF9M87iDdWb8PdVNhm YGO04v/dRrDRFea2TYtnSFkZ0zgok76/3e3B6WIdq4O2kHPkyOr0Ns2WJRdmqd+G5HIO P4WeLWbyGOznNI+dx1fkgVSqQq8xUQOe9GWF/iA3KrADRhYBVa5QczTYHuv0o6Jr+mVG WiZLTxoToWbx8jl6ky7K6u+yc8y3roPCDnV9oNAmerdb/6p++ANewhOnJqFQu0tD559x FTPtPKgHUyyyl0RhnM8awbBwZ+6B3QVBrA12P6fz5loF0UEqDsItTQqVNexZimQ5vk4Z ewdQ==
X-Gm-Message-State: AOAM531qZ9lV5JKLaNAFRNrBd8iXLqV9/7yf9PdZZJFwIMtILwoP/mJN 26uSSF8LG8wee+rh22vO5f7XaZoYFOxtVQ==
X-Google-Smtp-Source: ABdhPJzb+fDwkivT7oP27nKB1tvyrTuuAExCvrT/JCreMerwTB6XQ5Whg5PGDL3iG10ciLX7wfKqbA==
X-Received: by 2002:a63:1346:: with SMTP id 6mr556048pgt.330.1606258664418; Tue, 24 Nov 2020 14:57:44 -0800 (PST)
Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id 21sm86242pfw.105.2020.11.24.14.57.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Nov 2020 14:57:43 -0800 (PST)
To: John R Levine <johnl@taugh.com>
Cc: Seth Blank <seth@valimail.com>, "dmarc@ietf.org" <dmarc@ietf.org>
References: <20201124020453.AFDC027CE5C8@ary.qy> <cd855b53-d9bd-3412-3bd5-dc4b7720dc5c@mtcc.com> <948761a-f116-48cc-e5e3-bf2c6f462b@taugh.com>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <91049852-6e97-2bfb-2d0a-067c839db28a@mtcc.com>
Date: Tue, 24 Nov 2020 14:57:42 -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: <948761a-f116-48cc-e5e3-bf2c6f462b@taugh.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/3X2RqoQSblWH7UNUcFZ9kvZyLQQ>
Subject: Re: [dmarc-ietf] ARC questions
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Nov 2020 22:57:48 -0000

You'd be wrong. The only ad hominem was yours from yesterday and it was 
I think where *you* dismissed the very question I raised:

"Two or more levels of forward are quite common, particularly in large 
mail systems.  Look at mail coming out of Google and Microsoft's hosted 
mail and you'll see a lot of ARC headers.

Considering that the ARC RFC was published over a year ago, and it is 
implemented all over the place, could you explain what the point of this 
discussion is?  The people who designed ARC are not idiots.  If we could 
have fixed the mailing list problem with existing DKIM signatures, we 
would have."

And as I've said repeatedly, do not contact me in private.

Mike

On 11/24/20 2:53 PM, John R Levine wrote:
> This appears to me to be an ad-hominem attack on the people who 
> designed ARC, so I think we're done.
>
> On Tue, 24 Nov 2020, Michael Thomas wrote:
>
>>
>> On 11/23/20 6:04 PM, John Levine wrote:
>>> In article <e8e1d300-fbe7-6d10-c15f-30c29ab74237@mtcc.com> you write:
>>>> What I'm struggling to understand is what having authenticated 
>>>> auth-res
>>> >from a previous hop helps. this is what i found:
>>>
>>> See some of the previous messages. My usual example is a mailing list
>>> message that fails DMARC at the final recipient but passed DMARC (as
>>> recorded in AAR) when it arrived at the list. This lets the final
>>> recipient distinguish between real messages from subscribers and mail
>>> from spambots that happened to scrape both the list address and some
>>> subscribers' address and sends mail to one pretending to be from the
>>> other. (That definitely happens, I've seen it on lists I'm on.)
>>>
>>> I agree that the ARC document does not do a great job of explaining 
>>> that.
>>>
>>>> It would be kind of nice to understand what gap ARC actually plugs and
>>>> why it's important if you ask me. Also: there seem to be a lot of ways
>>>> to achieve this, but this one is probably the most complicated one 
>>>> that
>>>> I can envision.
>>> If you want to pass the A-R results through multiple rounds of
>>> forwarding, you can't do much less.
>>
>>
>> Sorry, changing the auth-res to old-auth-res and dkim signing the 
>> message would be completely sufficient, and far easier to understand 
>> with a lot less bloat. All of this hand wringing about dozens of 
>> message manglers in the path before it get to the destination and not 
>> be able to figure out which auth-res was which seems wildly out of 
>> proportion for what the normal case is: 1 message mangler in the path 
>> before it arrives at the receiver's domain. Just like this message 
>> right here. That's why I asked how common that was, which was 
>> dismissed, but not answered.
>>
>> Mike
>>
>>
>
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly