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

Todd Herr <todd.herr@valimail.com> Mon, 01 April 2024 18:33 UTC

Return-Path: <todd.herr@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 E2477C151520 for <dmarc@ietfa.amsl.com>; Mon, 1 Apr 2024 11:33:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 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, 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=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B09FznqO9coR for <dmarc@ietfa.amsl.com>; Mon, 1 Apr 2024 11:33:34 -0700 (PDT)
Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6406C14CE44 for <dmarc@ietf.org>; Mon, 1 Apr 2024 11:33:34 -0700 (PDT)
Received: by mail-yb1-xb35.google.com with SMTP id 3f1490d57ef6-dc6d8bd618eso3912408276.3 for <dmarc@ietf.org>; Mon, 01 Apr 2024 11:33:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; t=1711996414; x=1712601214; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=3zjw+a9Jn8L7/P7PbYH0S5i8T9sxMJLlPkKlS+GvfrQ=; b=TpIP6wgE+PQaIjN4A3sA3I1ls4gjSaQuRECoezB5AcpkHf82FjHKmk0FPauOBOCGKK gQyHUekTm1ZkJ5it8+7LmmmID0TVWisuzTQQ6DE5bzX8NqmdAnQI4ZF5p3Lb8lOMk5U9 HLzPBcWZt/rxQjJDWGoLO/2eiHPUOASefYxr2XVWcZUBs6RIG0mDNfWhRQXRpa3/N+xT j7Q7y6KmPUcH7g4F0ULEDcitvfghRvw+y9CuzP6ozPvrYYt1cd7Wt9EsZGdLnQNzjlUO LZRTtcEutV0wcKoDm3oHaYsMbypdGxQho2OgHfvxX+rpopDZls9dM2s5mRVgaNQiFA4v aXPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711996414; x=1712601214; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3zjw+a9Jn8L7/P7PbYH0S5i8T9sxMJLlPkKlS+GvfrQ=; b=rlQ0UOjfURoEzwIVgYUUPR0qCMLXnWwlguGjlt5hULWLuthLq15tsGzwq4sbJFT1hW E0smBlzphbz/CQNz9Il1WYrf0TrUFuZvFPty24vPlqsun9rYMsFhbXSzH530+k7Eg2pG 0VneZVwUzL62s6ROC9rCkvxpVmYHaOhuJa4rR8WJhciciopR1E7L+2oSOCkfy0XebYXa Xfui9+ZyL2+hhQnpF/5+uxqtnb8vSoxzFKNQ+3uM8I9+gThGHnby3U0maJ1NaIXNpYhP qQaSK08Tgb7ZhoxS4r34kJa2JCRSvPnC7dEwsqxrY8LJISkGHJLXQBmAtiB7JW7PnDeg JAUQ==
X-Gm-Message-State: AOJu0YwBzVJSCJ5jg+Z7WDTGBZUm3vJDgX9wuueRKCPhBaSgxhMDz4sw hK1j8ILOEp2I/b7ECROuNuReqUsU5gQ695s6gVCOstlAovNgeilbRrkkOhGB8oyG+YCh41ywtLf k73GxQn3zLL2yE7yC2CTqSGr1qUgeCn+pujGFNfHu0emEl0+z
X-Google-Smtp-Source: AGHT+IHkUg6E389AUDVNmSe/0psmJuGuS2xDbXLpS/953PW+XcPnqWom525Xj3d23jQya4YluKI0Zu2gluFO2fj635k=
X-Received: by 2002:a25:6990:0:b0:dcd:8a5:d5b8 with SMTP id e138-20020a256990000000b00dcd08a5d5b8mr8840534ybc.49.1711996413799; Mon, 01 Apr 2024 11:33:33 -0700 (PDT)
MIME-Version: 1.0
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> <CB1B38EF-70FF-44D7-81B3-20211E4BCBDF@bluepopcorn.net>
In-Reply-To: <CB1B38EF-70FF-44D7-81B3-20211E4BCBDF@bluepopcorn.net>
From: Todd Herr <todd.herr@valimail.com>
Date: Mon, 01 Apr 2024 14:33:15 -0400
Message-ID: <CAHej_8=7kNoqXkBkcqoou=c4VLgspfvRbjGsPn0BnkohwqiD9w@mail.gmail.com>
To: dmarc@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001a11d706150d3a9c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/KI24aq_OwxDgx4PlNGoufY9pR9o>
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 18:33:39 -0000

On Mon, Apr 1, 2024 at 12:53 PM Jim Fenton <fenton@bluepopcorn.net> wrote:

> On 1 Apr 2024, at 9:26, Todd Herr wrote:
>
> > 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?
>
>
The second document also recommends that receivers "Make use of ARC
headers", but I do not believe that ARC header consumption is yet
widespread enough to consider that recommendation to be commonly
implemented. I myself am not a receiver, but I've been in enough
conversations on the topic, including a present M3AAWG initiative, to
understand the the long poles in that tent don't involve consumption of the
headers per se, but rather knowing or deciding which ARC signers to trust
and what to do when the message passes through multiple intermediaries and
not all of them ARC sign the message.

Should DMARC-bis reference ARC? I don't know; can it? What I mean by that
is that some of us have an interest in DMARC-bis being published as
Standards track, and ARC is Experimental, and I don't fully understand the
rules regarding down-referencing (is that the right term?).

-- 

Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.herr@valimail.com
Phone: 703-220-4153


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.