Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all

Scott Kitterman <sklist@kitterman.com> Sat, 06 April 2024 17:44 UTC

Return-Path: <sklist@kitterman.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 4AED1C14F60D for <dmarc@ietfa.amsl.com>; Sat, 6 Apr 2024 10:44:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b="Kh6BMqyX"; dkim=pass (2048-bit key) header.d=kitterman.com header.b="iKGDDqMs"
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 O76g-0OxZ59M for <dmarc@ietfa.amsl.com>; Sat, 6 Apr 2024 10:44:04 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E652CC14F5F3 for <dmarc@ietf.org>; Sat, 6 Apr 2024 10:44:03 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 462CFF8020E for <dmarc@ietf.org>; Sat, 6 Apr 2024 13:43:22 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1712425387; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=G2bZpX7Zp+x0kn47IdONLn9KebDw6+FUQ9AJynvPSDY=; b=Kh6BMqyXDqN5Xxtwu19J/BTGuZIlhCiAZsyLuzySYZVxAbXTeunwS1cBllneHFhGJKJC7 wQXSbl9ERZH/cleBg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1712425387; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=G2bZpX7Zp+x0kn47IdONLn9KebDw6+FUQ9AJynvPSDY=; b=iKGDDqMslOAZPmbQMBpFi5NFyQ/Dumah5qqsSRKy3j9XQi83bm8JdwaMDaansTlW/896h iFW3Z+tXU7jR8nM+6flKkZ38vt+Y+kHwNFnSg35Jjlr518LS7DPXOVM31VhEYjQBqf+rYwJ oy7mKwWcGGqzQSJCyUL7Srk9RhVXuCR2H0g/HzNvxbdXXjXlZHIDbQmSdt5SJgxZLJwaX7Q IKVzva3RulnWGzRFMrRe9YiTRe3F9bwaL+wOG4H25s5b9C8ZcNr3eJOuwe+kHgIXRCvaqgG 9ujv4dBVNPkHbtl2cEWdDUEgBrgjcRqho3ZtZOkty228MYVp7AQjiH0J2k/Q==
Received: from zini-1880.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 17422F80126 for <dmarc@ietf.org>; Sat, 6 Apr 2024 13:43:07 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Sat, 06 Apr 2024 13:43:02 -0400
Message-ID: <2791156.Tha2kTCVin@zini-1880>
In-Reply-To: <CAOZAAfO3CY3z0cCHEeRvqf0r3Vac+ZJ2n5iZY_2GV0ZET5ohKg@mail.gmail.com>
References: <CAHej_8=te5Zx_5-rB67CLPy_Eh03H6bE=34T-sTAwwmnvRTqWg@mail.gmail.com> <2267299.JiQHTZpMlS@zini-1880> <CAOZAAfO3CY3z0cCHEeRvqf0r3Vac+ZJ2n5iZY_2GV0ZET5ohKg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/k4j_aeksoKQ-FtDBInQgEh8nM1o>
Subject: Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
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: Sat, 06 Apr 2024 17:44:08 -0000

The same thing can be said for every step of email processing that comes 
before DMARC.  If I reject your mail due to your IP being on a block list, you 
also don't get DMARC feedback about it.

It was long enough ago that I don't remember if it was RFC 7489 or early in 
this working group, but we did have extensive discussions about this before 
and that's how we got where we are.  I don't think there's a lot of value in 
redoing that discussion.

I think your N=5 versus N=8 topic is more important and much more on topic.

Scott K

On Saturday, April 6, 2024 1:27:18 PM EDT Seth Blank wrote:
> Scott, I disagree.
> 
> SPF hardfail in a DMARC context is an operational issue that comes up with
> some frequency for domain owners.
> 
> We should have some minimal amount of clarifying text.
> 
> S, individually
> 
> Seth Blank | Chief Technology Officer
> Email: seth@valimail.com
> 
> 
> 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.
> 
> On Sat, Apr 6, 2024 at 13:01 Scott Kitterman <sklist@kitterman.com> wrote:
> > On Monday, April 1, 2024 4:45:20 PM EDT Todd Herr wrote:
> > > Greetings.
> > > 
> > > Issue 141 has been opened to collect ideas around the discussion about
> > 
> > what
> > 
> > > to say in DMARCbis (if anything) about honoring SPF records that end in
> > > -all when SPF fails.
> > > 
> > > https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/141
> > 
> > I don't really understand the need for this.  What to do when SPF produces
> > a
> > fail result is an SPF question.  Not a DMARC question.  Additionally, we
> > have
> > discussed this before.  Note that not even RFC 7208 tells receivers what
> > to do
> > with SPF fail.  It seems far, far out of scope to do so here.
> > 
> > On the theory that the invocation not to relitigate things we've already
> > gone
> > through won't be honored entirely in the breach, can we not do this?
> > 
> > Scott K
> > 
> > 
> > 
> > _______________________________________________
> > dmarc mailing list
> > dmarc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmarc