IETF Logo Mail Archive

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

Seth Blank <seth@valimail.com> Sat, 06 April 2024 17:27 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 DE4EBC14F60F for <dmarc@ietfa.amsl.com>; Sat, 6 Apr 2024 10:27:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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_IMAGE_ONLY_32=0.001, 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 WzcnCYmWExFX for <dmarc@ietfa.amsl.com>; Sat, 6 Apr 2024 10:27:30 -0700 (PDT)
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 AAE13C14F5FD for <dmarc@ietf.org>; Sat, 6 Apr 2024 10:27:30 -0700 (PDT)
Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-1e252f2bf23so27706425ad.2 for <dmarc@ietf.org>; Sat, 06 Apr 2024 10:27:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; t=1712424450; x=1713029250; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=b4Wl8RkzedS366BrfIEW8ObEECnIa8aHvSbTXQAgtXY=; b=dbW38wV9HcbJJobZ6hA0vHvGJA5p56T2cZ4XFu78+1j+N5RzjruZd4QvFdbK0SbmSw ywV1ff7N8AziD2KCAFBGQuANAkqFc9ull4QGcWE1fvjgj9FpYydHZJ4tbkqujEeENAxv ZemFGvfd+Z6KRUc0YsC3N9tr1TMcnnzYDYCrzzHNepMgYoPg9Gxij+DxrHASP5zqvZGu lDpNyM1aJ5m2hD7HTHdh3LNVuH6ev8Yt3PYQmFt4ftjT8evFJ07/uLpo5b/DLwYzU8i9 JIVvrvV0pmGHD3K6rbRVDaaDlhIYYL+t+yHzrAyH//NSU6MSzkSUvKS+/N0MMyGkuR3R ixJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712424450; x=1713029250; h=cc: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=b4Wl8RkzedS366BrfIEW8ObEECnIa8aHvSbTXQAgtXY=; b=FVbq9Oc2ILTemLG1IbdbEBeCaaps0n2m/z4V4mRPaUc5p7zMn/tAyVTmb/05lxlqTk 2m7FdoTNrFYMAoODLdBDwPMcg0KF3QLlkM49+zTkHUJXlQ1P6W2dR/9qGUKyid74Hnxv fdoyAd4RAfcUv9MnqIdvVMhCXvA7XjbIrgH2sVGiiCwwf5cO1u/Y76tn2jMoPKreChjv I07PwlyFVH5163m8f4BfHlFaSjLDm86vGZ+Zmv1AIAHxKLK3yd+Z1ZfEn5yg1gSXCNCu 2QYAxndlmWkJpu08DlxxA9XAzUPIs3mTNGBiQQrebGgqqsHQ2UO4ALPL/tbqlKF9u3gO cE/A==
X-Gm-Message-State: AOJu0YwlOIZWKMShOoaf7pT+YKRLUQ88FbeW0e91TFHJGpriZGzz6LXR rymueJdHQWcb4laDNqMSuKkn4BdHHp4tIsidN6ep/R+oBZ00w+exh01EBYVXu1ltZ2Rw02myI6T VhdePt+99hnyIgYsQ6q/TrLrkOINe6cR26nuZfOZH0hE5hjho
X-Google-Smtp-Source: AGHT+IH+WbX5/yh/XCv8VtXoiWIYrdaoAV9Ohw1J1mOZSPsW17hssaskEOYs/BXDXLXtK1hxmXLZ0O5s6BJ2G/UKd38=
X-Received: by 2002:a17:902:e395:b0:1e2:16b6:e9b6 with SMTP id g21-20020a170902e39500b001e216b6e9b6mr3080534ple.48.1712424449570; Sat, 06 Apr 2024 10:27:29 -0700 (PDT)
MIME-Version: 1.0
References: <CAHej_8=te5Zx_5-rB67CLPy_Eh03H6bE=34T-sTAwwmnvRTqWg@mail.gmail.com> <2267299.JiQHTZpMlS@zini-1880>
In-Reply-To: <2267299.JiQHTZpMlS@zini-1880>
From: Seth Blank <seth@valimail.com>
Date: Sat, 06 Apr 2024 13:27:18 -0400
Message-ID: <CAOZAAfO3CY3z0cCHEeRvqf0r3Vac+ZJ2n5iZY_2GV0ZET5ohKg@mail.gmail.com>
To: Scott Kitterman <sklist@kitterman.com>
Cc: dmarc@ietf.org
Content-Type: multipart/alternative; boundary="000000000000059e23061570e303"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/UDBMYwNnPfZWfmXWPwRwzj_P9gw>
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:27:35 -0000

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
>

v2.23.0 | Report a Bug | By Email