On Fri, Oct 17, 2003 at 03:33:22AM -0400, Eric S. Raymond wrote:
| Section 2.4.3 needs to specify that "ends with" means the name has to some
| trailing set of segments, otherise some dimbulb is going to implement
| it so that qux.bar.com matches qux.foobar.com
fixed. thanks. this is almost complete.
Internet Draft
Category: Experimental Meng Weng Wong
draft-mengwong-spf-02.txt IC Group, Inc.
Expires: December 2003 October 2003
Sender Permitted From
A Convention to Identify Hosts Authorized to Send SMTP Traffic
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. It combines a technical specification
with an applicability statement.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This draft was produced by members of the ASRG (a research group of
the IRTF) and circulated for review within the ASRG.
Abstract
SPF proposes a convention for a domain to designate, using the DNS,
the set of hosts which could be expected to originate email
purporting to be from that domain. This designation enables
receivers of email to detect forgery and apply local policies with
greater confidence. For example, a receiver may wish to accept mail
purportedly from a domain only if it does in fact originate from that
domain's designated hosts. Lookups can be performed while an SMTP
transaction is ongoing, before DATA is transmitted. Mechanisms exist
to exclude individual addresses from consideration. This proposal is
fully backward-compatible with regular SMTP: a conformant MTA will
continue to receive mail from nonconformant domains.
Conventions used in this document
Example domains used in this document include example.net,
example.com, and example.org.
SPF is variously referred to as a scheme, a protocol, a convention,
and a system for designating mailers. These terms should be
considered roughly synonymous.
SPF can be seen as an extension to SMTP. SMTP servers which adopt
SPF may be colloquially referred to as speaking "SMTP+SPF".
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 RFC 2119 [1].
Table of Contents
1. Introduction
SMTP allows any client host to assert any sender email address. Over
time this policy has been exploited; today, some consider it a
significant security flaw. The Sender Permitted From protocol (SPF)
introduces a voluntary convention to address this vulnerability.
The SPF proposal defines mechanisms for domain owners to designate
legitimate outbound mail servers. Using these mechanisms, SMTP
servers may query the envelope sender domains about the validity of a
given SMTP transaction while that transaction is ongoing, even before
any message data is passed. SMTP servers and Mail Delivery Agents
may choose to accept, classify, discard, or reject messages according
to the result of that query.
This verification scheme is weaker than cryptographic systems but
stronger than the current SMTP model. This RFC does not obsolete
RFC2821. It is a voluntary extension fully backward-compatible with
the SMTP protocol.
The intended audience for this document includes DNS administrators
and developers of Mail Transfer Agents (MTAs) and Mail Delivery
Agents (MDAs). They are assumed to be familiar with the workings of
SMTP and DNS. See RFC2821 and RFC1034.
2. Designating SMTP Clients
Participating domains publish SPF records to indicate that only
certain hosts are permitted to claim they are sending mail from that
domain.
When this document says a domain has "designated" a host, that
domain name has permitted that host to use the domain's name when
sending mail. The scope of that permission may vary according to
the domain's stated policies, which could specify one or more of the
envelope sender address, the HELO/EHLO command, the header From:
address, or the header Errors-To: address.
Individual users can specify different policies.
2.1 The _smtp_client subdomain.
Domains create TXT and A records in a special subdomain called
"_smtp_client".
This subdomain is hereby reserved for domains to publish SMTP
policies which they request mail receivers to respect.
Domains participating in SPF are REQUIRED to respond to certain TXT
queries in that subdomain. Note that the TXT record may be
obsoleted in the future by a new DNS Resource Record Type. If that
time comes, domain administrators MUST be prepared to upgrade.
2.2 The policy label
Domains wishing to describe themselves as SPF-compliant MUST
publish the following record:
${DOMAIN} IN TXT "directive-set"
"directive-set" obeys the following ABNF syntax:
directive-set = 'v=spf1' *Mechanism [ SP 'scope=' Scopes ]
Default [ Explanation ]
Default = SP 'default=' ( 'unknown' / 'allow'
/ 'deny' / 'softdeny' )
Scopes = Scope [ ',' Scopes ]
Scope = [ 'envelope' / 'header-from' / 'errors-to' ]
Explanation = 'exp=' *( VCHAR / SP )
; the explanation string is subject to macro
; interpolation.
Mechanism = SP [mechanism-prefix ]
( MX / A / PTR / PI / IP4 / IP6 / Include
/ LocalPart / Extension )
MX = 'mx' [ ':' domain ]
A = 'a' [ ':' domain ]
PTR = 'ptr' [ ':' domain ]
PI = 'pi' [ ':' dot-domain ]
Include = 'include' ':' domain
LocalPart = 'localpart' ':' [ localpart-mechanism ]
mechanism-prefix = ( "+" / "-" / "!" / "?" )
; this corresponds to the shorthands
; defined in section 2.3.2.
Extension = *VCHAR ; non-whitespace string that is
; clearly distinct from other directives.
domain = standard DNS domain name, eg. as defined in RFC1034
dot-domain = ( '.' ) <domain>
IP4 = 'ip4' ':' ip4-cidr
IP6 = 'ip6' ':' ip6-cidr
ip4-cidr = < ipv4-address-prefix > ; eg. "127.0.0.1/8"
ip6-cidr = < ipv6-address-prefix >
; as in RFC2373, eg. 12AB:0:0:CD30::/60
localpart-mechanism is defined in section 3.5.1.
2.2.1 Examples
The following examples illustrate the above definition.
"v=spf1 default=deny"
"v=spf1 mx default=deny"
"v=spf1 a mx ptr pi default=deny exp=This is a test of SPF"
"v=spf1 a:example.com mx:example.org ptr:example.net
pi:.example.com scope=envelope,header-from
default=deny exp=This is a test of SPF"
2.3 Modifiers
Modifiers use an = sign as the separator. Modifiers MUST NOT appear
multiple times: for example, "default=deny default=softdeny" is an
invalid construct.
------------------------------------------------------------------------
2.3.1 Scope
------------------------------------------------------------------------
By default, envelope scope is assumed. In envelope scope, the
sender domain used for lookups is taken from the envelope sender
domain, or from the HELO/EHLO where the envelope sender has no
domain. If other scopes are specified, an SPF client SHOULD
perform tests using the indicated scopes.
In practice, an SPF client would have first tested message header
address domains on its own initiative, and subsequently discovered
that the domains in question did desire protection for the message
headers. SPF clients are NOT REQUIRED to test message headers when
a domain can be found in the envelope (HELO/EHLO/MAIL). When a
domain cannot be found in the envelope, SPF clients SHOULD check the
message headers. (If this poses insurmountable implementation
difficulties, SPF clients MAY forgo checking the message headers.)
We define the <current-domain> as the domain name being investigated
by SPF:
- if a domain is present in the envelope sender,
it is the envelope sender domain;
- otherwise, if a domain is present in the HELO/EHLO command,
it is the HELO/EHLO domain;
- otherwise, SPF clients, not being able to discover a domain
in the envelope, MAY abort and return unknown,
- or they may proceed to parse the message headers for the
header-from and errors-to addresses, in which case the domains
found there would become the <current-domain>.
The <current-address> is similarly defined: it is the <current-domain>
prefixed by the local-part in the manner of an email address.
------------------------------------------------------------------------
2.3.2 Result Values and the Default Modifer
------------------------------------------------------------------------
"Unknown" means MTAs SHOULD proceed as if the sender domain did not
publish SPF data. The shorthand for "unknown" is "?".
"Softdeny" means MTAs SHOULD reject the message using a 450 transient
failure reply code. The shorthand for "softdeny" is "-".
"Deny" means MTAs SHOULD reject the message using a 550 permanent
failure reply code. (See RFC2821 section 7.1) The shorthand for
"deny" is "!".
"Allow" indicates that the sender domain has validated the SMTP
client, and accepts a certain (possibly minimal) responsibility for
originating or relaying the message. The shorthand for "allow" is
"+".
If none of the mechanisms provide an explicit "deny", "softdeny", or
"allow" result, the value of the "Default" modifier is used.
2.3.2.1 Examples
"v=spf1 default=deny" "v=spf1 default=!"
"v=spf1 default=softdeny" "v=spf1 default=-"
"v=spf1 default=unknown" "v=spf1 default=?"
"v=spf1 default=allow" "v=spf1 default=+"
------------------------------------------------------------------------
2.3.3 Explanation
------------------------------------------------------------------------
Provides a space for the publishing domain to communicate further
information about its policy: for instance, a short message, or a
URL pointing to a longer message. SPF clients SHOULD convey this
message to the SMTP client when rejecting; if they cannot pass the
whole thing, they SHOULD convey at least the first 128 bytes of the
explanation.
The explanation SHOULD be macro-interpolated according to the
following convention:
%% = a literal "%"
%u = local-part of current-address
%s = current-address
%d = current-domain
%t = current timestamp in YYYYMMDD-HHMMSS notation
%h = HELO/EHLO string provided
%i = SMTP client IP
The uppercase versions of those macros are to be URL-encoded.
A % sign not followed by a recognized macro character MUST be
interpreted as a literal.
The explanation string is OPTIONAL. If it is omitted, SPF clients
may use their discretion in constructing an appropriate string.
2.3.3.1 Simple Example
"v=spf1 default=! exp=Sender domain does not originate mail."
2.3.3.2 Example with macro interpolation
"v=spf1 default=! exp=%d does not originate mail."
2.3.3.2 Example with URL-encoded macro interpolation
"v=spf1 default=! exp=See http://%d/badmail?s=%S&i=%I&h=%H";
If the <current-address> were foo+bar(_at_)example(_dot_)com
the explanation would be expanded by the SPF client into
"See http://example.com/badmail?s=foo%2Bbar%40example.com
&i=192.0.2.1&h=fake.example.com"
See RFC1738 regarding URL encoding.
------------------------------------------------------------------------
2.3.4 The version directive
------------------------------------------------------------------------
Consider this scenario. If an SPF client runs across a mechanism it
is unable to execute, should it:
1) bail out immediately and return unknown?
2) pretend the mechanism didn't exist and eventually respect the
default directive?
3) pretend it didn't exist, but continue processing, and
convert the default result to unknown?
In the absence of a version string, this scenario has the potential
for undefined and undesired behaviour.
If an SPF client sees a v=spf1 label, and then sees a mechanism
which is not defined by the spf1 specification and which it does not
implement, it SHOULD ignore it and SHOULD continue to respect the
default label.
This provides a means for organizations to define optional
extensions without confusion.
By default, spf clients MUST use the highest understood version
published by a domain and ignore all lower versions, unless a higher
version explicitly defines the use of lower-versioned responses.
------------------------------------------------------------------------
3 Mechanisms In Detail
------------------------------------------------------------------------
Mechanisms may be modified by a mechanism-prefix. A mechanism that
matches may cause the SPF lookup to return the value indicated
by its prefix, unless the value is "unknown", in which case
processing continues as though the mechanism had not matched.
Example:
"v=spf1 -a:softdeny.example.com ?a:unknown.example.com default=deny"
If the A lookup against softdeny.example.com results in a match,
the result of the SPF lookup is "softdeny".
In the absence of a mechanism prefix, the value returned is
dependent on the default value.
If "default=deny", mechanisms default to "allow".
If "default=softdeny", mechanisms default to "allow".
If "default=unknown", mechanisms default to "allow".
If "default=allow", mechanisms default to "deny".
Mechanisms that cause further lookup, such as <Include> and LocalPart,
return the innermost value; any explicitly specified prefix is ignored.
Mechanisms MUST be evaluated in the order they are presented.
A response of "allow", "deny", or "softdeny" short-circuits evaluation.
------------------------------------------------------------------------
3.1 MX
------------------------------------------------------------------------
Valid syntax:
- mx
- mx:example.com
If a host is an MX server for example.com, it is also designated to
send mail on behalf of example.com; this mechanism then returns "allow".
SPF clients perform an MX lookup on the provided domain. If no
domain is provided the <current-domain> is used. For each hostname
returned by the MX lookup, proceeding in order of priority, SPF
clients look up the A record for the hostname. If any of the IP
addresses returned by the lookup matches the client IP, this
mechanism matches.
3.1.1 Simple Example
"v=spf1 mx default=deny"
If the <current-domain> is example.com, the MX servers for example.com
are resolved.
3.1.2 Example with domain provided
"v=spf1 mx:example.org default=deny"
The MX servers for example.org are resolved instead of example.com.
3.1.2 Multiple MX mechanisms
"v=spf1 mx mx:example.org default=deny"
The MX servers for both example.com and example.org are resolved.
------------------------------------------------------------------------
3.2 A
------------------------------------------------------------------------
Valid syntax:
- a
- a:example.com
SPF clients perform an A lookup on the provided domain. (If the
connection is IPv6, clients perform an AAAA lookup.) If any of the
addresses returned by the lookup matches the client IP, this
mechanism matches.
3.2.1 Simple Example
"v=spf1 a default=deny exp=This is a test of SPF"
Given <current-domain> "example.com", an A lookup might return
192.0.2.1, 192.0.2.2, and 192.0.2.3. If the client IP is 192.0.2.2,
the mechanism matches. If the client IP is not one of those three,
the mechanism does not match.
3.2.2 Explicit Example
"v=spf1 a:example.org default=deny exp=This is a test of SPF"
An A lookup of example.org might return 192.0.2.1, 192.0.2.2, and
192.0.2.3. If the client IP is 192.0.2.10, the mechanism does not
match.
------------------------------------------------------------------------
3.3 PTR
------------------------------------------------------------------------
Valid syntax:
- ptr
- ptr:example.com
Unlike the other mechanisms, this does not trigger a PTR lookup on the
provided domain.
First, perform a PTR lookup on the connecting client IP; this should
produce one or more hostnames.
For each hostname, perform an A lookup. This should produce one or
more IP addresses. Discard any hostnames whose IP addresses do not
match the original client IP.
If any of the remaining hostnames ends in the specified domain-name,
this mechanism matches.
"Ending" means the matching hostname and the specified domain-name
must share a "."-level boundary. If a hostname is
"qux.1-example.com" and the specified domain-name is "example.com",
there is no match. There is a match if the hostname is
"qux.example.com". There is also a match if the hostname is simply
"example.com".
3.3.1 Example
"v=spf1 ptr default=deny"
Let the <current-domain> be example.com.
Let the SMTP client come from the IP address 192.0.2.1.
PTR(192.0.2.1) returns two names: foo.example.net and bar.example.com
A(foo.example.net) returns two results: 192.0.2.100 and 192.0.2.101.
This is an invalid result because neither A record matches the
original IP.
A(bar.example.com) returns two results: 192.0.2.1 and 192.0.2.2.
This is a valid result because the A record does point back to the
original IP.
bar.example.com does end in example.com; therefore this mechanism
returns a match.
------------------------------------------------------------------------
3.4 PI
------------------------------------------------------------------------
"PI" stands for "reversed IP", after the manner of in-addr records.
Valid syntax:
- pi:example.org
- pi:.example.org
- pi
Triggers an A query of the form
${ADDRESS}.${DOMAIN}
An A response constitutes a match.
${ADDRESS} represents a reversed network IP address either in IP4
or IP6 notation.
${DOMAIN} may be expanded in a number of ways.
If a domain name is given, that domain is substituted for ${DOMAIN}.
If no domain name is given,
"${ADDR-TYPE}._smtp_client.$CURRENT_DOMAIN" is used.
If a domain is given, prefixed with a ".", the "." expands to
"${ADDR-TYPE}_smtp_client.".
"${ADDR-TYPE}" expands according to the IP version: if the client is
connecting over IPv4, it expands to "in-addr". If the client is
connecting over IPv6, it expands to "ip6".
3.4.1 Expansion Examples
Suppose the <current-domain> is example.com.
The IPv4 SMTP client IP is 192.0.2.3.
The IPv6 SMTP client IP is 5f05:2000:80ad:5800::1.
The appropriate infix is automatically selected based on the
connection type: "in-addr" for IPv4, and "ip6" for IPv6.
DIRECTIVE LOOKUP
---------------- -------------------------------------------
pi:example.org 3.2.0.192.example.org
pi:.example.org 3.2.0.192.in-addr._smtp_client.example.org
pi 3.2.0.192.in-addr._smtp_client.example.com
Under IPv6,
pi: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
pi:.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.ip6._smtp_client.example.org
pi: 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.ip6._smtp_client.example.com
3.4.2 Simple Example
In these examples we have an SMTP connection from 192.0.2.1 with the
<current-domain> example.com.
SPF label: "v=spf1 pi default=deny"
Query: 1.2.0.192.in-addr._smtp_client.example.com IN A
If 192.0.2.1 were a permitted sender for example.com, the A query
would resolve, and the mechanism would match. If it were not, no
response would be returned, and the mechanism would not match.
------------------------------------------------------------------------
3.5 LocalPart
------------------------------------------------------------------------
LocalPart = 'localpart' ':' [ localpart-mechanism ]
localpart-mechanism = 'rlp' [ '=' delimiters [ '@' dot-domain ] ]
/ *VCHAR ; non-whitespace string
delimiters = *CHAR
Valid syntax:
- LocalPart:rlp
- LocalPart:rlp=+-
- LocalPart:rlp(_at_)v?* ׶Ûóí?xn×?¾Âq:Ø¢õ?¹
- LocalPart:rlp(_at_)ù? ·Hðâ^?¿Õ40§a
- LocalPart:rlp==+-@@.example.org
- LocalPart:other
Individual users may wish to specify a policy that differs from the
rest of the domain: for example, if a roaming user wishes to send
mail from any SMTP server, he may opt out of SPF using this
mechanism.
Suppose the initial SPF <directive-set> is
"v=spf1 a mx ptr LocalPart:rlp=+- default=deny"
If any of the (a,mx,ptr) mechanisms result in a hit, the localpart
mechanism is not consulted. This is the usual short-circuiting.
If none of them get a hit, SPF clients MUST turn to the LocalPart
before defaulting to deny.
LocalPart directives may specify different <localpart-mechanisms>.
3.5.1 LocalPart sub-mechanisms: rlp
If the LocalPart argument string begins with the word "rlp", the
local-part will be resolved using the "rlp" sub-mechanism.
"rlp" stands for reversed-localpart. The RHS of the = sign, up to an
optional < '@' dot-domain >, indicates delimiters for the reversal.
If no delimiters are specified, no delimiters will be used in the
reversal. If '@' is to be a delimiter, it MUST be the last character
within the <delimiter> section.
An optional < '@' dot-domain > follows the delimiter section. If a
dot-domain is provided, lookups will use that domain instead of the
<current-domain>. If the domain is preceded by a ".", the "." will
be expanded into "lp._smtp_client".
If a dot-domain part is not provided, SPF clients shall substitute
"lp._smtp_client." <current-domain>.
SPF clients split the local-part of the <current-address> using the
delimiters, and convert them into "." marks. If this conversion
process would result in two or more "." in a row, the repeated "."
are reduced to a single ".". A leading or trailing "." is
eliminated.
The resulting local-part is then reversed using the "." delimiters as
separators. For example, if the LocalPart mechanism specifies
"rlp=+-", SPF clients would rewrite the sender bob+foo(_at_)example(_dot_)com
into this TXT query:
foo.bob.lp._smtp_client.example.com IN TXT
"lp" stands for local-part as defined by RFC2822.
The result of the TXT query should be another <directive-set>. For
example,
"v=spf1 default=allow" or
"v=spf1 a:bob-at-home.example.org default=softdeny"
SPF clients process these directives in the usual way. If a match is
found, the value of the match returns to the outermost level, and
processing terminates. If no match is found, the default value is
used. If the default value is not "unknown", processing terminates.
The <directive-set> could even include another LocalPart lookup. As
with <Include> mechanisms, SPF clients are REQUIRED to support
recursion to a depth of 6 lookups.
Examples:
LocalPart:rlp=+- bob+foo-bar(_at_)example(_dot_)com
bar.foo.bob.lp._smtp_client.example.com
LocalPart:rlp=+ bob+foo-bar(_at_)example(_dot_)com
foo-bar.bob.lp._smtp_client.example.com
LocalPart:rlp bob+foo-bar(_at_)example(_dot_)com
bob+foo-bar.lp._smtp_client.example.com
LocalPart:rlp bob(_dot_)foo(_dot_)bar(_at_)example(_dot_)com
bob.foo.bar.lp._smtp_client.example.com
LocalPart:rlp=. bob(_dot_)foo(_dot_)bar(_at_)example(_dot_)com
bar.foo.bob.lp._smtp_client.example.com
LocalPart:rlp=+ tm.o'reilly(_at_)example(_dot_)com
tm.o'reilly.lp._smtp_client.example.com
Non-alphanumeric characters MUST be preserved in the query.
See RFC2181 section 11 and RFC1123 section 6.1.3.5.
3.5.1 other LocalPart sub-mechanisms
Other sub-mechanisms MAY be defined by SPF publishers. However, SPF
version 1 clients are NOT REQUIRED to implement those mechanisms; if
they encounter an unsupported sub-mechanism, they MUST proceed as
though the unsupported LocalPart directive were not present.
------------------------------------------------------------------------
3.6 Include
------------------------------------------------------------------------
<Include> directives provide an aliasing mechanism. They point
to other domains which themselves publish SPF records.
This aliasing mechanism makes it possible to consolidate multiple
domains that share the same set of designated hosts.
"v=spf1 include:domain.org default=unknown"
<Include> directives MUST be followed in search of a match which
short-circuits the lookup. Matches with the value "Unknown" do not
cause short-circuiting.
If an <Include> directive points to a domain that does not publish
SPF, SPF clients MUST proceed as though that directive had not been
present.
------------------------------------------------------------------------
3.7 Extensions
------------------------------------------------------------------------
SPF publishers MAY specify mechanisms not defined in this proposal.
If an SPF client encounters a mechanism which is not defined in this
proposal, if it does not understand that mechanism, it MUST proceed
as though that mechanism were not present.
Extensions MUST not contain whitespace characters.
------------------------------------------------------------------------
4 The Received-SPF header.
------------------------------------------------------------------------
This proposed standard reserves the RFC2822 header "Received-SPF"
for use by the SPF protocol.
An SPF-conformant MTA SHOULD prepend the Received-SPF header to
messages, with five possible values:
pass (client localhost[192.0.2.1] is designated mailer for domain of
sender myname(_at_)example(_dot_)com)
error (temporary failure while resolving designated mailer status for
domain of sender myname(_at_)example(_dot_)com)
unknown (domain of sender myname(_at_)mexample(_dot_)com does not
designate mailers)
fail (client localhost[192.0.2.1] is not a designated mailer for
domain of sender myname(_at_)example(_dot_)com)
softfail (client localhost[192.0.2.1] is not a designated mailer for
transitioning domain of sender myname(_at_)example(_dot_)com)
The <current-address> SHOULD be used where available; if it is not,
the <current-domain> MAY be used.
The topmost Received-SPF header should always be from the nearest
and most trusted mail exchanger.
------------------------------------------------------------------------
5 Applicability Statement
------------------------------------------------------------------------
While SMTP+SPF is protocol-compatible with SMTP, potential adopters
should carefully consider certain consequences.
This section constitutes an applicability statement. It discusses
reasons for adoption, caveats, limitations, and conformance.
5.1 Naive Mail Forwarding
Mail forwarders have traditionally left the sender envelope
untouched. "Forwarding" is used in the sense of Unix user .forward
and /etc/aliases files.
A companion Technical Specification titled "Sender Rewriting
Scheme" describes a backward-compatible way for one or more
forwarding mail exchangers to rewrite the sender address to their
local domain while preserving return-path functionality.
SPF-conformant SMTP receivers SHOULD implement Sender Rewriting
Scheme or its moral equivalent. Receiver hosts MAY work around this
issue by simply modifying .forward files on a systemwide basis to
pipe messages to a local mailer, such that forwarded messages are
instead remailed: the envelope sender would thereby change to the
local user on the forwarding host.
5.2 The Traveling Mailman Problem
Domains which desire the freedom to originate mail from arbitrary IP
addresses SHOULD NOT publish SPF records; or they could publish a
simple "v=spf1 default=allow" response.
If a domain that publishes SPF records wishes to exempt certain users
from the burden of SPF compliance, it could support LocalPart lookups
described in section 3.5.
5.3 Bandwidth burden on DNS servers
If a large number N of malign hosts forge a certain domain when
sending M messages to each a total of R distinct SMTP receivers, how
many DNS queries could the forged domain expect to bear?
The first lookup is for the SPF directive-set. If each SMTP receiver
triggers a query, the forged domain might expect O(R) queries.
Subsequent queries may be triggered by the mechanisms defined in the
directive-set.
If the domain defines IP4 or IP6 mechanisms, the domain should expect
no further queries for those mechanisms.
If the domain defines A, MX, or PTR mechanisms, the domain should
expect O(KR) further queries where K represents the complexity of its
A, MX, and PTR configuration. This reduces to O(R).
If the domain defines PI mechanisms, the domain should expect O(NR)
queries.
The above analysis assumes that the messages are sent reasonably
close together in time, and that the directive-set responses remain
cached. In the absence of caching, the estimates may be multiplied
by M.
Caching by local resolvers minimizes the burden imposed by IP4, IP6,
A, MX, and PTR mechanisms. The PI mechanism benefits least from
caching.
The burden for Include and LocalPart mechanisms can be estimated
using similar reasoning.
Still, considering only bandwidth, the resources consumed by SPF are
believed to be miniscule compared to the resources imposed by forgery
in the form of bounce messages and abuse complaints.
Suppose 100 SMTP receivers receive 20 messages each. All the
messages forge the same sender domain. Each of those 2000 messages
is sent by a different malign host.
If the DNS query consumes 250 bytes, 100 * 250 = 25kB. The total DNS
burden for SPF is 25kB under caching, or 250kB without.
Without SPF, let one in ten messages be returned to sender at the
forged domain. Suppose the size of the message is 8,000 bytes.
If 1/10 * 2000 messages are returned to the forged domain,
200 * 8kB = 1600 kB of not just bandwidth but also storage.
Thus we observe that the bandwidth burden of SPF is smaller than the
bandwidth burden of handling bounce messages.
5.4 Reasons for Adoption
A domain owner may wish to restrict the set of hosts permitted to
send email that identifies itself as coming from that domain. SPF
provides a consensual mechanism for domain owners to announce that
set of hosts, and for SMTP receivers to check incoming mail against
it.
In response to RFC2821 section 7.1, forged email currently
represents a significant burden on Internet infrastructure. This
proposal suggests that the very usability of Internet email is so
threatened by unwanted and forged messages that adoption of SPF
would currently do more good than harm. See RFC1958 section 1.
5.4.1 Viruses and Worms
Some viruses forge an innocent third-party's email address when
they send mail. SPF-conformant MTAs may detect such viruses.
5.4.2 Account Fraud
Reputable institutions may wish to control the use of their brands,
and protect their domain names from fradulent use.
5.4.3 "Joe-Jobbers"
Standard SMTP allows anyone to forge any sender address. A "Joe-Job"
happens when a message is sent to many recipients with a forged
sender address; the forged sender receives a storm of replies and
bounce messages. The forged sender's ISP may also receive many
incorrect abuse reports.
SPF-conformant domains protect their users from joe-jobbing.
5.5 Limitations
In an SPF-conformant environment, envelope sender forgery is limited
to the local domain, whose administrative organization presumably has
the wherewithal to follow an audit trail.
5.6 Conformance Definitions
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".
5.6.1 Conformance with regard to DNS Domains
For conformance, authoritative DNS servers are REQUIRED to publish
SPF policy labels. Domains which do not publish SPF data or publish
only a default of "unknown" SHALL NOT be deemed SPF-conformant.
5.6.2 Conformance with regard to sending e-mail systems
To be considered SPF-conformant, an SMTP sending host MUST resolve
"allow"ed for all the SPF-conformant domains for which it sends mail.
5.6.3 Conformance with regard to receiving e-mail systems
To describe themselves as SPF-conformant, an SMTP receiver is
REQUIRED to perform SPF tests, though those tests need not be
performed while an SMTP transaction is ongoing. An SMTP server which
does not perform SPF tests SHALL NOT be deemed conformant. A server
NEED NOT reject a message; but if it does not, it SHOULD add a
Received-SPF header. If a server rejects a message, it SHOULD
include any <explanation> provided by the SPF publisher.
E-mail systems SHOULD exclude special addresses such as postmaster@
and abuse@ from SPF processing. See RFC2142.
5.6.4 Conformance with regard to a particular SMTP transaction
An email message during delivery shall be deemed conformant if the
client IP address and sender domain provide an "allow" result value
after SPF resolution according to the Technical Specification.
5.6.5 Conformance with regard to an email-sending user
An email-sending user is deemed conformant if all of her outbound
mail is sent through the designated mailer for the user's sender
domain.
5.6.6 Rejection of non-SPF conformant email
An SPF email system MAY choose to reject or discard email on the
basis of local policy. SPF is one component in an overall
email-policy engine. SPF merely makes it possible for policy
decisions to be properly made at the sender-domain level. The
actual policy decisions are outside the scope of this document.
5.7 Phased Rollout
At an adopting domain, adoption of SPF occurs in two phases, the
Transitional Phase and the Acceptance Phase. The boundary between
the two phases is called the "Sunrise Date". The "Sunrise Date"
varies from domain to domain and describes the date on which the
domain default switches from "softdeny" to "deny".
The two phases are characterized by different levels of awareness
among the domain's userbase, and different levels of strictness on
the part of SPF-conformant receivers.
When a sufficient majority of its users are SPF-conformant, a domain
SHOULD change its default from default=softdeny to default=deny.
That sends a signal to SPF-conformant mail receivers that
non-conformant messages SHOULD be rejected. Setting "default=deny"
protects the users from account fraud and joe-jobbing.
Messages that explicitly fail SPF with a "deny" SHOULD be rejected.
5.8 Global Sunrise Date
The decision to switch from default=softdeny to default=deny is
up to individual domains.
However, to encourage widespread adoption, this proposed standard
specifies July 4th, 2004 as a Global Sunrise Date, after which date
SPF-conformant domains SHOULD use default=deny, and after which date
SPF-conformant domains MAY choose to reject mail from non-conformant
domains.
Security Considerations
Spoofing of DNS data; poisoning of caches.
Spoofing of TCP sequences to make mail appear to come from a designated host.
On the Costs of Progress
Inherit the Wind
Gentlemen, progress has never been a bargain. You've got to pay for
it. Sometimes I think there's a man behind a counter who says 'All
right, you can have a telephone; but you'll have to give up privacy and
the charm of distance. Madam, you may vote; but at at price; you lose
the right to retreat behind a powder puff or a petticoat. Mister, you
may conquer the air; but the birds will lose their wonder and the
clouds will smell of gasoline.' Darwin moved us forward to a hilltop,
where we can look back and see the way from the which we came. But for
this view, this insight, this knowledge, we must abandon our faith in
the pleasant poetry of Genesis.
Declaration of Independence
... all experience hath shewn, that mankind are more disposed to
suffer, while evils are sufferable, than to right themselves by
abolishing the forms to which they are accustomed.
Normative References
1. Wong, M.W., "Sender Rewriting Scheme", Work In Progress,
http://spf.pobox.com/srs/
2. various RFCs, to be filled in.
Informative References
1. Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
2. Credit where due: B. Gingery first brought up the topic on the
SPAM-L mailing list, and it had been discussed earlier on the
Spamtools mailing list. There are other documents describing
similar approaches to this problem, some of which include:
http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00658.html
http://nospam.couchpotato.net/
3. Derek J. Balling <dredd(_at_)megacity(_dot_)org> for initial design of the
DNS record template and explanation, and "der Mouse"
<mouse(_at_)rodents(_dot_)montreal(_dot_)qc(_dot_)ca> for generalizing it
into the
current form.
4. Gulbrandsen, A., Vixie, P., "A DNS RR for specifying the location
of services (DNS SRV)", RFC 2052, October 1996
5. 4.3.2 of Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001
6. 2.1 of Lindenberg, G., "Anti-Spam Recommendations for SMTP MTAs",
RFC 2505, February 1999
7. 4.5.5 of Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001
8. Rosenbam, R., "Using the Domain Name System To Store Arbitrary
String Attributes", RFC 1464, May 1993
9. Danisch, Hadmut. "A DNS RR for simple SMTP sender authentication",
http://www.danisch.de/work/security/antispam.html, June 2003,
Work In Progress.
10. Fecyk, Gordon. "Designated Mailer Protocol", June 2003,
Work In Progress.
12. Acknowledgments
Gordon Fecyk for DMP.
The folks on the dsdraft mailing list.
The folks on the ASRG mailing list.
The folks on the spf-discuss mailing list.
The folks on zorch.
The folks on #perl.
Author's Address
Meng Weng Wong
IC Group, Inc.
105 S 12TH ST STE 310
Philadelphia, PA 19107
USA
Email: mengwong(_at_)pobox(_dot_)com
"I have made it a rule, whenever in my power, to avoid becoming the
draughtsman of papers to be reviewed by a public body."
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
TODO
http://www.ietf.org/ID-nits.html
2.10 Special Cases
If the client is localhost, SPF does not apply; policy mechanisms are
expected to bypass SPF. SPF clients SHOULD return "allow".
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡