Re: [dmarc-ietf] ARC questions

Seth Blank <seth@valimail.com> Tue, 24 November 2020 23:02 UTC

Return-Path: <seth@valimail.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 5F6603A0E7C for <dmarc@ietfa.amsl.com>; Tue, 24 Nov 2020 15:02:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 piycSmJgDD8C for <dmarc@ietfa.amsl.com>; Tue, 24 Nov 2020 15:02:50 -0800 (PST)
Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 A1EDA3A0E83 for <dmarc@ietf.org>; Tue, 24 Nov 2020 15:02:50 -0800 (PST)
Received: by mail-ua1-x92d.google.com with SMTP id y26so114423uan.5 for <dmarc@ietf.org>; Tue, 24 Nov 2020 15:02:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sRqQhrqkwOeghAvUNhn86GusgtFYk5rxEaDIm2mrdfw=; b=HrwF8DKueybpoxID648hDiwxf+3jmFKrk1lG7xmL+DQhqeGlfFklWBANJLRqdZcCne X8YKyVAc9AGc9+BmYBuinyvfVcl9Xy6FamBhtg0BHzv81IdCTo82B7YIokyTyVyzW7Uh dXfrdUpxTh2OLUn1Xtj4lMawgJ80kKIbJKEOkUYXavwch3IwxIDm4ynO9psiUC2oaCw6 iGMneuQe1lg0d7zcPGzlMaJapnzvOY28K2NQCYu+vxdjejDvfPUvqoj7N9xqR5ycVBV3 VlZ1cdpAmY2qJ5Ifq+XYQtn4jSPrsCXctqmeuZr574WlUic55PvsY04RdOVyhicjhaCK ktIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sRqQhrqkwOeghAvUNhn86GusgtFYk5rxEaDIm2mrdfw=; b=WS4ZH6oKEP+tiwt+WOXGFEo2W/aMraSYasFECYRmjnyQBat28guV8Wb0HIN4lkwFai 6DgW6mZiqKpxB1hF+M+PJ7GP4IKwH8jMMRpwQfyghiR+meK4Z6rhy2DLIXPklxXsE+Y5 MdR+L8O0ZaGyb0lcu6Vb/G+bObeefTZsTBL5Gb+qymNhMUbOjgPg2UZpU/LTZJv4JfBH 1f/Q9HeQhJLwhPI+ziumk9VMqqRP0Nyt/+ZD3Tm0fSMcr4W1SeCmXhkuWgxuSZMNveqz YnCyH4+XngHfGqN/kBNl7CqcosexIY6Sl+fngPWhXKKYVbPtIWwyhzcABob/ad26Dhlb phgQ==
X-Gm-Message-State: AOAM530/D1IuaFsI0gB5WGxGK/zaBNGxgZyAXyLGyDwH2635eWIRRl8J 5ywIu4/FAhdjAE6gAMP552TtEyme4yfjbAPNGO45Jbevxmo=
X-Google-Smtp-Source: ABdhPJzaeKEjaFiVCfxWpASO0GNR5S6MdrjiBMX1dUcqC1+gihyyLvga2FzU9Gux7rLANjIyRual3TauO5SOMHcuak0=
X-Received: by 2002:ab0:3901:: with SMTP id b1mr458348uaw.34.1606258969057; Tue, 24 Nov 2020 15:02:49 -0800 (PST)
MIME-Version: 1.0
References: <20201124020453.AFDC027CE5C8@ary.qy> <cd855b53-d9bd-3412-3bd5-dc4b7720dc5c@mtcc.com> <948761a-f116-48cc-e5e3-bf2c6f462b@taugh.com> <91049852-6e97-2bfb-2d0a-067c839db28a@mtcc.com>
In-Reply-To: <91049852-6e97-2bfb-2d0a-067c839db28a@mtcc.com>
From: Seth Blank <seth@valimail.com>
Date: Tue, 24 Nov 2020 15:02:37 -0800
Message-ID: <CAOZAAfNWeAPJm9tU3ya5h+O2JwEEdBLoA9n1iGwjV3D8nkd1=w@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Cc: Michael Thomas <mike@mtcc.com>, John R Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary="00000000000044af7505b4e24f46"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/M9wwgMpG5oPsIlXPUtMgUHqN_ns>
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 23:02:53 -0000

As Chair-

This thread is quickly becoming unproductive and veering to personal
attacks, which will not be tolerated.

Please engage productively and on the merits, take the conversation
elsewhere, or disengage.

Seth

On Tue, Nov 24, 2020 at 2:57 PM Michael Thomas <mike@mtcc.com> wrote:

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


-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* seth@valimail.com
*p:* 415.273.8818


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.