I think I can make everybody happy with this.
Before, an SMTP+SPF receiver would only look at the HELO argument if the
return-path was blank. Now, SMTP+SPF receivers MAY look at the HELO
argument all the time, and use it as the source of the
<responsible-sender>; if the HELO check returns a FAIL, the entire SPF
result is a FAIL and the SMTP receiver does not have to check the
return-path. Otherwise, use the MAIL FROM return-path as the source of
the <responsible-sender> and proceed as usual.
This semantic refinement allows new strictness for SPF receivers, while
remaining backward compatible with the existing publishing base and,
more importantly, with the set of folks I have in mind who want to
publihs SPF for their return-paths but have bogus HELO strings like
"WINMAILSERVER.LOCAL".
Here's the diff.
--- spf-draft-20040209.txt 2004-02-22 14:47:07.000000000 -0500
+++ spf-draft-200403.txt 2004-03-06 01:35:57.000000000 -0500
@@ -1,7 +1,7 @@
Internet Draft
Category: Experimental Mark Lentczner
draft-mengwong-spf-00.txt Meng Weng Wong, pobox.com
-Expires: July 2004 February 2004
+Expires: August 2004 March 2004
Sender Policy Framework (SPF)
A Convention to Describe Hosts Authorized to Send SMTP Traffic
@@ -184,19 +184,35 @@
for a domain. Clients MUST correctly interpret the SPF record
according to the algorithm defined here.
-2.2.1 Terms
+2.2.1 Subject of SPF testing
- This section defines important terms. They can be thought of as
- variables in an SPF client. It is crucial that they be interpreted
- correctly.
-
- It is RECOMMENDED that the <responsible-sender> be drawn from the
- envelope using this algorithm:
-
- The <responsible-sender> comes from the domain name of the "MAIL
- FROM" envelope sender. When the envelope sender has no domain, a
- client MUST use the HELO domain instead. If the HELO argument does
- not provide an FQDN, SPF processing terminates with "unknown".
+ In an SMTP transaction, an SMTP client may provide FQDNs in the HELO
+ argument and in the MAIL FROM return-path. SMTP+SPF receivers MAY
+ check the HELO argument and MUST check the return-path. A single
+ SMTP transaction may therefore trigger one or two SPF queries.
+
+ Accordingly, the <responsible-sender> may be drawn from the HELO
+ argument or from the "MAIL FROM" return-path. This document
+ sometimes refers to the <responsible-sender> as the "envelope
+ sender".
+
+ It is RECOMMENDED that SMTP+SPF receivers perform tests using the
+ following algorithm.
+
+ SMTP+SPF receivers MAY check the HELO argument. In this mode, the
+ <responsible-sender> comes from the HELO argument IF the HELO
+ argument is a fully qualified domain name. If the HELO argument
+ is not an FQDN, there is nothing to check and the result is
+ "unknown". If the HELO test returns a "fail", the overall result
+ for the envelope is "fail", and there is no need to test the
+ return-path.
+
+ SMTP+SPF receivers MUST check the return-path unless HELO testing
+ produced a "fail". In this mode, the <responsible-sender> comes
+ from the domain name of the "MAIL FROM" return-path. When the
+ return-path has no domain, a client MUST use the HELO domain
+ instead. If the HELO argument does not provide an FQDN, SPF
+ processing terminates with "unknown".
If SPF processing occurs after SMTP time, the envelope sender may
be obtained from the Return-Path header. If the Return-Path header
@@ -204,6 +220,9 @@
Received headers. If the headers do not yield useful envelope
information, SPF processing terminates with "unknown".
+ SMTP+SPF receivers MAY test the domain given in the HELO argument
+ whether or not the return-path contains a domain name.
+
However, the <responsible-sender> address MAY be drawn from an
alternative source. For example, an MUA may find it more convenient
to extract the <responsible-sender> from the Return-Path header or
@@ -239,6 +258,8 @@
record is found for "workstation.example.com", clients MUST NOT
proceed automatically to query "example.com".
+ *** TODO: introduce the match_subdomains=1 modifier
+
3. SPF Record Evaluation
@@ -562,6 +583,7 @@
if the sending-host_IP is one of the IP_addresses {
validated_sending-host_names += name;
} }
+
Check all validated hostnames to see if they end in the <target-name>
domain. If any do, this mechanism matches. If no validated hostname
can be found, or if none of the validated hostnames end in the
@@ -957,8 +979,10 @@
Splitting characters MUST be non-alphanumeric. Parts are always
rejoined using "." and not the original splitting characters.
- For the "l" and "s" macros: when the local-part has no length, the
- string "postmaster" is substituted.
+ For the "l" and "s" macros: when the local-part is not defined, the
+ string "postmaster" is substituted. The local-part might be
+ undefined if the <current-domain> is drawn from the HELO command
+ rather than the MAIL FROM.
The "p" macro expands to the validated domain name of the SMTP
client. The validation procedure is described in section 5.4. If
@@ -1070,37 +1094,38 @@
foo.example.com IN TXT "v=spf1 ..."
A domain also SHOULD publish policy records for each of its
- designated servers to accommodate the MAIL FROM: <>.
+ designated servers.
8.3 Conformance with regard to sending e-mail systems
To be considered SPF-conformant, an SMTP sending host MUST resolve a
- "pass" for all the SPF-conformant domains for which it sends mail.
+ "pass" for all the SPF-conformant domains which appear in the "MAIL
+ FROM" command.
- When an SMTP host sends a message delivery status notification
- message, it MAY use the null envelope sender:
- MAIL FROM: <>
+ An SMTP sending host MUST also resolve a "pass" for all the
+ SPF-conformant domains which appear in the "HELO" or "EHLO" command.
- The sender host's HELO/EHLO command string MUST include the Fully
- Qualified Domain Name of the sender host, and an SPF record MUST
- exist for that FQDN for the host to be considered SPF-conformant.
+ If the domains used in MAIL FROM and in HELO/EHLO do not publish SPF
+ information, an SMTP sending host is considered conformant by
+ default. Only when those domains do publish SPF is the SMTP sending
+ host required to resolve a "pass".
- For example: in a transaction with
+ For example: in a transaction where host mx01 emits:
HELO mx01.example.com
- MAIL FROM: <>
+ MAIL FROM:<strongbad(_at_)example(_dot_)com>
- an SMTP+SPF receiver will perform an SPF query of the form
+ An SMTP+SPF receiver will attempt to find an SPF record at
- mx01.example.com TXT
+ example.com TXT
- and expect a result such as
+ An SMTP+SPF receiver may also attempt to find an SPF record at
- "v=spf1 ptr:example.com -all"
- or
- "v=spf1 a -all"
+ mx01.example.com TXT
+ If either query returns an SPF record, host mx01 MUST return a
+ "pass" for that SPF test.
8.4 Conformance with regard to receiving e-mail systems
@@ -1117,6 +1142,9 @@
recorded in the Return-Path header) versus the message headers (as
recorded in Sender or From), the envelope is recommended.
+ If the domain passed in the HELO command is a fully-qualified domain
+ name, an SPF-conformant receiver MAY test that domain name.
+
Receiver systems SHOULD exclude special recipients such as
postmaster@ and abuse@ from SPF processing. See RFC2142.
@@ -1153,6 +1181,11 @@
Mail from a domain SHOULD NOT be automatically treated as suspect
just because the domain doesn't publish SPF records.
+ If SPF tests return an explicit "fail" result during processing, the
+ receiver domain MAY reject, label, or classify the message as it
+ wishes. If the message is rejected, the receiver domain SHOULD
+ provide the "exp" string specified in section 5.2.
+
8.8 Rejection of SPF conformant email
An SPF email system MAY choose to reject or discard email on the