[dmarc-ietf] Ticket #1 - SPF alignment

John R Levine <johnl@taugh.com> Tue, 01 December 2020 22:17 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 632B83A03F1 for <dmarc@ietfa.amsl.com>; Tue, 1 Dec 2020 14:17:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=XdFOFpQb; dkim=pass (2048-bit key) header.d=taugh.com header.b=INJmGjuZ
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2zqWiTW9yOEg for <dmarc@ietfa.amsl.com>; Tue, 1 Dec 2020 14:17:18 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A64E3A03C9 for <dmarc@ietf.org>; Tue, 1 Dec 2020 14:17:18 -0800 (PST)
Received: (qmail 78072 invoked from network); 1 Dec 2020 22:17:15 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type; s=130f4.5fc6c0eb.k2012; i=johnl-iecc.com@submit.iecc.com; bh=xLnYU9z6saRW44p9YamdsH8NKg6qN3dQq67EoNFxGBY=; b=XdFOFpQbeyxOosdIl+SByPqvTdqngRnlhoiueU0IFWUIZj+GQkQ3dbLnjg/2RhMKPZ++dyxYoT2wWTzisvLUKB8Ux2nWKxHm2sE4NrffVhBlKhDJ2Uc1GiLHYxjGsWymvHk0kF0Xvvv8D5Kr4A7I9ZMT+9T0sZ3hONYAIVgoxf6gikLv09Z4npmi9FHbIvWhRLtaAx0XDNJYiM8A1xqsh5l/Ooju3uctJTLSGkb3D/H3F0aZLILjeIWozt7pMUl/4Ng0mUf5u+FYOrU2T1PrhQEt0sdqF0MjURHZUvofapfofv/mlO+62fSjiRdyza/HCyhbBSoYu0rLFf68LWAzPg==
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type; s=130f4.5fc6c0eb.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=xLnYU9z6saRW44p9YamdsH8NKg6qN3dQq67EoNFxGBY=; b=INJmGjuZNZ2OzLcm4VAvL6j3rLW9KSr/UVDLOCpT4ruQpIPp3d7uJO27KW6m80FW91tNfIY3NEVFvYjZKjbCrLTr0o7IZ5bFIazScGYnjENujd4LEe6WXwaOG+UPamY+75eaub0TzPwFUZ5IKGs/OZDj35+idsDkC98jmYiaqEfg8h50UMAmBEhQYmiX1XY55DECqE60axO5BeKQVQnEMeypdFzFEIem2un1jb5JO6MD+JhZxVmJc7y0xHlW2By2LD25e7TM4+7rUKcJZtqVlnMlTV60uPAlylVJbEMG79ySvVeQ32XBRko8d3NuigJD9cpsu26Bq2k9M3t0miQwMA==
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 01 Dec 2020 22:17:15 -0000
Date: 1 Dec 2020 17:17:15 -0500
Message-ID: <bef64e7a-571b-a73f-dc91-aa402ca320c8@taugh.com>
From: "John R Levine" <johnl@taugh.com>
To: dmarc@ietf.org
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-1471237373-1606861035=:99975"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/9RO1vASQ6N0Yt2oEXBy0u1ZYD8g>
Subject: [dmarc-ietf] Ticket #1 - SPF alignment
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 01 Dec 2020 22:17:20 -0000

We would like to close this ticket by Dec 15, two weeks from now, so short 
trenchant comments are welcome.

Ticket #1 is about SPF alignment.  We need to replace references to 4408 
with 7408, ando clarify what if anything we do with SPF HELO checks if
the MAIL FROM is null.  One possibility is to say only MAIL FROM SPF 
counts, if you want to align your bounces, sign them.  The other is to 
explicitly say that HELO alignment is OK on bounces.



From: Anne Bennett <anne@…>
Date: Fri, 16 Jan 2015 19:10:56 -0500
Subject: [dmarc-ietf] SPF RFC 4408 vs 7208

On Jan 6, Murray S. Kucherawy confirmed fixing the reference for
the SPF RFC from the now-obsolete 4408 to 7208 ("Fixed in -11").
However, -12 still has, in section "3.1. Identifier Alignment":
For example, [DKIM] authenticates the domain that affixed a
signature to the message, while [SPF] authenticates either
the domain that appears in the RFC5321.MailFrom? portion of
[SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom?
is null (in the case of Delivery Status Notifications).
Actually, RFC 7208 states that:
Checking "HELO" before "MAIL FROM" is the RECOMMENDED sequence
if both are checked.

... and implies that if the first check passes, the second
is unnecessary:

If a conclusive determination about the message can be made
based on a check of "HELO", then the use of DNS resources to
process the typically more complex "MAIL FROM" can be avoided.
So the RFC5321.EHLO/HELO domain is checked not only if the
RFC5321.MailFrom? is null - in fact in cases where sites have
followed the RFC 7208 recommendation, it will be checked first,
at least by a "pure SPF" implementation.
This means, first of all, that the -12 text above needs fixing.
But also, I'm struggling with what it means for alignment.
I can think of some real-life cases where only one of
HELO or MAIL FROM aligns with RFC5322.From, even though
both would "pass" in a pure SPF check. IMHO, Section
"3.1.2. SPF-authenticated Identifiers" needs to be clarified
to better take HELO into account.
I'd like to see an approach similar to that for DKIM, where it
is explicitly stated that:
a single email can contain multiple DKIM signatures, and it
is considered to be a DMARC "pass" if any DKIM signature is
aligned and verifies.
Similarly, I think that for SPF, it should be considered a pass
if either the MAIL FROM or the HELO is aligned and results in a
pass at the SPF level.
But whether it is decided to take into account both HELO and MAIL
FROM, or whether it is decided to ignore HELO (modulo its use to
construct an artificial MAIL FROM if the latter is null), the text
should IMHO make this clear one way or another, both in "3.1.2.
SPF-authenticated Identifiers":
In relaxed mode, the [SPF]-authenticated domain and
RFC5322.From domain must have the same Organizational Domain.
In strict mode, only an exact DNS domain match is considered
to produce identifier alignment.

... and in "4.1. Authentication Mechanisms":

o [SPF], which authenticates the domain found in an
[SMTP] MAIL command when it is the authorized domain.
In both cases, the text should specifically mention HELO,
and whether to include or exclude a HELO SPF result, in view
of HELO's prominence in RFC 7208.
If it is decided to allow both HELO and MAIL FROM results to be
passed back to DMARC, then in section "6.6.2. Determine Handling
Policy", item 4 should be updated to reflect that as well.