Re: [dmarc-ietf] Ticket #1 - SPF alignment

John R Levine <> Wed, 30 December 2020 21:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 998463A00D9 for <>; Wed, 30 Dec 2020 13:06:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.85
X-Spam-Status: No, score=-1.85 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, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=Vw9xlWeF; dkim=pass (2048-bit key) header.b=GnyODjw7
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G13852WsFPRX for <>; Wed, 30 Dec 2020 13:06:03 -0800 (PST)
Received: from ( [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 (Postfix) with ESMTPS id 4B2F63A00D3 for <>; Wed, 30 Dec 2020 13:06:02 -0800 (PST)
Received: (qmail 12293 invoked by uid 100); 30 Dec 2020 21:06:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:cleverness; s=2ffa.5fecebba.k2012;; bh=sU/+wv67JHomfJWLO2BrVO+4PYv4HHhCziRiICR4o2U=; b=Vw9xlWeF+SU0ePmTQfvzmnvu25Y8UCnIeZIwnBTM0x+6iByZt7KKnrl1kErjrMGM6OXcN3JyBeq/MVj/BRLcglCKvFXM9MW5JxTj3F57wBWFRKw2V2nav7ZP/em40HWtBS0DIHgYt/YXorMQkeFYs8YA3kq49Mzzp+2/6Ole1KWDklR9IWvKJ8BjF37TanX6wE0I0fDCVzGRcXtKTYFOzb8aG8mfGOyl7waz3vQcPiPdZoGyGmEyYMWWOAXuCzNonfDdrg009SyscJ5QKqx39Q21m8PBr4pUVODwDix+naxYF/+M5njZTTjNbzQhcjMsy4vYKIKI+tATQe20y9IJKA==
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:cleverness; s=2ffa.5fecebba.k2012;; bh=sU/+wv67JHomfJWLO2BrVO+4PYv4HHhCziRiICR4o2U=; b=GnyODjw78ypjs+JHmlP4zQwAMPtoWErVVZ+JCFq1O8mqUeVAuu2sbqmKXSzJXImPGcARZzSGtnfmjBcezrewxxZ9EuTbKFKLjnvHDf2QkKRAU5oZl9h2OCER5utQavyZdCi6fu2QHtRMWfdoJwiBH/uV8gsrMHjPuf8nZ0EB1sfsLaNf0XwKzcUqM2/+7nFhxsv3kDVTgWtG/jFtlK0ltiWJytR230pazMlQFgI9Jy2QtceHQJeHZHAUDl2RF+qHiKAZVhUsUtLrdadL0oCh9BOGRDIy2sbIsnziOyueQ9QLP/QIRBwll7rWhkVFkpaFlliyh1UgkTqJotLA43SC5A==
Date: 30 Dec 2020 16:06:01 -0500
Message-ID: <>
From: "John R Levine" <>
In-Reply-To: <>
References: <>
Cleverness: None detected
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="3168237118-343771159-1609362361=:5427"
Archived-At: <>
Subject: Re: [dmarc-ietf] Ticket #1 - SPF alignment
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Dec 2020 21:06:07 -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.

I didn't hear a lot of strong opinions, but I think they leaned in the 
direction of only checking the MAIL FROM, since the name of the MTA often 
is unrelated to the From: domain.

This means that if you want your bounces to be DMARC aligned, they'd need 
DKIM signatures.


> ================================================================
> 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.

John Levine,, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.