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

Neil Anuskiewicz <neil@marmot-tech.com> Mon, 08 April 2024 19:33 UTC

Return-Path: <neil@marmot-tech.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 CB927C151547 for <dmarc@ietfa.amsl.com>; Mon, 8 Apr 2024 12:33:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.192
X-Spam-Level:
X-Spam-Status: No, score=-6.192 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, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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=pass (2048-bit key) header.d=marmot-tech.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 UQjY9JpaaI5G for <dmarc@ietfa.amsl.com>; Mon, 8 Apr 2024 12:32:57 -0700 (PDT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 00D4FC151545 for <dmarc@ietf.org>; Mon, 8 Apr 2024 12:32:56 -0700 (PDT)
Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-1e36b7e7dd2so27721765ad.1 for <dmarc@ietf.org>; Mon, 08 Apr 2024 12:32:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marmot-tech.com; s=google1; t=1712604775; x=1713209575; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=QC7YMwbRoCwuB5oZ7OSVWRDY/YzpU5xa6I10wyXrh2E=; b=XCW63pMN24MkBgnM4FEcdfh0N5Rx6CWL6Ja2LUzYfKpMzMnkApM3BXJPTrXejoSfbC IW4EBQCU0FMzMWqZEVR0B4hLWam2vDbmhMeTaR2i0I+KIHPAYI9KIUrhzeqr0JjS6/9f cXtFdyMIBxu88rNGKKn7rlehJ7nHjlZ8sAv9jVkOnHdZagzR3YaTAs5Q1nJ1050dKUht zX2m4DZnef2f4+T/IN2GYcbDcvo7busVT3LOpIA0gdvGxYu1XrNkVO68+cF5duJ557GT 4s+q8YclNujNbW8iO/DTxUhySowDODzZi9eD5GJns0eVLsuzUazPMngXahxXXchvdBBK l1iA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712604775; x=1713209575; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QC7YMwbRoCwuB5oZ7OSVWRDY/YzpU5xa6I10wyXrh2E=; b=IXqLXjB8whplwFCVsCSfi+v95/Q8lvcxfdAu+p7fXKF5K5KDf94MJT9b2cgzItq4zj iukGK7ZC52twgBdPe18H3I1CG5rIualRmDc5yyt99YzAPfR0Vq/79TesRslws6R4Qt87 t6g0Xmea8ap30yeAgW+rFkrL2iKtP1QDD/mp1P5WWd4qVYlsAmQ+pTupk3MEjokPDl7S L5tQbn32z6D/o0rOz1UyHlmfEDxBZvCpJbvRc6zyqtBcdl0Z0s1RQ43S5/fLEKuwVTai 13mNmID2zSZZEN2Ft6DeUArTHXN/YxuNXdKj370I6B+7nvqmnrh4Vg0An81FpbmhbBrP r11A==
X-Forwarded-Encrypted: i=1; AJvYcCUiHQsxdfeiE0RAFCiFX22grpDuD0qy1y8voikK17EL26riJqvFrvdx5qFyynmudwncW6wJxpNhjwwlD/FruQ==
X-Gm-Message-State: AOJu0Ywmpkry5EdgIBFYf/tZ0ysjRvurO3dEZyZUzMMNTrlVH7zAx49E Sl7ERFzvuPGistCG4omSSMfLPgbi8v27HELKIo655/2TUypJ0TIMH4toufVbyIxgvZzcdGpgcFQ a
X-Google-Smtp-Source: AGHT+IHmRzKqHFQY6Q1fw8y81AZdrnv5e3+VNXpguTc+7kquoWqkN8cYxYLjMGJn23PUOxdxelDpFw==
X-Received: by 2002:a17:903:40c2:b0:1e4:60d4:916b with SMTP id t2-20020a17090340c200b001e460d4916bmr1940699pld.64.1712604775012; Mon, 08 Apr 2024 12:32:55 -0700 (PDT)
Received: from smtpclient.apple (c-73-96-89-175.hsd1.or.comcast.net. [73.96.89.175]) by smtp.gmail.com with ESMTPSA id kp11-20020a170903280b00b001e20afa1038sm7395225plb.8.2024.04.08.12.32.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Apr 2024 12:32:54 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-24B1D67F-400F-4721-A2DB-56BA78CBA5DD"
Content-Transfer-Encoding: 7bit
From: Neil Anuskiewicz <neil@marmot-tech.com>
Mime-Version: 1.0 (1.0)
Date: Mon, 08 Apr 2024 12:32:43 -0700
Message-Id: <62B04142-F7F9-46D5-9E87-0367F8DE2E97@marmot-tech.com>
References: <CAOZAAfP9tXi80Fi=ZkgPpGwHo1fDbdSOZwVcnuPDbbc2xQd-7A@mail.gmail.com>
Cc: John Levine <johnl@taugh.com>, dmarc@ietf.org
In-Reply-To: <CAOZAAfP9tXi80Fi=ZkgPpGwHo1fDbdSOZwVcnuPDbbc2xQd-7A@mail.gmail.com>
To: Seth Blank <seth=40valimail.com@dmarc.ietf.org>
X-Mailer: iPad Mail (21E236)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/rfcYJ8orzcamF1I3Uy8aVZIKqlc>
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, 08 Apr 2024 19:33:00 -0000



On Mar 31, 2024, at 12:45 PM, Seth Blank <seth=40valimail.com@dmarc.ietf.org> wrote:


On Sun, Mar 31, 2024 at 2:00 PM John Levine <johnl@taugh.com> wrote:
It appears that Mark Alley  <mark.alley@tekmarc.com> said:
>>   People who publish -all know what they do.
>
>I posit that there is a non-insignificant amount of domain owners that
>don't know what the consequences of -all are other than that they've
>been instructed to use "-all" by a guide online, ...

I'm with you.  I have had too many arguments with people whose SPF records
end with -all and insist it is everyone's fault but theirs that their mail
doesn't get delivered.

The special case of a record only containing -all, meaning they send no
mail whatsoever, is different and I don't think it's contentious.

But I still am reluctant to give people a lot of advice about how to
sent up their SPF records. This is dmarc-bis, not spf-bis.

I concur, and do not want to accidentally make normative updates to SPF.

SPF hard fails in a DMARC context is a constant point of confusion and bad operational practice. I do think the spec should cover it in a concise and mostly informational way.


My proposed text was:

----
Some Mail Receiver architectures implement SPF in advance of any DMARC operations. This means that an SPF hard fail ("-") prefix on a sender's SPF mechanism, such as "-all", could cause that rejection to go into effect early in handling, causing message rejection before any DMARC processing takes place, and DKIM has a chance to validate the message instead of SPF. Operators choosing to use "-all" to terminate SPF records should be aware of this. Since DMARC only relies on an SPF pass, all failures are treated equally. Therefore, it is considered best practice when using SPF in a DMARC context for domains that send email to end records with a soft fail ("~" / "~all").
---

Could this work with simply the removal of the last sentence covering best practice?
 

R's,
John

John’s treatment of this topic is as clear and concise as I’ve seen. Excellent.