Professional Documents
Culture Documents
<%attr>
autohandler_skip => 1
</%attr>
Internet Draft
Category: Experimental Mark Lentczner
draft-mengwong-spf-01.txt Meng Weng Wong, pobox.com
Expires: September 2004 May 2004
Abstract
Table of Contents
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 2 of 37
1. Introduction
1.1 Terminology
1.2 Designated Senders
2. SPF Records
2.1 Publishing
2.2 Interpretation
2.2.1 Subject of SPF testing
2.2.2 Lookup
3. SPF Record Evaluation
3.1 Matching Version
3.2 SPF Directive Evaluation
3.3 Default result
4. Mechanism Definitions
4.1 "all"
4.2 "include"
4.3 Introducing Designated Sender Mechanisms
4.4 "a"
4.5 "mx"
4.6 "ptr"
4.7 "ip4" and "ip6"
4.8 "exists"
5. Modifier Definitions
5.1 redirect: Redirected Query
5.2 exp: Explanation
5.3 accredit: Sender Accreditation
6. Miscellaneous
6.1 Unrecognized Mechanisms and Modifiers
6.2 Processing Limits
6.3 The Received-SPF header
7. Macros
7.1 Macro definitions
7.2 Expansion Examples
8. Conformance Definitions
8.1 Introduction
8.2 Conformance with regard to sender domains
8.3 Conformance with regard to sending e-mail systems
8.4 Conformance with regard to receiving e-mail systems
8.5 Conformance with regard to a particular SMTP transaction
8.6 Conformance with regard to an email-sending user
8.7 Rejection of non-SPF conformant email
8.8 Rejection of SPF conformant email
8.9 Recommendations
8.10 Changes to Existing Semantics
8.10.1 The Return-Path is now also a Responsible Sender
9. Applicability Statement
9.1 Adoption by disreputable domains
9.2 Limitations
9.3 Phased Rollout
9.4 Verbatim Forwarding
9.5 Per-user exemptions
10. Security Considerations
11. IANA Considerations
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 3 of 37
1. Introduction
SPF publishes policy data in the DNS. DNS resolvers can cache SPF
data. Caching reduces lookup traffic. Sender domains do not have to
run new servers to advertise SPF information.
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 4 of 37
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119].
An SMTP client sends mail to an SMTP server. The SMTP server and
downstream systems comprise the SMTP receiver. The SMTP receiver
acts as an SPF client to an SPF publisher domain.
SPF processing may occur as early as the MAIL FROM stage of an SMTP
transaction or as late as the display stage in a Mail-User Agent.
For convenience, SMTP servers which accept, classify, discard, or
reject mail on the basis of SPF tests may be said to be speaking
"SMTP+SPF".
2. SPF Records
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 5 of 37
2.1 Publishing
The SPF record is published in the DNS. The record is of type TXT.
The record is placed in the DNS tree at the level of the domain.
A domain MUST NOT return multiple records that begin with the
version "v=spf1". If more than one "v=spf1" record is returned,
this constitutes a syntax error and the result is "unknown".
2.2 Interpretation
SPF clients are applications that parse and interpret the SPF record
for a domain. Clients MUST correctly interpret the SPF record
according to the canonical algorithm defined here.
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 6 of 37
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.
If SPF processing occurs after SMTP time, the envelope sender may
be obtained from the Return-Path header. If the Return-Path header
has no domain, a client MAY try to extract the HELO domain from the
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.
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 7 of 37
2.2.2 Lookup
Any number of records may be returned. Only the record which begins
with the version "v=spf1" is relevant to this document. CNAME
responses are followed as usual.
If the domain does not exist (NXDOMAIN), SPF clients MUST return
"unknown".
If a domain has no SPF record, clients MAY substitute SPF data from
a parent domain ONLY IF the appropriate parent domain's SPF record
sets "match_subdomains=yes". For example, if no SPF record is
Neutral (?): The SPF client MUST proceed as if a domain did not
publish SPF data. This result occurs if the domain explicitly
specifies a "?" value, or if processing "falls off the end" of
the SPF record.
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 8 of 37
There are two error conditions, one temporary and one permanent.
SPF clients MUST use only the records of the highest understood
version published by a domain and ignore all lower versions, unless
that version explicitly recognizes lower versioned responses.
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 9 of 37
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 10 of 37
Note that SPF records SHOULD always either use a redirect modifier or
an "all" mechanism to explicitly terminate processing.
For example:
4. Mechanism Definitions
- all
- include
- a - ip4
- mx - ip6
- ptr - exists
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 11 of 37
4.1 "all"
all = "all"
For example:
v=spf1 +mx +a -all
4.2 "include"
For example, a vanity domain "example.net" might send mail using the
servers of administratively independent domains example.com and
example.org.
That would direct an SPF client to, in effect, search the SPF records
for example.com and example.org for a "pass" result. Only if the
message were not permitted for either of those domains would the
result be "fail".
This mechanism matches when the inner, included query result returns
a pass, and doesn't match when the result is fail, softfail, or
neutral. However, if the new query returns none, error, or unknown,
then processing of the entire SPF query stops immediately and
returns the error result.
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 12 of 37
included include
query mechanism SPF
result result processing
-------- -- -------------- -------------------------------------
pass => match, return the prefix value for "include"
fail => no match, continue processing
softfail => no match, continue processing
neutral => no match, continue processing
error => throw error, abort processing, return error
unknown => throw unknown, abort processing, return unknown
none => throw unknown, abort processing, return unknown
If the parent domain includes another domain, and that domain one day
loses its SPF record, it is better for the query to abort with
"unknown" than to continue on to a potential "-all".
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 13 of 37
If the SMTP connection is IPv6, read "AAAA lookup" for "A lookup",
except where "A" lookups are explicitly specified.
4.4 "a"
4.5 "mx"
4.6 "ptr"
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 14 of 37
sending-host_names := ptr_lookup(sending-host_IP);
for each name in (sending-host_names) {
IP_addresses := a_lookup(name);
if the sending-host_IP is one of the IP_addresses {
validated_sending-host_names += name;
} }
Pseudocode:
for each name in (validated_sending-host_names) {
if name ends in <domain-spec>, return match.
if name is <domain-spec>, return match.
}
return no-match.
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 15 of 37
4.8 "exists"
5. Modifier Definitions
Only two standard modifiers are defined: "redirect" and "exp". SPF
clients MUST support them both.
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 16 of 37
Note that the newly queried domain may itself specify redirect
processing.
Only one redirect modifier may appear per SPF record. The modifier
does not have to appear at the end; it MAY appear anywhere in the
record. However, for clarity it is RECOMMENDED that redirect
modifiers appear after mechanisms.
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 17 of 37
When an SPF client performs a query, and the result is anything other
than pass, then the explanation string, if present, SHOULD be
presented to the SMTP client after macro expansion. See section 7.
See http://%{d}/why.html?s=%{S}&i=%{I}&h=%{H}
-- a complicated example that constructs a URL with
-- most of the parameters of the failed message so that
-- a web page can be generated with instructions
For example,
accredit=%{d}.accreditation-provider.example.com
accredit=%{ir}.accreditation-provider.example.com
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 18 of 37
6. Miscellaneous
messages that match the "a", "mx", or "ptr" mechanisms would return a
"pass" result. An SPF client that did not recognize the mechanism
"domainkeys" would return "unknown". An SPF client that was
domainkeys-aware would be able to perform extended evaluation. If
the message matched the domainkeys test, it would pass; if it did
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 19 of 37
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 20 of 37
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 21 of 37
Other key-value pairs may be defined by SPF clients. Until a new key
name becomes widely accepted, new key names should start with "x-".
7. Macros
l = local-part of responsible-sender
s = responsible-sender
o = responsible-domain
d = current-domain
i = SMTP client IP (nibble format when an IPv6 address)
p = SMTP client domain name
v = client IP version string: "in-addr" for ipv4 or "ip6" for ipv6
h = HELO/EHLO domain
r = receiving domain
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 22 of 37
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.
For IPv4 addresses, both the "i" and "c" macros expand to the
standard dotted-quad format.
Use of the "t" macro in DNS lookups would greatly reduce the
effectiveness of DNS caching. The "t" macro is only allowed in
explanation records. The value of the "t" macro SHOULD NOT change
during the evaluation of a given SPF record.
The "p" macro expands to the validated domain name of the SMTP
client. The validation procedure is described in section 4.6. If
there are no validated domain names, the word "unknown" is
substituted. If multiple validated domain names exist, the first one
returned in the PTR result is chosen.
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 23 of 37
The "r" macro expands to the name of the receiving MTA. This SHOULD
be a fully qualified domain name, but if one does not exist (as when
the checking is done by a script) or if policy restrictions dictate
otherwise, the word "unknown" SHOULD be substituted. The domain
name MAY be different than the name found in the MX record that the
client MTA used to locate the receiving MTA.
macro expansion
-------------------------------
%{s} strong-bad@email.example.com
%{o} email.example.com
%{d} email.example.com
%{d4} email.example.com
%{d3} email.example.com
%{d2} example.com
%{d1} com
%{p} mx.example.org
%{p2} example.org
%{dr} com.example.email
%{d2r} example.email
%{l} strong-bad
%{l-} strong.bad
%{lr} strong-bad
%{lr-} bad.strong
%{l1r-} strong
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 24 of 37
macro-string expansion
---------------------------------------------------------------------
%{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com
%{lr-}.lp._spf.%{d2} bad.strong.lp._spf.example.com
%{lr-}.lp.%{ir}.%{v}._spf.%{d2}
bad.strong.lp.3.2.0.192.in-addr._spf.example.com
%{ir}.%{v}.%{l1r-}.lp._spf.%{d2}
3.2.0.192.in-addr.strong.lp._spf.example.com
%{p2}.trusted-domains.example.net
example.org.trusted-domains.example.net
IPv6:
%{ir}.example.org 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.
5.d.a.0.8.0.0.0.2.5.0.f.5.example.org
8. Conformance Definitions
8.1 Introduction
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 25 of 37
FROM" command.
An SMTP sending host MUST also resolve a "pass" for all the
SPF-conformant domains which appear in the "HELO" or "EHLO" command.
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".
HELO mx01.example.com
MAIL FROM:<strongbad@example.com>
example.com TXT
mx01.example.com TXT
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 26 of 37
8.9 Recommendations
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 27 of 37
From [RFC2821]:
The <reverse-path> portion of the first or only argument contains
the source mailbox (between "<" and ">" brackets), which can be
used to report errors (see section 4.2 for a discussion of error
reporting).
9. Applicability Statement
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 28 of 37
9.2 Limitations
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 29 of 37
The "exists" mechanism can be used to exempt certain users from the
SPF requirements that apply to the rest of the domain.
SPF owes a debt of parentage to RMX (by Hadmut Danisch in 2003) and to
DMP (by Gordon Fecyk in 2003). It traces its ancestry farther back
through "Repudiating Mail-From" by Paul Vixie in 2002 to a suggestion
by Jim Miller in 1998.
The authors would also like to thank the following individuals who
contributed to, critically reviewed, or otherwise furthered the
development of this specification. The authors wish to apologize in
advance for any omissions.
Jameel Akari, Marc Alaia, Dave Alden, Tom Allison, Eric Allman,
Justo Alonso, Mark Anderson, Matthias Andree, Don Andrews,
Mohammad Arca, Aredridel, William Astle, Bob Atkinson, Roy Badami,
Andy Bakun, Derek J. Balling, Arik Baratz, Graham Barr, Matthew
Barr, Ernesto Baschny, Mike Batchelor, Peter Baumann, Steven
Bellovin, Jon Bertrand, Paul Blair, Andrew Boling, Richard
Bollinger, Dan Boresjo, Nicolas Bougues, Daniel Bourque, Jeremy
T. Bouse, Raymond S Brand, Seth Breidbart, David Brodbeck, Neil
Brown, Zack Brown, Michael R. Brumm, Jason Buchanan, Jasmin
Buchert, Ted Cabeen, Dave Camp, Anthony Campbell, Bryan Campbell,
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 30 of 37
Brian Candler, John Capo, Dennis Carr, L. Carver, Lee Carver, Ian
Castle, Jose Celestino, Christopher Chan, Jason Chen, Joe Christy,
Andrew Church, Greg Cirino, Bradley Cloete, James H. Cloos Jr.,
Bill Cole, Brian Coloney, Sean Comeau, Greg Connor, Erik Corry, Dj
Coster, James Couzens, Chris Cowherd, Dave Crocker, Arlie Davis,
Alan DeKok, Mark Delany, Kitt Diebold, Mark Jason Dominus, Andrew
W. Donoho, William H. Dorell, Jeremy Doupe, Lilia Downs, Chris
Drake, Jesus Duarte, Viktor Duchovni, Lars B. Dybdahl, David
Dyer-Bennet, Lyndon Eaton, Henrik Edlund, William Elan, Matthew
Elvey, Stefan Engelbert, Shaun T. Erickson, Ray Everett-Church,
Mark Farver, Nick Fields, Guillaume Filion, Tony Finch, Cary
Fitch, Gustav Foseid, Mark Foster, Steven Foster, Benjamin Franz,
Tim Freeman, Tugrul Galatali, Stuart D. Gathman, Fotis Georgatos,
Richard George, Oliver Gerler, Dean Gibson, B. Gingery, Eric
Girard, Tim Gladding, Philip Gladstone, Etta Good, Seth Goodman,
Gabriel Granger, Ben Greear, Bob Greene, Ronald F. Guilmette,
Phillip Hallam-Baker, Clifford Hammerschmidt, Catherine Hampton,
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 31 of 37
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 32 of 37
This section is normative and any discrepancies with the ABNF fragments
in the preceding text are to be resolved in favor of this grammar.
all = "all"
include = "include" ":" domain-spec
A = "a" [ ":" domain-spec ] [ dual-cidr-length ]
MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
PTR = "ptr" [ ":" domain-spec ]
IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
exists = "exists" ":" domain-spec
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 33 of 37
$ORIGIN example.com.
@ MX 10 mail-a
MX 20 mail-b
A 192.168.1.10
A 192.168.1.11
amy A 192.168.1.65
bob A 192.168.1.66
mail-a A 192.168.1.129
mail-b A 192.168.1.130
www CNAME example.com.
$ORIGIN 1.168.192.in-addr.arpa.
10 PTR example.com.
11 PTR example.com.
65 PTR amy.example.com.
66 PTR bob.example.com.
129 PTR mail-a.example.com.
130 PTR mail-b.example.com.
; A related domain
$ORIGIN example.org
@ MX 10 mail-c
mail-c A 192.168.2.140
$ORIGIN 2.168.192.in-addr.arpa.
140 PTR mail-c.example.org.
$ORIGIN 0.0.10.in-addr.arpa.
4 PTR bob.example.com.
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 34 of 37
"v=spf1 +all"
-- any mail message passes
"v=spf1 a -all"
-- sending hosts 192.168.1.10 and 192.168.1.11 pass
"v=spf1 mx -all"
-- sending hosts 192.168.1.129 and 192.168.1.130 pass
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 35 of 37
This SPF record would be used if mail from example.org actually came
through servers at example.com and example.net. Example.org's
designated servers are the union of example.com and example.net's
designated servers.
These SPF records allow a set of domains that all use the same
mail system to make use of that mail system's SPF record. In this
way, only the mail system's SPF record needs to updated when
the mail setup changes. These domains' SPF records never have to
change.
$Origin _spf.example.com.
mary.mobile-users A 127.0.0.2
fred.mobile-users A 127.0.0.2
15.15.168.192.joel.remote-users A 127.0.0.2
16.15.168.192.joel.remote-users A 127.0.0.2
example.com:
"v=spf1 mx
include:mobile-users._spf.%{d}
include:remote-users._spf.%{d} -all"
mobile-users._spf.example.com:
"v=spf1 exists:%{l1r+}.%{d}"
remote-users._spf.example.com:
"v=spf1 exists:%{ir}.%{l1r+}.%{d}"
Normative References
[RFC2396]
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 36 of 37
Informative References
[RFC1034]
[RFC1464]
[RFC2119]
[RFC2142]
[RFC2234]
[RFC2373]
[RFC2505]
[RFC2821]
[RFC2822]
Danisch, Hadmut.
"The RMX DNS RR Type for light weight sender authentication",
http://www.danisch.de/work/security/antispam.html, October 2003,
Work In Progress.
http://nospam.couchpotato.net/
http://asrg.sp.am/
http://www.ietf.org/html.charters/marid-charter.html
Authors
Mark Lentczner
1209 Villa Street
Mountain View, CA 94041
United States of America
markl@glyphic.com
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010
Page 37 of 37
http://old.openspf.org/draft-mengwong-spf-01.txt 3/29/2010