Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

Jim Fenton <fenton@bluepopcorn.net> Mon, 01 April 2024 16:53 UTC

Return-Path: <fenton@bluepopcorn.net>
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 3EDF7C14F5EA for <dmarc@ietfa.amsl.com>; Mon, 1 Apr 2024 09:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98BQC9QP_Q5D for <dmarc@ietfa.amsl.com>; Mon, 1 Apr 2024 09:53:37 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CCDDC14F5F9 for <dmarc@ietf.org>; Mon, 1 Apr 2024 09:53:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=AY/xeYo7VxxF3jq+6CuRV1bYkIDUKsJOL88H7dPn8ms=; b=o6ltDLegQDdZxNd+Imn0yzoqrb 951xDBpoc9yb7HvaDPNXgpEgeos7+kiuVd2AkAqYIVSphqNxTQ3zkiFJpR8qYrut20HNhFEeaLuZk s1vf9jK5bPq/7GdDJVWkdtBCCx1cN+OI9RsulGVOu8ElFQDKWnAUjRBUdTNXWyH7N7r8=;
Received: from [2601:647:6801:6430:75ef:9993:d6a1:7356] (helo=[10.10.20.233]) by v2.bluepopcorn.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <fenton@bluepopcorn.net>) id 1rrKuS-0006Z7-O8; Mon, 01 Apr 2024 09:53:35 -0700
From: Jim Fenton <fenton@bluepopcorn.net>
To: Todd Herr <todd.herr=40valimail.com@dmarc.ietf.org>
Cc: dmarc@ietf.org
Date: Mon, 01 Apr 2024 09:53:33 -0700
X-Mailer: MailMate (1.14r5852)
Message-ID: <CB1B38EF-70FF-44D7-81B3-20211E4BCBDF@bluepopcorn.net>
In-Reply-To: <CAHej_8=OxfPySzx0p2xR7iRmfai=CdU6iADECUCZoHXr6qvxcg@mail.gmail.com>
References: <eda55c54-c149-475c-8117-bfdf3885a883@tekmarc.com> <20240331180009.F36CD8687B50@ary.qy> <CAOZAAfP9tXi80Fi=ZkgPpGwHo1fDbdSOZwVcnuPDbbc2xQd-7A@mail.gmail.com> <lIU60SB3NeCmFAG+@highwayman.com> <CAL0qLwZt+bo4ydCVOQbfg6bQEv-ufXrrwr8Aege9Wsv7LgH=kA@mail.gmail.com> <CAOZAAfPtxdBwEthN26cgvAnAbQ70wym+2k0WjtKqNVf44=-vMg@mail.gmail.com> <MN2PR11MB435115B7428C63C1B1058D9EF73F2@MN2PR11MB4351.namprd11.prod.outlook.com> <CAJ4XoYfmyDykZGm9Gb1bxjz=pW_scqon3pDv-DRGHjFrnyCLoQ@mail.gmail.com> <CADyWQ+HbfegU=07gNyR-5Dby_71GNim4Nq-LyFerKHk1dV0=Nw@mail.gmail.com> <CAHej_8=OxfPySzx0p2xR7iRmfai=CdU6iADECUCZoHXr6qvxcg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/rBxqxjk8yof4Uhwpycd8g-sfUJE>
Subject: Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 01 Apr 2024 16:53:41 -0000

On 1 Apr 2024, at 9:26, Todd Herr wrote:

> On Mon, Apr 1, 2024 at 12:17 PM Tim Wicinski <tjw.ietf@gmail.com> wrote:
>
>> I have to agree with Seth's comments that "security teams believe an SPF
>> hard fail is more secure".
>> I've been on the receiving end of that discussion more than once.
>>
>> Also, can we reference those two M3AAWG documents ?  That seems like
>> operational guidance.
>>
>>
> I'm digesting the threads for the purpose of preparing tickets to track the
> work, and I suspect one of the tickets will include, "Add reference to the
> following two M3AAWG documents":
>
>    1.
>   https://www.m3aawg.org/sites/default/files/m3aawg_managing-spf_records-2017-08.pdf
>    2.
>   https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf

These are useful documents.

The second one seems to be saying that the recommended action for intermediaries is to use ARC, and doesn’t mention address rewriting. I have some concerns about whether enough receivers interpret ARC header fields for that to be viable, but that seems to be a better solution than address rewriting. To echo Murray’s comment, should DMARC-bis reference ARC?

-Jim