Opened 8 years ago

Last modified 20 months ago

#1 infoneeded defect

SPF RFC 4408 vs 7208

Reported by: superuser@… Owned by: todd.herr@…
Priority: major Milestone: Deliverable #3 (changes to DMARC base spec + DMARC Usage Guide
Component: dmarc-bis Version:
Severity: - Keywords:


To: dmarc@…
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.

Change History (7)

comment:1 Changed 3 years ago by seth@…

  • Component set to dmarc-bis

comment:2 Changed 23 months ago by todd.herr@…

  • Owner set to todd.herr@…
  • Status changed from new to assigned

comment:3 Changed 23 months ago by todd.herr@…

  • Status changed from assigned to started

comment:4 Changed 22 months ago by johnl@…

  • Resolution set to out-of-scope
  • Status changed from started to closed

Nothing to fix. changes to SPF even if they were a good idea, are way out of scope.

comment:5 Changed 20 months ago by todd.herr@…

  • Resolution out-of-scope deleted
  • Status changed from closed to new

comment:6 Changed 20 months ago by todd.herr@…

  • Status changed from new to assigned

comment:7 Changed 20 months ago by todd.herr@…

  • Status changed from assigned to infoneeded
Note: See TracTickets for help on using tickets.