RE: draft-mengwong-spf-02.txt
Paul Judge <[email protected]> Thu, 23 Oct 2003 10:59:27 -0400
| Newsgroups | gmane.ietf.asrg.rmx |
|---|---|
| Message-ID | <[email protected]> |
Will others please comment on the suggestion to move forward with this as the base og the combined proposal? > -----Original Message----- > From: Meng Weng Wong [mailto:[email protected]] > Sent: Saturday, October 18, 2003 5:12 PM > To: [email protected] > Subject: [asrg-rmx] draft-mengwong-spf-02.txt > > > On Thu, Oct 09, 2003 at 11:30:17AM -0400, Yakov Shafranovich wrote: > | > | I believe it is time to start working on a common draft. > | > > Here is the latest version of the SPF draft. I believe it > provides a superset of RMX functionality. > > I suggest we use the SPF name because it's already received > considerable exposure, and is the #1 hit on google too. > > If we proceed with this draft, I suggest the two primary > authors be Hadmut and Gordon, and I will take contributor credit. > > 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 > 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 policy record > > 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. > > This document refers to records of this kind as primary records. > > Note that the use of the TXT query-type for SPF 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.1.1 Examples > > example.com IN TXT "v=spf1 default=deny" > > If the <current-domain> is example.com, SPF clients perform a TXT > query on example.com. The following TXT results are valid syntax: > > "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.2 The _smtp_client subdomain. > > Domains may 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 MAY be REQUIRED to respond to A or TXT > queries under the _smtp_client subdomain, depending on how > they have > configured their primary SPF response. > > 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 > expanded 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[+TZ] 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. SPF publishers SHOULD NOT rely on this > feature; they MUST escape % literals. For example, > "exp=Your message looks like 20% spam" > is invalid syntax. Instead, say > "exp=Your message looks like 20%% spam" > > 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" > > If the <current-domain> were example.com, the <explanation> would > expand to "example.com 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 [email protected] > 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.3.3 Example with timestamp interpolation > > "v=spf1 default=! exp=Message rejected at %t" > > If the current time were noon on 3rd Feb 2001 EST(-5), the > <explanation> would expand to > > "Message rejected at 20010203-120000-5" > > The TZ timezone field syntax is > ( ( '+' / '-' ) DIGIT DIGIT [ ':' DIGIT DIGIT ] ) > representing an offset from UTC. See ISO8601. > > If an uppercase "%T" were used, the + would be encoded as "%2B". > > -------------------------------------------------------------- > ---------- > 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 directive, 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>. > > 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. > > Future version numbers may appear as "v=spf1.1" or "v=spf1.02.01". > Leading zeroes within dot-delimited sections are ignored, so > "1.02.01" is a higher version than "1.1". > > TXT responses which do not begin with a recognized version > directive > are ignored. > > -------------------------------------------------------------- > ---------- > 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 by a > matching mechanism depends on the default value of the > directive-set. > > 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 recursive lookup of another > directive-set, 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. > > If the client is localhost, SPF does not apply; policy > mechanisms are > expected to bypass SPF. SPF clients SHOULD return "allow". > > -------------------------------------------------------------- > ---------- > 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:[email protected] > - LocalPart:[email protected] > - 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 [email protected] > 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=+- [email protected] > bar.foo.bob.lp._smtp_client.example.com > LocalPart:rlp=+ [email protected] > foo-bar.bob.lp._smtp_client.example.com > LocalPart:rlp [email protected] > bob+foo-bar.lp._smtp_client.example.com > LocalPart:rlp [email protected] > bob.foo.bar.lp._smtp_client.example.com > LocalPart:rlp=. [email protected] > bar.foo.bob.lp._smtp_client.example.com > LocalPart:rlp=+ tm.o'[email protected] > 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. > > <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.6.1 Example > > Given the <current-domain> example.com, the initial SPF query might > produce: > > domain.com IN TXT "v=spf1 include:domain.org default=unknown" > > The next query would be > > domain.org IN TXT > > And subsequent queries within the scope of the include would > substitute "domain.org" as the <current-domain>. For example, if > > domain.org IN TXT "v=spf1 mx default=deny" > > The MX lookup would be for domain.org, not domain.com. > > > -------------------------------------------------------------- > ---------- > 3.7 IP4 > -------------------------------------------------------------- > ---------- > > Valid syntax: > - ip4:192.0.2.0/24 > > If the connecting IPv4 client IP lies in the specified > network, this > mechanism matches. > > -------------------------------------------------------------- > ---------- > 3.8 IP6 > -------------------------------------------------------------- > ---------- > > Valid syntax: > - ip6:.....um. > > If the connecting IPv6 client IP lies in the specified > network, this > mechanism matches. > > > -------------------------------------------------------------- > ---------- > 3.9 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 [email protected]) > error (temporary failure while resolving designated > mailer status for domain of sender [email protected]) > unknown (domain of sender [email protected] does not > designate mailers) > fail (client localhost[192.0.2.1] is not a > designated mailer for domain of sender [email protected]) > softfail (client localhost[192.0.2.1] is not a > designated mailer for transitioning domain of sender > [email protected]) > > 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. > > A domain MUST publish a policy record for the domain itself: > example.com IN TXT "v=spf1 ..." > > A domain also SHOULD publish policy records for each of its > designated servers: > mx01.example.com IN TXT "v=spf1 ..." > mx02.example.com IN TXT "v=spf1 ..." > > 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. > > When an SMTP host sends a message delivery status notification > message, it MAY use the null envelope sender: > MAIL FROM: <> > > If the sender host's HELO/EHLO command string includes the Fully > Qualified Domain Name of the sender host, primary SPF records MUST > exist for that FQDN for the host to be considered SPF-conformant. > > For example: in a transaction with > > HELO mx01.example.com > MAIL FROM: <> > > an SMTP+SPF receiver will perform an SPF query of the form > > mx01.example.com IN TXT > > and expect a result such as > > "v=spf1 ptr:example.com default=deny" > or > "v=spf1 mx:example.com default=deny" > > If these records are absent, SPF clients will be unable to > determine > conformance status based on envelope information alone, and MAY > proceed to analyze message headers in search of a sender > domain which > defines scope=header-from or scope=errors-to. > > 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 <[email protected]> for initial design of the > DNS record template and explanation, and "der Mouse" > <[email protected]> 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: [email protected] > > "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." > > > _______________________________________________ > asrg-rmx mailing list > [email protected] http://mailman.ntp.org/mailman/listinfo/asrg-rmx >