Re: [dmarc-ietf] ARC questions

Michael Thomas <mike@mtcc.com> Tue, 24 November 2020 22:49 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 68BCB3A0E87 for <dmarc@ietfa.amsl.com>; Tue, 24 Nov 2020 14:49:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 e5CpeP3TDGDy for <dmarc@ietfa.amsl.com>; Tue, 24 Nov 2020 14:49:20 -0800 (PST)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 2609C3A0E84 for <dmarc@ietf.org>; Tue, 24 Nov 2020 14:49:19 -0800 (PST)
Received: by mail-pl1-x62f.google.com with SMTP id v21so59546plo.12 for <dmarc@ietf.org>; Tue, 24 Nov 2020 14:49:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=hbuWHpxqWEfZ3IZZQNk1q+802DhIb3RsgVi3cvpOB0Q=; b=N/evXsHuQKLY6iAz2CapNQFqAkVpE3ke9jVw2LDbFMzKkr0mxtsVE1kCXB8c8sA2n4 5fqI8wUFZgwvzHkweN3GtEdHlqH0Lm8g2U07Lm8s427AfQ6gr1eE534CAo0f1hv+xDpE V3vbSQe+WbXj+9HEP8xD7ZnM8vS9f47t4LueGoTn5h8OTomTVOtqRHZaxYcCJvz40vmZ EVBQlPdoIYoi6ubL5vi5vTwRIhuiAp03KnU+N17O66qiMtGmaPRusfXybynevsmzj4pG ACZrJT5hG8SCB9ggbWA01sFvrUD5hAbN+FcUF4TD6sV9FNHZ/uNyPIdTBqiZmQAhwUwC UUpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=hbuWHpxqWEfZ3IZZQNk1q+802DhIb3RsgVi3cvpOB0Q=; b=FQNvbj9yy2Mpkn3HU8jcpVsM2oHs9UTnpbhYBGfFSEDDDDrG5kpuIV/fXjD+lYRHQW P8XgoeAJcowiVkmYuWJ18ebN2obIxgdd6hJ9B3wPYXH9tafyl6+GdFipAPiP62JL/X9t 2IutBNj12A9YaNlyXdOpOnObXrVLpYj6knIgDvY5dEvEqOewXWVY252FhcpOAWYgkKgV fYs4jiNnixCRlrNqHPM6CePKqntYHaQGrLyvyrCpFQKFmkHRCFXhD5oJXjwTFYU9x+T+ Qz9X8ntXWvGSoZydYc1Ks7TV8S86rKURAYLH2mK4JjlYRERaXH4UKW889QonCN6mLNHc txYw==
X-Gm-Message-State: AOAM531UuAczw+IpYbjsOcp4HnVLKgnbSfS0x1vsrhK0hc9JfudeXd9L lZjzOFhXuJbfSMabkFN60EP/qvcJ4WOM+w==
X-Google-Smtp-Source: ABdhPJyBlqQMh/Bfl4G7zXZe/RaDDbhptItfOR33i35OzeyYDGLnS2Ox+knQsNeAHa4VSM0q+FugDw==
X-Received: by 2002:a17:902:6b45:b029:d6:c43e:ad13 with SMTP id g5-20020a1709026b45b02900d6c43ead13mr550625plt.77.1606258159062; Tue, 24 Nov 2020 14:49:19 -0800 (PST)
Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id w2sm228799pjq.57.2020.11.24.14.49.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Nov 2020 14:49:18 -0800 (PST)
To: John Levine <johnl@taugh.com>, dmarc@ietf.org
References: <20201124020453.AFDC027CE5C8@ary.qy>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <cd855b53-d9bd-3412-3bd5-dc4b7720dc5c@mtcc.com>
Date: Tue, 24 Nov 2020 14:49:16 -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: <20201124020453.AFDC027CE5C8@ary.qy>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/xyIlmatAT1Lfw5zoe7wZwW2pvio>
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:49:21 -0000

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