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:52 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 C3197C14F60D for <dmarc@ietfa.amsl.com>; Sat, 6 Apr 2024 10:52:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.397
X-Spam-Level:
X-Spam-Status: No, score=-4.397 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_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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="l6f+Q+HG"; dkim=pass (2048-bit key) header.d=kitterman.com header.b="Wpx+6N/V"
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 xDljS9rkpmXS for <dmarc@ietfa.amsl.com>; Sat, 6 Apr 2024 10:52:30 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 22835C14F5F3 for <dmarc@ietf.org>; Sat, 6 Apr 2024 10:52:24 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id B47F6F8020E for <dmarc@ietf.org>; Sat, 6 Apr 2024 13:52:12 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1712425917; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=Lz1Boucz5ElW+JzC0uIXJgClnJZMlgoqegLa6d+vjhE=; b=l6f+Q+HGvZexidoeqbqQYRsiBrtZcyRKv+NeJ7X+FxEuFYX2Fi7rge83BCGnR1RubyyRi E6uNs4dZ9SZTg/ZBg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1712425917; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=Lz1Boucz5ElW+JzC0uIXJgClnJZMlgoqegLa6d+vjhE=; b=Wpx+6N/VZxOm/Am6uIbsQ8BB9RQXovJyT7jI15rT8Qn4Gg0zTKYBdUPiipcZSVAlWpLIE 9bsY8nkWcldr1XvTlpRrDHVZXWmfd65c5taYan20RsNx4DRFwwl7k+xXOuU4Oc2whrplxhf 2SHHR2dqJcfl2qKa+I452sbK9Z6pJQHSxE6GiLDFFrDIKROuysF73zpDO7vKHuBLYdd+CQL 6cWm2WhkCThOGM95VFjz4b5HDE8Al1Ucv5WiDNZIgGHBBVYpXdo/JTIzWd7dWPoEBU5hiZJ 2Kq4AFueWP80uwPfuWaBbOzt2YJQAUtT95n2m9kAf1Mr0Gvuci/znqfbdMTw==
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 A2C6AF80126 for <dmarc@ietf.org>; Sat, 6 Apr 2024 13:51:57 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Sat, 06 Apr 2024 13:51:51 -0400
Message-ID: <10772164.eV7dEhVGUO@zini-1880>
In-Reply-To: <CAOZAAfNkz6wu_ZOUR7-iojreAzTHONnC600SnTLArHd+EK28ag@mail.gmail.com>
References: <CAHej_8=te5Zx_5-rB67CLPy_Eh03H6bE=34T-sTAwwmnvRTqWg@mail.gmail.com> <2791156.Tha2kTCVin@zini-1880> <CAOZAAfNkz6wu_ZOUR7-iojreAzTHONnC600SnTLArHd+EK28ag@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/IgWWDXdwnf_sh49PnbneraU3uEc>
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:52:34 -0000

I hear you.  Your operational issue is my system working as designed.  DMARC 
works on top of SPF, it doesn't change it.  

Anything like this belongs in an operational guidance document, not in the 
protocol description.  I have no problem describing the trade offs in an 
appropriate document, but I don't think this is it.

Scott K

On Saturday, April 6, 2024 1:47:07 PM EDT Seth Blank wrote:
> You’re not hearing me— this is something that comes up frequently for
> organizations working to implement DMARC. Others have confirmed on list.
> This is not an academic concern, it’s an operational one as elevated by the
> charter.
> 
> Your other examples you cited do not come up in practice as issues for
> domain owners looking to do DMARC.
> 
> Yes, let’s get back to N.
> 
> S
> 
> 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:44 Scott Kitterman <sklist@kitterman.com> wrote:
> > 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
> > 
> > _______________________________________________
> > dmarc mailing list
> > dmarc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmarc