idnits 2.17.1 draft-mengwong-spf-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. == There is 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There is 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There is 18 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There is 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 553 has weird spacing: '...ncluded inc...' == Line 999 has weird spacing: '...pe-from the e...' -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2004) is 7257 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC3513' is mentioned on line 1088, but not defined ** Obsolete undefined reference: RFC 3513 (Obsoleted by RFC 4291) == Unused Reference: 'RFC1464' is defined on line 1723, but no explicit reference was found in the text == Unused Reference: 'RFC2373' is defined on line 1727, but no explicit reference was found in the text == Unused Reference: 'RFC2505' is defined on line 1728, but no explicit reference was found in the text == Unused Reference: 'RFC2822' is defined on line 1730, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2234 (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 2373 (Obsoleted by RFC 3513) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft 2 Category: Experimental Mark Lentczner 3 draft-mengwong-spf-01.txt Meng Weng Wong, pobox.com 4 Expires: September 2004 May 2004 6 Sender Policy Framework (SPF) 7 A Convention to Describe Hosts Authorized to Send SMTP Traffic 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire in September 2004. 33 Abstract 35 Email address forgery is a problem on the Internet today. Domain 36 owners want to control the use of their names in email, but are 37 helpless because they lack the means. This document introduces a 38 language for domains to make email-related declarations in DNS. It 39 defines in detail one possible sender authentication scheme for 40 domains to describe the hosts from which they send mail. SMTP 41 receivers can use this scheme to detect sender forgery. 43 Table of Contents 45 1. Introduction 46 1.1 Terminology 47 1.2 Designated Senders 48 2. SPF Records 49 2.1 Publishing 50 2.2 Interpretation 51 2.2.1 Subject of SPF testing 52 2.2.2 Lookup 53 3. SPF Record Evaluation 54 3.1 Matching Version 55 3.2 SPF Directive Evaluation 56 3.3 Default result 57 4. Mechanism Definitions 58 4.1 "all" 59 4.2 "include" 60 4.3 Introducing Designated Sender Mechanisms 61 4.4 "a" 62 4.5 "mx" 63 4.6 "ptr" 64 4.7 "ip4" and "ip6" 65 4.8 "exists" 66 5. Modifier Definitions 67 5.1 redirect: Redirected Query 68 5.2 exp: Explanation 69 5.3 accredit: Sender Accreditation 70 6. Miscellaneous 71 6.1 Unrecognized Mechanisms and Modifiers 72 6.2 Processing Limits 73 6.3 The Received-SPF header 74 7. Macros 75 7.1 Macro definitions 76 7.2 Expansion Examples 77 8. Conformance Definitions 78 8.1 Introduction 79 8.2 Conformance with regard to sender domains 80 8.3 Conformance with regard to sending e-mail systems 81 8.4 Conformance with regard to receiving e-mail systems 82 8.5 Conformance with regard to a particular SMTP transaction 83 8.6 Conformance with regard to an email-sending user 84 8.7 Rejection of non-SPF conformant email 85 8.8 Rejection of SPF conformant email 86 8.9 Recommendations 87 8.10 Changes to Existing Semantics 88 8.10.1 The Return-Path is now also a Responsible Sender 89 9. Applicability Statement 90 9.1 Adoption by disreputable domains 91 9.2 Limitations 92 9.3 Phased Rollout 93 9.4 Verbatim Forwarding 94 9.5 Per-user exemptions 95 10. Security Considerations 96 11. IANA Considerations 97 12. Contributors and Acknowledgements 98 Appendix A. Collected ABNF for SPF records 99 Appendix B. Extended Examples 100 Appendix B.1 Simple Example 101 Appendix B.2 Multiple Domain Examples 102 Appendix B.3 RBL Style Example 103 Normative References 104 Informative References 105 Authors 107 1. Introduction 109 The intended audience for this document includes administrators of 110 the Domain Name System and developers of Mail Transfer Agents (MTAs), 111 Mail Delivery Agents (MDAs), and Mail User Agents (MUAs). They are 112 assumed to be familiar with the workings of SMTP and DNS. See 113 [RFC2821] and [RFC1034]. 115 Forgery of domain names is a problem. Malicious entities often 116 falsify envelope and header addresses to make it harder to identify 117 the source of a message. When those addresses correspond to real 118 people and organizations, the victims of forgery suffer a cost in 119 bounce messages, tarnished reputations, and misdirected abuse 120 reports. 122 SPF is designed to fight email address forgery. It does this by 123 establishing a policy framework and an authentication scheme. 125 SPF defines a simple language. Domains can use that language to 126 describe the mail they send. SMTP receivers can use these 127 descriptions to evaluate messages. 129 SPF can implement a sender authentication scheme. In a sender 130 authentication scheme, a domain owner asserts that legitimate 131 messages from that domain must meet certain criteria. Messages which 132 do not meet the criteria are not legitimate. These assertions are 133 made in machine-readable form. 135 SPF defines a specific sender authentication scheme based on the 136 designated sender model. A domain identifies certain hosts as 137 designated senders. Mail from those hosts is considered legitimate. 138 Mail from other hosts is not. 140 SPF publishes policy data in the DNS. DNS resolvers can cache SPF 141 data. Caching reduces lookup traffic. Sender domains do not have to 142 run new servers to advertise SPF information. 144 SPF is extensible. Multiple mechanisms can be defined. While other 145 sender authentication schemes can be expressed in SPF, the rest of 146 this document defines a designated sender scheme in detail. 148 1.1 Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 152 this document are to be interpreted as described in [RFC2119]. 154 An SMTP client sends mail to an SMTP server. The SMTP server and 155 downstream systems comprise the SMTP receiver. The SMTP receiver 156 acts as an SPF client to an SPF publisher domain. 158 SPF processing may occur as early as the MAIL FROM stage of an SMTP 159 transaction or as late as the display stage in a Mail-User Agent. 160 For convenience, SMTP servers which accept, classify, discard, or 161 reject mail on the basis of SPF tests may be said to be speaking 162 "SMTP+SPF". 164 1.2 Designated Senders 166 Designated sender schemes are weaker than cryptographic schemes but 167 provide more assurance than the current SMTP model. 169 SPF defines a set of mechanisms which add up to a designated sender 170 scheme. First, domain owners designate legitimate outbound mail 171 servers in a compact, symbolic notation. SMTP receivers may query 172 sender domains using these mechanisms and decide the validity of a 173 given SMTP transaction while that transaction is ongoing, even before 174 any message data is passed. Alternatively, SPF tests can be 175 performed after SMTP time by an MDA or MUA. MTAs, MDAs, and MUAs may 176 choose to accept, classify, discard, or reject messages based on the 177 result of an SPF test. 179 SPF can be used to verify the sender of a message based on envelope 180 information available at SMTP time or according to the headers after 181 an SMTP transaction has completed. 183 2. SPF Records 185 Domains declare verifiable attributes that describe the mail they 186 send. 188 A domain's declarations are presented in an SPF record. The record 189 is a single string of text: 191 SPF-record = version *( 1*SP ( directive | modifier ) ) 193 An example SPF Record is: 195 v=spf1 +mx +a:colo.example.com/28 -all 197 This record has a version of "v=spf1" and three directives: 198 "+mx", "+a:colo.example.com/28", and "-all". 200 2.1 Publishing 202 The SPF record is published in the DNS. The record is of type TXT. 203 The record is placed in the DNS tree at the level of the domain. 205 The TXT type was chosen for pragmatic reasons. 207 SPF clients ignore records which do not carry a recognized version 208 string. This document specifies the version string "v=spf1". 210 A domain MUST NOT return multiple records that begin with the 211 version "v=spf1". If more than one "v=spf1" record is returned, 212 this constitutes a syntax error and the result is "unknown". 214 Note: The comparison is done on the entire version section (which is 215 terminated either by a SP character, or the end of the TXT record). 216 Hence, a record with a version of "v=spf10" is not considered a 217 record with version "v=spf1". 219 An example SPF record is: 221 v=spf1 +mx +a:colo.example.com/28 -all 223 This might be published easily via this line in a domain file: 225 example.com. IN TXT "v=spf1 +mx +a:colo.example.com/28 -all" 227 In unusual situations, directives may require additional DNS records. 228 If additional records are used, they MAY be published under the 229 "_spf" subdomain. See Appendix B for examples. 231 An SPF record MAY consist of a single TXT record with multiple 232 strings. If such an TXT record is encountered, then an SPF client 233 MUST concatenate those strings without adding spaces, eg 234 TXT "v=spf1 .... first" "second string..." 235 MUST be treated as equivalent to 236 TXT "v=spf1 .... firstsecond string..." 238 TXT records containing multiple strings are useful in order to 239 construct more complex SPF records which would otherwise exceed 240 the maximum length of a string within a TXT record. 242 Note: Many nameserver implementations will silently split long 243 strings in TXT records into several shorter strings. 245 2.2 Interpretation 247 SPF clients are applications that parse and interpret the SPF record 248 for a domain. Clients MUST correctly interpret the SPF record 249 according to the canonical algorithm defined here. 251 Clients MAY use a different algorithm, so long as the results are 252 the same. 254 2.2.1 Subject of SPF testing 256 In an SMTP transaction, an SMTP client may provide FQDNs in the HELO 257 argument and in the MAIL FROM return-path. SMTP+SPF receivers MAY 258 check the HELO argument and MUST check the return-path. A single 259 SMTP transaction may therefore trigger one or two SPF queries. 261 Accordingly, the may be drawn from the HELO 262 argument or from the "MAIL FROM" return-path. This document 263 sometimes refers to the as the "envelope 264 sender". 266 It is RECOMMENDED that SMTP+SPF receivers perform tests using the 267 following algorithm. 269 SMTP+SPF receivers MAY check the HELO argument. In this mode, the 270 comes from the HELO argument IF the HELO 271 argument is a fully qualified domain name. If the HELO argument 272 is not an FQDN, there is nothing to check and the result is 273 "unknown". If the HELO test returns a "fail", the overall result 274 for the envelope is "fail", and there is no need to test the 275 return-path. 277 SMTP+SPF receivers MUST check the return-path unless HELO testing 278 produced a "fail". In this mode, the comes 279 from the domain name of the "MAIL FROM" return-path. When the 280 return-path has no domain, a client MUST use the HELO domain 281 instead. If the HELO argument does not provide an FQDN, SPF 282 processing terminates with "unknown". 284 If SPF processing occurs after SMTP time, the envelope sender may 285 be obtained from the Return-Path header. If the Return-Path header 286 has no domain, a client MAY try to extract the HELO domain from the 287 Received headers. If the headers do not yield useful envelope 288 information, SPF processing terminates with "unknown". 290 SMTP+SPF receivers MAY test the domain given in the HELO argument 291 whether or not the return-path contains a domain name. 293 However, the address MAY be drawn from an 294 alternative source. For example, an MUA may find it more convenient 295 to extract the from the Return-Path header or 296 from the Sender: header. 298 If the has no localpart, clients MUST 299 substitute the string "postmaster" for the localpart. 301 The is initially drawn from the 302 . Recursive mechanisms such as Include and 303 Redirect replace the initial with another domain. 304 However, they do not change the value of the . 305 See sections 4.2, 3.3, and 8.4. 307 2.2.2 Lookup 309 SPF clients perform a TXT type query in search of an SPF record. 311 Any number of records may be returned. Only the record which begins 312 with the version "v=spf1" is relevant to this document. CNAME 313 responses are followed as usual. 315 If no matching records are returned, an SPF client MUST assume that 316 the domain makes no SPF declarations. SPF processing MUST abort 317 and return "none". 319 If the domain does not exist (NXDOMAIN), SPF clients MUST return 320 "unknown". 322 If a domain has no SPF record, clients MAY substitute SPF data from 323 a parent domain ONLY IF the appropriate parent domain's SPF record 324 sets "match_subdomains=yes". For example, if no SPF record is 325 found for "workstation.example.com", clients MAY proceed to 326 automatically query "example.com". The appropriate parent domain 327 to fallback on MUST be determined according to the DNS zone cut. 329 3. SPF Record Evaluation 331 An SPF client evaluates an SPF record and produces one of seven 332 results: 334 None: The domain does not publish SPF data. 336 Neutral (?): The SPF client MUST proceed as if a domain did not 337 publish SPF data. This result occurs if the domain explicitly 338 specifies a "?" value, or if processing "falls off the end" of 339 the SPF record. 341 Pass (+): the message meets the publishing domain's definition of 342 legitimacy. MTAs proceed to apply local policy and MAY accept or 343 reject the message accordingly. 345 Fail (-): the message does not meet a domain's definition of 346 legitimacy. MTAs MAY reject the message using a permanent 347 failure reply code. (Code 550 is RECOMMENDED. See [RFC2821] 348 section 7.1.) 350 Softfail (~): the message does not meet a domain's strict 351 definition of legitimacy, but the domain cannot confidently state 352 that the message is a forgery. MTAs SHOULD accept the message 353 but MAY subject it to a higher transaction cost, deeper scrutiny, 354 or an unfavourable score. 356 There are two error conditions, one temporary and one permanent. 358 Error: indicates an error during lookup; an MTA SHOULD reject the 359 message using a transient failure code, such as 450. 361 Unknown: indicates incomplete processing: an MTA MUST proceed as 362 if a domain did not publish SPF data. 364 When SPF-aware SMTP receivers accept a message, they SHOULD prepend a 365 Received-SPF header. See section 6. 367 SPF clients MUST use the algorithm described in this section 368 or its functional equivalent. 370 If an SPF client encounters a syntax error in an 371 SPF record, it must terminate processing and return a result 372 of "unknown". 374 3.1 Matching Version 376 An SPF record begins with a version section: 378 version = "v=spf" version-number 379 version-number = 1*DIGIT 381 SPF clients MUST use only the records of the highest understood 382 version published by a domain and ignore all lower versions, unless 383 that version explicitly recognizes lower versioned responses. 385 For example, if an SPF client understands versions 1, 2 and 3, and 386 the DNS query results in records of version 1, 2 and 4, then only 387 the record with version 2 is used. 389 This specification describes version 1. If multiple "v=spf1" records 390 are returned, the SPF client MUST reject them all and act as if no 391 version 1 records were returned. 393 SPF-like records of the form "v=spf1+ext" or "v=spf1.1" are not 394 described by this document. 396 3.2 SPF Directive Evaluation 398 There are two types of directives: mechanisms and modifiers. A given 399 mechanism type may always appear multiple times in a record. 400 Modifiers may be constrained to appear at most once per record, 401 depending on the definition of the modifier. Unknown mechanisms 402 cause processing to abort with the result "unknown". Unknown 403 modifiers are ignored by clients. 405 An SPF record contains an ordered list of mechanisms and modifiers: 407 SPF-record = version *( 1*SP ( directive / modifier ) ) *SP 409 version = "v=spf" 1*DIGIT 411 prefix = "+" / "-" / "?" / "~" 413 directive = [prefix] mechanism 414 mechanism = name [ ":" macro-string ] *[ '/' *DIGIT ] 415 modifier = name "=" macro-string 416 name = alpha *( alpha / digit / "-" / "_" / "." ) 418 Modifiers always contain an equals ('=') character. 420 Mechanisms usually contain ':' or '/' characters. 422 Directives that do not contain any of '=', ':', or '/' are 423 mechanisms. 425 Modifiers MAY appear to the right of a terminal mechanism such as 426 "all". SPF parsers may therefore choose to extract all the 427 modifiers from a record before interpreting mechanisms. 428 Alternatively, they may continue to parse a record in search of a 429 meaningful modifier even after mechanism evaluation has completed. 431 Each mechanism is considered in turn from left to right. 433 When a mechanism is evaluated, one of three things can happen: it 434 can match, it can not match, or it can throw an exception. 436 If it matches, processing ends and the prefix value is returned as 437 the result of that record. (The default prefix value is "+".) 439 If it does not match, processing continues with the next mechanism. 440 If no mechanisms remain, the default result is specified in section 441 3.3. 443 If it throws an exception, mechanism processing ends and 444 the exception value is returned (either "error" 445 indicating a temporary failure, usually DNS-related, or 446 "unknown" indicating a syntax error or other permanent 447 failure resulting in incomplete processing.) 449 Mechanisms are described in Sections 4 and 5. 451 A missing prefix for a mechanism is the same as a prefix of "+". 453 The possible prefixes are: 454 + pass 455 - fail 456 ~ softfail 457 ? neutral 459 Mechanism and modifier names are case-insensitive. A mechanism 460 "INCLUDE" is equivalent to "include". However, case SHOULD be 461 preserved in arguments to mechanisms and modifiers. 463 3.3 Default result 465 If none of the mechanisms match and there is no redirect modifier, 466 then the result of the SPF query is "neutral". If there is a 467 redirect modifier, the SPF client proceeds as defined in section 5.1. 469 Note that SPF records SHOULD always either use a redirect modifier or 470 an "all" mechanism to explicitly terminate processing. 472 For example: 474 v=spf1 +mx -all 476 v=spf1 +mx redirect=_spf.example.com 478 4. Mechanism Definitions 480 This section defines two types of mechanisms. 482 Basic mechanisms contribute to the SPF language framework. They 483 do not specify a particular type of authentication scheme. 485 - all 486 - include 488 Designated sender mechanisms are used to discover the relationship of 489 the client IP address to the . 491 - a - ip4 492 - mx - ip6 493 - ptr - exists 495 Other mechanisms can be independently defined in the future. 497 Mechanisms either match, do not match, or throw an exception. 498 If they match, their prefix value is returned. 499 If they do not match, processing continues. 500 If they throw an exception, the exception value is returned. 502 Several of these mechanisms take an optional argument. 503 If the is present, then it is macro expanded (see 504 Section 7) and becomes the . If the is 505 not provided, the is used as the . 507 Several mechanisms require DNS lookups. In those lookups, CNAME 508 responses are followed in the usual way. 510 4.1 "all" 512 all = "all" 514 The "all" mechanism is a test that always matches. It is used as the 515 rightmost mechanism in an SPF record to provide an explicit default. 517 For example: 518 v=spf1 +mx +a -all 520 Mechanisms after "all" will never be tested. 522 4.2 "include" 524 include = "include" ":" domain-spec 526 The "include" mechanism triggers a recursive SPF query. The 527 domain-spec is expanded as per section 7. Then a new query is 528 launched using the resulting string as the . The 529 stays the same. 531 "Include" makes it possible for one domain to designate multiple 532 administratively independent domains. 534 For example, a vanity domain "example.net" might send mail using the 535 servers of administratively independent domains example.com and 536 example.org. 538 Example.net could say 540 "v=spf1 include:example.com include:example.org -all". 542 That would direct an SPF client to, in effect, search the SPF records 543 for example.com and example.org for a "pass" result. Only if the 544 message were not permitted for either of those domains would the 545 result be "fail". 547 This mechanism matches when the inner, included query result returns 548 a pass, and doesn't match when the result is fail, softfail, or 549 neutral. However, if the new query returns none, error, or unknown, 550 then processing of the entire SPF query stops immediately and 551 returns the error result. 553 included include 554 query mechanism SPF 555 result result processing 556 -------- -- -------------- ------------------------------------- 557 pass => match, return the prefix value for "include" 558 fail => no match, continue processing 559 softfail => no match, continue processing 560 neutral => no match, continue processing 561 error => throw error, abort processing, return error 562 unknown => throw unknown, abort processing, return unknown 563 none => throw unknown, abort processing, return unknown 565 If the parent domain includes another domain, and that domain one day 566 loses its SPF record, it is better for the query to abort with 567 "unknown" than to continue on to a potential "-all". 569 The Include mechanism is intended for crossing administrative 570 boundaries. While it is possible to use Includes to consolidate 571 multiple domains that share the same set of designated hosts, domains 572 are encouraged to use Redirects where possible, and to minimize the 573 number of within a single administrative domain. 574 For example, if example.com and example.org were managed by the same 575 entity, and if the canonical set of designated mailers for both 576 domains were "mx:example.com", it would be possible for example.org 577 to specify "include:example.com", but it would be preferable to 578 specify "redirect=example.com" or even "mx:example.com". 580 4.3 Introducing Designated Sender Mechanisms 582 Designated sender schemes allow SMTP receivers to make policy 583 decisions on the basis of domain name rather than IP address. 585 These mechanisms allow a domain to declare that certain hosts send 586 mail from that domain. When an SPF client processes these 587 mechanisms, it tests to see if the matches. 589 Usually, the is the IP address of an SMTP client. The 590 SMTP receiver is the SPF client. The SPF lookup may also operate 591 after the SMTP transaction has terminated. In these cases the 592 may have to be extracted from the Received header or 593 some other meta-data about the message. Received headers can be 594 forged. Still, accurate analysis is possible if care is taken. 596 If mail is transferred between mail systems internal to an 597 organization, and that organization chooses to process SPF after such 598 transfers, then the should be the external host that 599 first transferred the mail into the organization's mail system. 601 When the is localhost, Designated Sender mechanisms 602 are not meaningful. Therefore, an SPF client immediately returns 603 "pass" without evaluating mechanisms. 605 The is required for these mechanisms. If it cannot 606 be determined, then these mechanisms cannot be tested, and "unknown" 607 is returned. 609 The following conventions apply to designated sender mechanisms: 611 If the optional is given, then only the upper 612 bits of each IP are compared to the . 614 If the SMTP connection is IPv6, read "AAAA lookup" for "A lookup", 615 except where "A" lookups are explicitly specified. 617 4.4 "a" 619 This mechanism matches if the is one of the 620 's IP addresses. 622 A = "a" [ ":" domain-spec ] [ dual-cidr-length ] 624 The is compared to the IP address(es) of the 625 . If any address matches, the mechanism matches. 627 4.5 "mx" 629 This mechanism matches if the is one of the MX hosts 630 for a domain name. 632 MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] 634 SPF clients first perform an MX lookup on the . SPF 635 clients then perform an A lookup on each MX name returned, in order 636 of MX priority. The is compared to each returned IP 637 address. If any address matches, the mechanism matches. 639 Note Regarding Implicit MXes: If the has no MX records, 640 SPF clients MUST NOT pretend the target is its single MX, and MUST 641 NOT default to an A lookup on the directly. This 642 behaviour breaks with the legacy "implicit MX" rule. See [RFC2821] 643 Section 5. If such behaviour is desired, the publisher should 644 specify an "a" directive. 646 4.6 "ptr" 648 This mechanism tests if the 's name is within a 649 particular domain. 651 PTR = "ptr" [ ":" domain-spec ] 653 First the 's name is looked up using this procedure: 654 perform a PTR lookup against the 's IP. For each 655 record returned, validate the host name by looking up its IP address. 656 If the 's IP is among the returned IP addresses, then 657 that host name is validated. In pseudocode: 659 sending-host_names := ptr_lookup(sending-host_IP); 660 for each name in (sending-host_names) { 661 IP_addresses := a_lookup(name); 662 if the sending-host_IP is one of the IP_addresses { 663 validated_sending-host_names += name; 664 } } 666 Check all validated hostnames to see if they end in the 667 domain. If any do, this mechanism matches. If no validated hostname 668 can be found, or if none of the validated hostnames end in the 669 , this mechanism fails to match. 671 Pseudocode: 672 for each name in (validated_sending-host_names) { 673 if name ends in , return match. 674 if name is , return match. 675 } 676 return no-match. 678 This mechanism matches if the is an ancestor of the 679 , or if the and the are 680 the same. For example: "mail.example.com" is within the domain 681 "example.com", but "mail.bad-example.com" is not. If a validated 682 hostname is the , a match results. 684 4.7 "ip4" and "ip6" 686 These mechanisms test if the falls into a given IP 687 network. 689 IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] 690 IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] 691 ip4-cidr-length = "/" 1*DIGIT 692 ip6-cidr-length = "/" 1*DIGIT 694 ip4-network = dotted-quad notation 695 ip6-network = conventional IPv6 notation 697 The is compared to the given network. If they match, 698 the mechanism matches. 700 If the cidr-length is omitted, the ip4-cidr-length is taken to be 701 "/32" and the ip6-cidr-length is taken to be "/128". 703 4.8 "exists" 705 This mechanism is used to construct an arbitrary host name that is 706 used for a DNS A record query. It allows for complicated schemes 707 involving arbitrary parts of the mail envelope to determine what is 708 legal. 710 exists = "exists" ":" domain-spec 712 The domain-spec is expanded as per Section 7. The resulting domain 713 name is used for a DNS A lookup. If any A record is returned, this 714 mechanism matches. The lookup type is 'A' even when the connection 715 type is IPv6. 717 SPF publishers can use this mechanism to specify arbitrarily complex 718 queries. For example, suppose example.com publishes the SPF record: 720 v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all 722 The target-name might expand to 723 "1.2.0.192.someuser._spf.example.com". This makes fine-grained 724 decisions possible at the level of the user and client IP address. 726 5. Modifier Definitions 728 Only two standard modifiers are defined: "redirect" and "exp". SPF 729 clients MUST support them both. 731 Modifiers are not mechanisms: they do not return match or no-match. 733 Instead they provide additional information or change the course of 734 SPF processing. 736 While unrecognized mechanisms cause an immediate "unknown" abort, 737 unrecognized modifiers are simply ignored. 739 Modifiers therefore provide an easy way to extend the SPF protocol. 741 This document reserves one extension modifier, "accredit", one 742 deprecated modifier "default", and one future modifier 743 "match_subdomains". 745 5.1 redirect: Redirected Query 747 If all mechanisms fail to match, and a redirect modifier is present, 748 then processing proceeds as follows. 750 redirect = "redirect" "=" domain-spec 752 The domain-spec portion of the redirect section is expanded 753 as per the macro rules in section 7. The resulting string 754 is a new domain that is now queried: The 755 is set to this new domain, and the new domain's SPF record 756 is fetched and processed. Note that does not 757 change. 759 The result of this new query is then considered the result of 760 original query. 762 Note that the newly queried domain may itself specify redirect 763 processing. 765 This facility is intended for use by organizations that wish to apply 766 the same SPF record to multiple domains. For example: 768 la.example.com. TXT "v=spf1 redirect=_spf.example.com" 769 ny.example.com. TXT "v=spf1 redirect=_spf.example.com" 770 sf.example.com. TXT "v=spf1 redirect=_spf.example.com" 771 _spf.example.com. TXT "v=spf1 mx:example.com -all" 773 In this example, mail from any of the three domains is described by 774 the same SPF record. This can be an administrative advantage. 776 Note: in general, a domain A cannot reliably use a redirect to 777 another domain B not under the same administrative control. Since 778 the stays the same, there is no guarantee that 779 the SPF directives at domain B will correctly work for addresses in 780 domain A, especially if domain B uses mechanisms involving 781 localparts. An "Include" directive may be more appropriate. 783 Only one redirect modifier may appear per SPF record. The modifier 784 does not have to appear at the end; it MAY appear anywhere in the 785 record. However, for clarity it is RECOMMENDED that redirect 786 modifiers appear after mechanisms. 788 5.2 exp: Explanation 790 The argument to the explanation modifier is a domain-spec to be TXT 791 queried. The result of the TXT query is a macro-string that is 792 macro-expanded. If SPF processing results in a rejection, the 793 expanded result SHOULD be shown to the sender in the SMTP reject 794 message. This string allows the publishing domain to communicate 795 further information via the SMTP receiver to legitimate senders in 796 the form of a short message or URL. 798 Only one exp modifier may appear per SPF record. 800 explanation = "exp" "=" domain-spec 802 When an SPF client performs a query, and the result is anything other 803 than pass, then the explanation string, if present, SHOULD be 804 presented to the SMTP client after macro expansion. See section 7. 806 Suppose example.com has this SPF record 808 v=spf1 mx -all exp=explain._spf.%{d} 810 Here are some examples of possible explanation TXT records at 811 explain._spf.example.com: 813 Example.com mail should only be sent by its own servers. 814 -- a simple, constant message 816 %{i} is not one of %{d}'s designated mail servers. 817 -- a message with a little more info, including the 818 -- SMTP sender's IP address 820 See http://%{d}/why.html?s=%{S}&i=%{I}&h=%{H} 821 -- a complicated example that constructs a URL with 822 -- most of the parameters of the failed message so that 823 -- a web page can be generated with instructions 825 If multiple explanation TXT records are returned, they are 826 concatenated in the order they were received. Use of multiple TXT 827 records is discouraged as DNS does not guarantee order. 829 Note: during recursion into an Include mechanism, explanations do not 830 propagate out. But during execution of a Redirect modifier, the 831 explanation string from the target of the redirect is used. 833 5.3 accredit: Sender Accreditation 835 accreditation = 'accredit' '=' domain-spec 837 The argument to the accreditation modifier is a domain-spec to be 838 macro-expanded and queried. The result of the query is interpreted 839 according to the definitions set forth by the accreditation service. 841 For example, 843 accredit=%{d}.accreditation-provider.example.com 844 accredit=%{ir}.accreditation-provider.example.com 846 This facility allows the publishing domain to make independently 847 verifiable assertions about itself in machine-readable form. 849 Multiple "accredit" modifiers may appear in one SPF record. 851 The "accredit" modifier is OPTIONAL. SPF publishers MAY omit it. 852 SPF clients MAY ignore any or all "accredit" modifiers. If a 853 receiver does not recognize the domain-spec argument, it MAY ignore 854 the modifier. 856 It is expected that SPF-enabled receivers will maintain a library of 857 recognized accreditation providers, keyed by the domain-spec. An 858 accreditation provider is responsible for describing the protocol it 859 uses to encode assertions. For example, suppose an accreditation 860 provider supports DNS "A" queries against the expanded domain-spec. 861 A result of NXDOMAIN could mean "domain is not known to the 862 accreditation service." A result of "127.0.0.10" could mean "the 863 accreditation service vouches for the integrity of the sender 864 domain." Accreditation providers can make up any protocol they like 865 as long as they can convince receivers to use it. 867 Accreditation is only meaningful if the result of the SPF query is a 868 PASS. 870 Accreditation operates on behalf of the sender. Receivers, and the 871 reputation services that operate on their behalf, are expected to 872 adopt a critical stance toward accreditation assertions. 874 6. Miscellaneous 876 6.1 Unrecognized Mechanisms and Modifiers 878 Future extensions to this standard may introduce new mechanisms and 879 modifiers. 881 Unrecognized mechanisms cause processing to abort: if, during 882 evaluation of an SPF record, an SPF client encounters a mechanism 883 which it does not understand or which it cannot properly evaluate 884 (due perhaps to insufficient information about the message at 885 evaluation time), then it terminates processing and returns 886 "unknown", without evaluating any further mechanisms. Mechanisms 887 listed before the unknown mechanism MUST, however, be evaluated. 889 For example, given the record 891 v=spf1 a mx ptr domainkeys:_dk.%{d} -all 893 messages that match the "a", "mx", or "ptr" mechanisms would return a 894 "pass" result. An SPF client that did not recognize the mechanism 895 "domainkeys" would return "unknown". An SPF client that was 896 domainkeys-aware would be able to perform extended evaluation. If 897 the message matched the domainkeys test, it would pass; if it did 898 not, evaluation would proceed to "-all" and return "fail". 900 "domainkeys" is an example of an unknown extension mechanism that 901 could be defined in future versions of this standard. It is NOT 902 defined by this proposal. 904 Unrecognized modifiers are ignored: if an SPF client encounters 905 modifiers which it does not recognize, it MUST ignore them and 906 continue processing. Modifiers always contain an "=" sign. 908 Unrecognized mechanisms are preserved in the Received-SPF header. 909 See section 6.3. 911 6.2 Processing Limits 913 During processing, an SPF client may perform additional SPF 914 subqueries due to the Include mechanism and the Redirect modifier. 916 SPF clients must be prepared to handle records that are set up 917 incorrectly or maliciously. SPF clients MUST perform loop detection, 918 limit SPF recursion, or both. If an SPF client chooses to limit 919 recursion depth, then at least a total of 20 redirects and includes 920 SHOULD be supported. (This number should be enough for even the most 921 complicated configurations.) 923 If a loop is detected, or if more than 20 subqueries are triggered, 924 an SPF client MAY abort the lookup and return the result "unknown". 926 Regular non-recursive lookups due to mechanisms like "a" and "mx" or 927 due to modifiers like "exp" do not count toward this total. 929 6.3 The Received-SPF header 931 It is RECOMMENDED that SMTP receivers record the result of SPF 932 processing in the message headers. If an SMTP receiver chooses to do 933 so, it MUST use the "Received-SPF" header defined here. This 934 information is intended for the recipient. (Information intended for 935 the sender of the e-mail is described in Section 5.2, Explanation.) 937 The header SHOULD be prepended to existing headers. It MUST appear 938 above any other Received-SPF headers in the message. The header has 939 the format: 941 header = "Received-SPF:" 1*SP result [ 1*SP "(" comment ")" ] 942 *( 1*SP key-value-pair ) 944 result = "pass" / "fail" / "error" / "softfail" / "neutral" / 945 "none" / "unknown" / unknown-mechanisms 947 unknown-mechanisms = "unknown" *( 1*SP [prefix] mechanism ) 949 key-value-pair = 1*VCHAR "=" *(WSP / VCHAR) ";" 951 comment = [ smtp-receiver-hostname ": " comment-string ] 953 The comment-string should convey supporting information for the 954 result (such as and ). 956 If processing was aborted due to unrecognized mechanisms, the 957 Received-SPF header SHOULD show the unrecognized mechanisms after 958 the "unknown" word. 960 Example headers generated by mybox.example.org: 962 Received-SPF: pass (mybox.example.org: domain of 963 myname@example.com designates 192.0.2.1 as permitted sender) 964 receiver=mybox.example.org; client-ip=192.0.2.1; 965 envelope-from=; helo=foo.example.com; 967 Received-SPF: fail (mybox.example.org: domain of 968 myname@example.com does not designate 969 192.0.2.1 as permitted sender) 970 receiver=mybox.example.org; 971 client-ip=192.0.2.1; 972 envelope-from=; 973 helo=foo.example.com; 975 Received-SPF: softfail (mybox.example.org: domain of 976 transitioning myname@example.com does not 977 designate 192.0.2.1 as permitted sender) 979 Received-SPF: neutral (mybox.example.org: 192.0.2.1 is neither 980 permitted nor denied by domain of 981 myname@example.com) 983 Received-SPF: none (mybox.example.org: myname@example.com does 984 not designate permitted sender hosts) 986 Received-SPF: unknown -extension:foo (mybox.example.org: domain 987 of myname@example.com uses a 988 mechanism not recognized by this client) 990 Received-SPF: error (mybox.example.org: error in processing 991 during lookup of myname@example.com: DNS 992 timeout) 994 SPF clients may append zero or more of the following key-value-pairs 995 at their discretion: 997 receiver the hostname of the SPF client 998 client-ip the IP address of the SMTP client 999 envelope-from the envelope sender address 1000 helo the hostname given in the HELO or EHLO command 1001 mechanism the mechanism that matched (if no mechanisms 1002 matched, substitute the word "default".) 1003 problem if an error was returned, details about the error 1005 Other key-value pairs may be defined by SPF clients. Until a new key 1006 name becomes widely accepted, new key names should start with "x-". 1008 7. Macros 1010 7.1 Macro definitions 1012 Certain directives perform macro interpolation on their arguments. 1014 macro-string = *( macro-char / VCHAR ) 1015 macro-char = ( "%{" ALPHA transformer *delimiter "}" ) 1016 / "%%" / "%_" / "%-" 1017 transformer = [ *DIGIT ] [ "r" ] 1018 delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" 1020 A literal "%" is expressed by "%%". 1021 %_ expands to a single " " space. 1022 %- expands to a URL-encoded space, viz. "%20". 1024 The following macro letters are expanded in directive arguments: 1026 l = local-part of responsible-sender 1027 s = responsible-sender 1028 o = responsible-domain 1029 d = current-domain 1030 i = SMTP client IP (nibble format when an IPv6 address) 1031 p = SMTP client domain name 1032 v = client IP version string: "in-addr" for ipv4 or "ip6" for ipv6 1033 h = HELO/EHLO domain 1034 r = receiving domain 1036 The following macro letters are expanded only in "exp" text: 1038 c = SMTP client IP (easily readable format) 1039 t = current timestamp in UTC epoch seconds notation 1041 The uppercase versions of all these macros are URL-encoded. 1043 A '%' character not followed by a '{', '%', '-', or '_' character 1044 MUST be interpreted as a literal. SPF publishers SHOULD NOT rely on 1045 this feature; they MUST escape % literals. For example, an 1046 explanation TXT record 1047 Your spam volume has increased by 581% 1048 is incorrect. Instead, say 1049 Your spam volume has increased by 581%% 1051 Legal optional transformers are: 1053 *DIGIT ; zero or more digits 1054 'r' ; reverse value, splitting on dots by default 1056 If transformers or delimiters are provided, the macro strings are 1057 split into parts. After performing any reversal operation or 1058 removal of left-hand parts, the parts are rejoined using "." and not 1059 the original splitting characters. 1061 By default, strings are split on "." (dots). Macros may specify 1062 delimiter characters which are used instead of ".". Delimiters 1063 MUST be one or more of the characters: 1064 "." / "-" / "+" / "," / "/" / "_" / "=" 1066 The 'r' transformer indicates a reversal operation: if the client IP 1067 address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1" 1068 and the macro %{ir} would expand to "1.2.0.192". 1070 The DIGIT transformer indicates the number of right-hand parts to 1071 use after optional reversal. If a DIGIT is specified, it MUST be 1072 nonzero. If no DIGITs are specified, or if the value specifies more 1073 parts than are available, all the available parts are used. If the 1074 DIGIT was 5, and only 3 parts were available, the macro interpreter 1075 would pretend the DIGIT was 3. Implementations MAY limit the 1076 number, but MUST support at least a value of 9. 1078 For the "l" and "s" macros: when the local-part is not defined, the 1079 string "postmaster" is substituted. The local-part might be 1080 undefined if the is drawn from the HELO command 1081 rather than the MAIL FROM. 1083 For IPv4 addresses, both the "i" and "c" macros expand to the 1084 standard dotted-quad format. 1086 For IPv6 addresses, the "i" macro expands to dot-format address; it 1087 is intended for use in %{ir}. The "c" macro may expand to any of 1088 the hexadecimal colon-format addresses specified in [RFC3513] section 1089 2.2. It is intended for humans to read. 1091 Use of the "t" macro in DNS lookups would greatly reduce the 1092 effectiveness of DNS caching. The "t" macro is only allowed in 1093 explanation records. The value of the "t" macro SHOULD NOT change 1094 during the evaluation of a given SPF record. 1096 The "p" macro expands to the validated domain name of the SMTP 1097 client. The validation procedure is described in section 4.6. If 1098 there are no validated domain names, the word "unknown" is 1099 substituted. If multiple validated domain names exist, the first one 1100 returned in the PTR result is chosen. 1102 The "r" macro expands to the name of the receiving MTA. This SHOULD 1103 be a fully qualified domain name, but if one does not exist (as when 1104 the checking is done by a script) or if policy restrictions dictate 1105 otherwise, the word "unknown" SHOULD be substituted. The domain 1106 name MAY be different than the name found in the MX record that the 1107 client MTA used to locate the receiving MTA. 1109 The "s" macro expands to the sender email address: a localpart, an @ 1110 sign, and a domain. The "o" macro is the domain part of the "s". 1111 They remain the same during a recursive "include" or "redirect" 1112 subquery. 1114 When the result of macro expansion is used in a domain name query, if 1115 the expanded domain name exceeds 255 characters (the maximum length 1116 of a domain name), the left side is truncated to fit, by removing 1117 successive subdomains until the total length falls below 255 1118 characters. 1120 Uppercased macros are URL escaped. 1122 URL encoding is described in [RFC2396]. 1124 7.2 Expansion Examples 1126 The is strong-bad@email.example.com. 1127 The IPv4 SMTP client IP is 192.0.2.3. 1128 The IPv6 SMTP client IP is 5f05:2000:80ad:5800::1. 1129 The PTR domain name of the client IP is mx.example.org. 1131 macro expansion 1132 ------------------------------- 1133 %{s} strong-bad@email.example.com 1134 %{o} email.example.com 1135 %{d} email.example.com 1136 %{d4} email.example.com 1137 %{d3} email.example.com 1138 %{d2} example.com 1139 %{d1} com 1140 %{p} mx.example.org 1141 %{p2} example.org 1142 %{dr} com.example.email 1143 %{d2r} example.email 1144 %{l} strong-bad 1145 %{l-} strong.bad 1146 %{lr} strong-bad 1147 %{lr-} bad.strong 1148 %{l1r-} strong 1149 macro-string expansion 1150 --------------------------------------------------------------------- 1151 %{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com 1152 %{lr-}.lp._spf.%{d2} bad.strong.lp._spf.example.com 1154 %{lr-}.lp.%{ir}.%{v}._spf.%{d2} 1155 bad.strong.lp.3.2.0.192.in-addr._spf.example.com 1157 %{ir}.%{v}.%{l1r-}.lp._spf.%{d2} 1158 3.2.0.192.in-addr.strong.lp._spf.example.com 1160 %{p2}.trusted-domains.example.net 1161 example.org.trusted-domains.example.net 1163 IPv6: 1164 %{ir}.example.org 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8. 1165 5.d.a.0.8.0.0.0.2.5.0.f.5.example.org 1167 8. Conformance Definitions 1169 The following sections define SPF conformance applied to various 1170 entities. 1172 8.1 Introduction 1174 In an SMTP+SPF transaction, there are three primary entites: 1175 - the envelope sender domain 1176 - the sending host (the SMTP client) 1177 - the SMTP receiver 1179 The conformance status of each entity has implications for the 1180 transaction as a whole. 1182 8.2 Conformance with regard to sender domains 1184 For a domain to be considered SPF-conformant, its authoritative DNS 1185 servers are REQUIRED to publish an SPF record for that domain. 1186 Domains which do not publish SPF data SHALL NOT be deemed 1187 SPF-conformant. 1189 If foo.example.com claims SPF compliance, it must have a record of 1190 the form: 1192 foo.example.com IN TXT "v=spf1 ..." 1194 A domain also SHOULD publish policy records for each of its 1195 designated servers. 1197 8.3 Conformance with regard to sending e-mail systems 1199 To be considered SPF-conformant, an SMTP sending host MUST resolve a 1200 "pass" for all the SPF-conformant domains which appear in the "MAIL 1201 FROM" command. 1203 An SMTP sending host MUST also resolve a "pass" for all the 1204 SPF-conformant domains which appear in the "HELO" or "EHLO" command. 1206 If the domains used in MAIL FROM and in HELO/EHLO do not publish SPF 1207 information, an SMTP sending host is considered conformant by 1208 default. Only when those domains do publish SPF is the SMTP sending 1209 host required to resolve a "pass". 1211 For example: in a transaction where host mx01 emits: 1213 HELO mx01.example.com 1214 MAIL FROM: 1216 An SMTP+SPF receiver will attempt to find an SPF record at 1218 example.com TXT 1220 An SMTP+SPF receiver may also attempt to find an SPF record at 1222 mx01.example.com TXT 1224 If either query returns an SPF record, host mx01 MUST return a 1225 "pass" for that SPF test. 1227 8.4 Conformance with regard to receiving e-mail systems 1229 To describe itself as SPF-conformant, an SMTP receiver MUST perform 1230 SPF tests. 1232 SPF tests need not be performed while an SMTP transaction is ongoing: 1233 if the MDA performs the test, that is sufficient. A server need not 1234 reject a message; but if it does not, it SHOULD add a Received-SPF 1235 header. If a server rejects a message, it SHOULD include any 1236 provided by the SPF publisher. 1238 If a receiver system has a choice of testing the envelope sender (as 1239 recorded in the Return-Path header) versus the message headers (as 1240 recorded in Sender or From), the envelope is recommended. 1242 If the domain passed in the HELO command is a fully-qualified domain 1243 name, an SPF-conformant receiver MAY test that domain name. 1245 Receiver systems SHOULD exclude special recipients such as 1246 postmaster@ and abuse@ from SPF processing. See [RFC2142]. 1248 SPF is only one component in a policy engine. An SPF-conformant SMTP 1249 receiver is NOT REQUIRED to perform SPF tests on messages whose 1250 dispositions have already been decided on the basis of other policy. 1252 Example 1: if an SMTP receiver requires that sender domains must 1253 possess MX or A records, and rejects transactions where they do 1254 not, then SPF tests are moot. 1256 Example 2: if an SMTP receiver expects messages from a trusted 1257 client, such as a secondary MX for its own domain, then SPF tests 1258 are not needed. 1260 Example 3: if an SMTP receiver is considering a transaction which 1261 does not yield a fully-qualified domain name in either the MAIL 1262 FROM sender or the HELO command, SPF tests are not appropriate, and 1263 the disposition of the message should be decided on the basis of 1264 other policy. 1266 8.5 Conformance with regard to a particular SMTP transaction 1268 An email message during delivery is conformant if SPF evaluation 1269 results in a "pass", "neutral", or "softfail". 1271 8.6 Conformance with regard to an email-sending user 1273 An email-sending user is conformant if all of her outbound mail is 1274 sent through a designated mailer for her sender domain. 1276 8.7 Rejection of non-SPF conformant email 1278 Mail from a domain SHOULD NOT be automatically treated as suspect 1279 just because the domain doesn't publish SPF records. 1281 If SPF tests return an explicit "fail" result during processing, the 1282 receiver domain MAY reject, label, or classify the message as it 1283 wishes. If the message is rejected, the receiver domain SHOULD 1284 provide the "exp" string specified in section 5.2. 1286 8.8 Rejection of SPF conformant email 1288 An SPF email system MAY choose to reject or discard email on the 1289 basis of local policy. SPF is one component in an overall 1290 email-policy engine. SPF merely makes it possible for policy 1291 decisions to be made with confidence at the sender-domain level. The 1292 actual policy decisions are outside the scope of this document. 1294 8.9 Recommendations 1296 If a domain contains subdomains or hostnames that have A or MX 1297 records, those subdomains and hostnames SHOULD publish SPF records as 1298 well. If they do not, they remain at risk of forgery. 1300 Domain names used in a legitimate envelope sender SHOULD possess MX 1301 records. 1303 This proposal recommends the deprecation of the legacy "implicit 1304 MX" rule defined in [RFC2821] section 5. Domains that want to 1305 receive mail SHOULD always define explicit MX records. 1307 This proposal also recommends that HELO arguments SHOULD be 1308 fully-qualified domain names that resolve to the IP address of the 1309 sending MTA. 1311 8.10 Changes to Existing Semantics 1313 8.10.1 The Return-Path is now also a Responsible Sender 1315 From [RFC2821]: 1316 The portion of the first or only argument contains 1317 the source mailbox (between "<" and ">" brackets), which can be 1318 used to report errors (see section 4.2 for a discussion of error 1319 reporting). 1321 When SPF is used to authenticate the return-path, the domain in the 1322 source mailbox is now also considered accountable for injecting the 1323 message into the mailstream. 1325 This semantic change is justified by the desire to control joe-jobs. 1326 Joe jobs are a distributed denial of service attack against a given 1327 address executed by forging messages using a victim sender address 1328 and sending them to thousands of recipients. Inevitably, some of 1329 those delivery attempts fail, and bounce messages are generated to 1330 the victim sender address. These unwanted bounce messages can end up 1331 crippling the victim mailbox. SPF gives these potential victims a 1332 way to protect their mailboxes. With SPF, senders can now control 1333 the use of their address in the return-path. 1335 9. Applicability Statement 1337 This section discusses deployment considerations. 1339 9.1 Adoption by disreputable domains 1341 It is trivial for a domain to publish "+all" to allow all. A 1342 disreputable domain could then send unwanted email from any host. 1343 This is a common objection to SPF. 1345 SPF provides a value-neutral framework for sender authentication and 1346 accreditation. Senders use that framework to make assertions 1347 regarding the quality of messages. 1349 It is the responsibility of the SMTP receiver to evaluate those 1350 assertions. First the SMTP receiver discards obvious forgeries. 1351 Then it evaluates the remaining messages according to the reputation 1352 of the sender and any accompanying accreditation assertions. 1354 Whether a given domain is reputable or not is a decision that belongs 1355 to an SMTP receiver. Policy decisions regarding particular messages 1356 are outside the scope of SPF. 1358 9.2 Limitations 1360 In an SPF-conformant environment, envelope sender forgery is limited 1361 to the local domain. Unless per-user macros are used, it is possible 1362 for one user to forge another user's address within that domain. 1363 However, the organization responsible for the domain presumably has 1364 the wherewithal to follow an audit trail. 1366 9.3 Phased Rollout 1368 At an adopting domain, adoption of SPF could occur in phases. A 1369 domain might move through these phases by changing its default 1370 response type from "neutral" to "softfail" to "fail". 1372 The phases are characterized by different levels of awareness 1373 among the domain's userbase, and different levels of strictness on 1374 the part of SPF-conformant receivers. 1376 When a sufficient majority of its users are SPF-conformant, a 1377 domain SHOULD change its default to "-all". This constitutes a 1378 request to mail receivers to reject non-conformant mail. Setting 1379 "-all" protects the users from account fraud and joe-jobbing. 1381 Messages that explicitly fail SPF with a "fail" SHOULD be rejected. 1383 9.4 Verbatim Forwarding 1385 SPF changes the model of email from a store-and-forward system to an 1386 end-to-end system. Verbatim email forwarding suffers accordingly. 1388 In verbatim forwarding, an intermediate forwarding host rewrites the 1389 envelope recipient, but leaves the envelope sender untouched. 1391 There are two ways to preserve forwarding functionality under SPF. 1392 Either forwarders can change to remailing, or receiver systems can 1393 whitelist forwarders. 1395 In remailing, forwarding hosts rewrite the return-path address. 1396 The rewritten envelope sender can take a variety of forms, depending 1397 on whether bounces should be forwarded back to the original sender. 1398 If bounces are unimportant, the rewritten sender could be as simple 1399 as . If bounces are important, forwarders can 1400 use envelope encapsulation with a MAC nonce, or rewrite the address 1401 into a database-backed cookie. 1403 If return-path rewriting is not feasible, receiver systems can simply 1404 whitelist trusted sites which are known to forward mail to local 1405 receivers. 1407 9.5 Per-user exemptions 1409 The "exists" mechanism can be used to exempt certain users from the 1410 SPF requirements that apply to the rest of the domain. 1412 10. Security Considerations 1414 SPF depends on DNS. A malicious attacker could poison a target's DNS 1415 cache with spoofed DNS data. 1417 SPF assumes the client IP address is true. A malicious attacker 1418 could spoof TCP sequences to make mail appear to come from a 1419 designated host. If this happens, an "echo" command could be 1420 introduced to ESMTP to require a simple challenge/response 1421 confirmation. 1423 SPF clients need to limit the number of includes and redirects to 1424 avoid attacks. Implementations are required to follow recursion to a 1425 minimum of 20. 1427 11. IANA Considerations 1429 The registry of standard mechanism and modifier names may be turned 1430 over to IANA for management. 1432 12. Contributors and Acknowledgements 1434 SPF owes a debt of parentage to RMX (by Hadmut Danisch in 2003) and to 1435 DMP (by Gordon Fecyk in 2003). It traces its ancestry farther back 1436 through "Repudiating Mail-From" by Paul Vixie in 2002 to a suggestion 1437 by Jim Miller in 1998. 1439 Philip Gladstone contributed macros to the specification, multiplying 1440 the expressiveness of the language and making per-user and per-IP 1441 lookups possible. 1443 The authors would also like to thank the following individuals who 1444 contributed to, critically reviewed, or otherwise furthered the 1445 development of this specification. The authors wish to apologize in 1446 advance for any omissions. 1448 Jameel Akari, Marc Alaia, Dave Alden, Tom Allison, Eric Allman, 1449 Justo Alonso, Mark Anderson, Matthias Andree, Don Andrews, 1450 Mohammad Arca, Aredridel, William Astle, Bob Atkinson, Roy Badami, 1451 Andy Bakun, Derek J. Balling, Arik Baratz, Graham Barr, Matthew 1452 Barr, Ernesto Baschny, Mike Batchelor, Peter Baumann, Steven 1453 Bellovin, Jon Bertrand, Paul Blair, Andrew Boling, Richard 1454 Bollinger, Dan Boresjo, Nicolas Bougues, Daniel Bourque, Jeremy 1455 T. Bouse, Raymond S Brand, Seth Breidbart, David Brodbeck, Neil 1456 Brown, Zack Brown, Michael R. Brumm, Jason Buchanan, Jasmin 1457 Buchert, Ted Cabeen, Dave Camp, Anthony Campbell, Bryan Campbell, 1458 Brian Candler, John Capo, Dennis Carr, L. Carver, Lee Carver, Ian 1459 Castle, Jose Celestino, Christopher Chan, Jason Chen, Joe Christy, 1460 Andrew Church, Greg Cirino, Bradley Cloete, James H. Cloos Jr., 1461 Bill Cole, Brian Coloney, Sean Comeau, Greg Connor, Erik Corry, Dj 1462 Coster, James Couzens, Chris Cowherd, Dave Crocker, Arlie Davis, 1463 Alan DeKok, Mark Delany, Kitt Diebold, Mark Jason Dominus, Andrew 1464 W. Donoho, William H. Dorell, Jeremy Doupe, Lilia Downs, Chris 1465 Drake, Jesus Duarte, Viktor Duchovni, Lars B. Dybdahl, David 1466 Dyer-Bennet, Lyndon Eaton, Henrik Edlund, William Elan, Matthew 1467 Elvey, Stefan Engelbert, Shaun T. Erickson, Ray Everett-Church, 1468 Mark Farver, Nick Fields, Guillaume Filion, Tony Finch, Cary 1469 Fitch, Gustav Foseid, Mark Foster, Steven Foster, Benjamin Franz, 1470 Tim Freeman, Tugrul Galatali, Stuart D. Gathman, Fotis Georgatos, 1471 Richard George, Oliver Gerler, Dean Gibson, B. Gingery, Eric 1472 Girard, Tim Gladding, Philip Gladstone, Etta Good, Seth Goodman, 1473 Gabriel Granger, Ben Greear, Bob Greene, Ronald F. Guilmette, 1474 Phillip Hallam-Baker, Clifford Hammerschmidt, Catherine Hampton, 1475 Ask Bjoern Hansen, Richard Hansen, Howard Lee Harkness, Thomas 1476 Harold, Edward Ned Harvey, Ned Harvey, Brian Hatch, Refugio 1477 Hayden, Philip Hazel, Zan Hecht, Eric Helfgott, George Herson, 1478 Greg Hewgill, Alan Hodgson, Vidar Holen, Sam Horrocks, Phil 1479 Howard, Paul Howarth, Anthony Howe, Marc Hudson, John Hughes, Kenn 1480 Humborg, Adam Hunt, Carl Hutzler, Paul Iadonisi, Lars Magne 1481 Ingebrigtsen, Aditya Ivaturi, Mitcheal Jackmoore, Jeremy Jackson, 1482 Bryce Jasmer, Mark Jeftovic, Jim Jobe, B. Johannessen, Thomas H 1483 Jones II, Nico Kadel-Garcia, Rob Kaper, Phil Karn, Harry Katz, Lou 1484 Katz, Richard Kay, Izzy Kindred, Alain Knaff, Don Koch, Kevin 1485 Kolk, Tomasz Konefal, Thor Kooda, Karl Kraft, Andreas Kreuzinger, 1486 Russell Kroll, Carsten Kuckuk, Jon Kyme, Ty Lammy, Bill Landry, 1487 Mark Lentczner, Nate Leon, Andy Lester, John R Levine, Jon 1488 Loeliger, Will Lowe, Dave Lugo, Jim Lyon, Marty Lyons, Vivien M., 1489 Daniel Mack, Dr Belo Madu, Lee Maguire, Ryan Malayter, Walt 1490 Mankowski, Marrandy, K.F.J. Martens, John A. Martin, Tracy Martin, 1491 Justin Mason, Jeroen Massar, Mike McCandless, Joel McClung, Chuck 1492 Mead, Tim Meadowcroft, Julian Mehnle, Cyrus Mehta, Michael Meier, 1493 Scott Merrill, Nigel Metheringham, Bob Miller, Nelson Minica, Anne 1494 Mitchell, George Mitchell, Dr. Ernst Molitor, Michael Fischer 1495 V. Mollard, Philipp Morger, Roger Moser, der Mouse, Matthew 1496 Mucker, Simon J Mudd, Graham Murray, Dan Nadir, Alain Nakache, 1497 Brian Nelson, Scott Nelson, Sam Norris, Daryl Odnert, Leonard Orb, 1498 Steven W. Orr, Seun Osewa, Gerald Oskoboiny, Harry Palmer, John 1499 Payne, Hans Dieter Pearcey, Randy Pearson, Matt Perry, R. Scott 1500 Perry, Kevin Peuhkurinen, Nick Phillips, Richard Pitt, Jordan 1501 Pollack, Bob Poortinga, Jim Popovitch, Kenneth Porter, Bob Proulx, 1502 Loic Prylli, Rich Puhek, Nils Puhlmann, James Pullicino, Jeremy 1503 Pullicino, Daniel Quinlan, Ramakanta, Suresh Ramasubramanian, Jim 1504 Ramsay, Eric S. Raymond, Kevin Reed, Alan Reider, Joe Rhett, Bill 1505 Rockefeller, Daniel Roethlisberger, Andrew Rose, Alex Rosen, David 1506 Saez, Hector Santos, Christophe Saout, Scott Savarese, Wayne 1507 Schlitt, George Schlossnagle, Theo Schlossnagle, Stuart Schneider, 1508 Neil Schwartzman, Frank Segtrop, Klaus Alexander Seistrup, Will 1509 Senn, Matt Sergeant, Yakov Shafranovich, Shevek, Mark Shewmaker, 1510 G. Roderick Singleton, Fridrik Skulason, Martin H. Sluka, Andy 1511 Smith, Karl J. Smith, Larry Smith, Steven Earl Smith, Richard 1512 Soderberg, Rolf E. Sonneveld, Robert Spier, Jonathan Steinert, 1513 Thomas R. Stephenson, Rick Stewart, Andrew Sweger, Bob Tanner, 1514 Daniel Taylor, Brad Templeton, Rahul Tongia, Laszlo Toth, Dustin 1515 D. Trammell, Mark Tranchant, Philip Tucker, Alex Van Den Bogaerdt, 1516 Dirk Van Mieghem, Rik Van Riel, Theo Van Dinter, Wietse Venema, 1517 Kelson Vibber, Peter Viertel, Paul Vixie, Martin Treusch Von 1518 Buttlar, Graham Wager, Matthew Walker, Jasper Wallace, John 1519 Warren, Odhiambo Washington, Terence Way, George Webb, Wechsler, 1520 Rick Wesson, Casey West, Peter Westlake, Nathan Wharton, David 1521 A. Wheeler, Weldon Whipple, Phil White, Sanford Whiteman, Colin 1522 Whittaker, Tim Wilde, Jan Wildeboer, Dan Willett Sr., 1523 Steven G. Willis, Chuck Wolber, David Woodhouse, Simon Woodward, 1524 Greg Wooledge, Paul Wouters, Samson Yormie, Zolta'N Za'Mbori, Joe 1525 Zasada, and Lloyd Zusman. 1527 The folks on the SPAM-L mailing list. 1528 The folks on the SPAM-L mailing list. 1529 The folks on the ASRG and MARID/MXCOMP mailing lists. 1530 The folks on the spf-discuss mailing list. 1531 The folks on the mailing list that shall not be named. 1532 The folks on #perl. 1534 Appendix A. Collected ABNF for SPF records 1536 This section is normative and any discrepancies with the ABNF fragments 1537 in the preceding text are to be resolved in favor of this grammar. 1539 See [RFC2234] for ABNF notation. 1541 SPF-record = version *( 1*SP ( directive / modifier ) ) *SP 1543 version = "v=spf" 1*DIGIT 1545 directive = [ prefix ] mechanism 1546 prefix = "+" / "-" / "?" / "~" 1547 modifier = redirect / explanation / unknown-modifier 1548 redirect = "redirect" "=" domain-spec 1549 explanation = "exp" "=" domain-spec 1550 unknown-modifier = name "=" macro-string 1552 mechanism = ( all / include 1553 / A / MX / PTR / IP4 / IP6 / exists 1554 / extension ) 1556 all = "all" 1557 include = "include" ":" domain-spec 1558 A = "a" [ ":" domain-spec ] [ dual-cidr-length ] 1559 MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] 1560 PTR = "ptr" [ ":" domain-spec ] 1561 IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] 1562 IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] 1563 exists = "exists" ":" domain-spec 1565 extension = name [ ":" macro-string ] 1567 ip4-network = as in [RFC2373] [15], e.g. 192.0.2.0 1568 ip6-network = as in [RFC2373] [15], e.g. 12AB:0:0:CD30 1570 domain-spec = domain-name / macro-string 1571 domain-name = domain-part *( "." domain-part ) [ "." ] 1572 domain-part = as defined in [RFC1034] 1574 dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] 1575 ip4-cidr-length = "/" 1*DIGIT 1576 ip6-cidr-length = "/" 1*DIGIT 1578 macro-string = *( macro-char / VCHAR ) 1579 macro-char = ( "%{" ALPHA transformer *delimiter "}" ) 1580 / "%%" / "%_" / "%-" 1581 transformer = [ *DIGIT ] [ "r" ] 1582 name = alpha *( alpha / digit / "-" / "_" / "." ) 1583 delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" 1585 Appendix B. Extended Examples 1587 These examples are based on the following DNS setup: 1589 ; A domain with two mail servers, two hosts 1590 ; and two servers at the domain name 1592 $ORIGIN example.com. 1593 @ MX 10 mail-a 1594 MX 20 mail-b 1595 A 192.168.1.10 1596 A 192.168.1.11 1597 amy A 192.168.1.65 1598 bob A 192.168.1.66 1599 mail-a A 192.168.1.129 1600 mail-b A 192.168.1.130 1601 www CNAME example.com. 1603 ; The reverse IP for that domain 1605 $ORIGIN 1.168.192.in-addr.arpa. 1606 10 PTR example.com. 1607 11 PTR example.com. 1608 65 PTR amy.example.com. 1609 66 PTR bob.example.com. 1610 129 PTR mail-a.example.com. 1611 130 PTR mail-b.example.com. 1613 ; A related domain 1615 $ORIGIN example.org 1616 @ MX 10 mail-c 1617 mail-c A 192.168.2.140 1619 ; The reverse IP for that domain 1621 $ORIGIN 2.168.192.in-addr.arpa. 1622 140 PTR mail-c.example.org. 1624 ; A rogue reverse IP domain that claims to be 1625 ; something it's not 1627 $ORIGIN 0.0.10.in-addr.arpa. 1628 4 PTR bob.example.com. 1630 Appendix B.1 Simple Example 1632 If is "example.com", then this describes the 1633 effect various possible SPF records for example.com would have 1634 on various 1636 "v=spf1 +all" 1637 -- any mail message passes 1639 "v=spf1 a -all" 1640 -- sending hosts 192.168.1.10 and 192.168.1.11 pass 1642 "v=spf1 a:example.org -all" 1643 -- no sending hosts pass since example.org has no A records 1645 "v=spf1 mx -all" 1646 -- sending hosts 192.168.1.129 and 192.168.1.130 pass 1648 "v=spf1 mx:example.org -all" 1649 -- sending host 192.168.2.140 passes 1651 "v=spf1 mx mx:example.org -all" 1652 -- sending hosts 192.168.1.129, 192.168.1.130, 1653 and 192.168.2.140 pass 1655 "v=spf1 mx/24 mx:example.org/24 -all" 1656 -- any sending host in 192.168.1.0/24 or 192.168.2.0/24 passes 1658 "v=spf1 ptr -all" 1659 -- sending host 192.168.1.65 passes 1660 (reverse IP is valid and in example.com) 1661 -- sending host 192.168.2.140 fails 1662 (reverse IP is valid, but not in example.com) 1663 -- sending host 10.0.0.4 fails 1664 (reverse IP is not valid) 1666 "v=spf1 ip4:192.168.1.128/25 -all" 1667 -- sending host 192.168.1.65 fails 1668 -- sending host 192.168.1.129 passes 1670 Appendix B.2 Multiple Domain Examples 1672 These examples show the effect of related SPF records: 1674 example.org: "v=spf1 include:example.com include:example.net -all" 1676 This SPF record would be used if mail from example.org actually came 1677 through servers at example.com and example.net. Example.org's 1678 designated servers are the union of example.com and example.net's 1679 designated servers. 1681 1.example.org: "v=spf1 redirect=example.org" 1682 2.example.org: "v=spf1 redirect=example.org" 1683 3.example.org: "v=spf1 redirect=example.org" 1685 These SPF records allow a set of domains that all use the same 1686 mail system to make use of that mail system's SPF record. In this 1687 way, only the mail system's SPF record needs to updated when 1688 the mail setup changes. These domains' SPF records never have to 1689 change. 1691 Appendix B.3 RBL Style Example 1693 Imagine that, in addition to the domain records listed above, 1694 there are these: 1696 $Origin _spf.example.com. 1697 mary.mobile-users A 127.0.0.2 1698 fred.mobile-users A 127.0.0.2 1699 15.15.168.192.joel.remote-users A 127.0.0.2 1700 16.15.168.192.joel.remote-users A 127.0.0.2 1702 The following SPF records describe users at example.com who mail 1703 from arbitrary servers, or who mail from personal servers. 1705 example.com: 1706 "v=spf1 mx 1707 include:mobile-users._spf.%{d} 1708 include:remote-users._spf.%{d} -all" 1710 mobile-users._spf.example.com: 1711 "v=spf1 exists:%{l1r+}.%{d}" 1713 remote-users._spf.example.com: 1714 "v=spf1 exists:%{ir}.%{l1r+}.%{d}" 1716 Normative References 1718 [RFC2396] 1720 Informative References 1722 [RFC1034] 1723 [RFC1464] 1724 [RFC2119] 1725 [RFC2142] 1726 [RFC2234] 1727 [RFC2373] 1728 [RFC2505] 1729 [RFC2821] 1730 [RFC2822] 1732 Danisch, Hadmut. 1733 "The RMX DNS RR Type for light weight sender authentication", 1734 http://www.danisch.de/work/security/antispam.html, October 2003, 1735 Work In Progress. 1737 Fecyk, Gordon. "Designated Mailers Protocol", December 2003, 1738 Work In Progress. http://www.pan-am.ca/dmp/ 1740 Wong, M.W., "Sender Rewriting Scheme", Work In Progress, 1741 http://spf.pobox.com/srs.html 1743 DeKok, Alan. The LMAP discussion document. 1745 Vixie, Paul. "Repudiating Mail-From". 1746 http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00658.html 1748 http://nospam.couchpotato.net/ 1750 http://asrg.sp.am/ 1752 http://www.ietf.org/html.charters/marid-charter.html 1754 Authors 1756 Meng Weng Wong 1757 Singapore 1758 mengwong+spf@pobox.com 1760 Mark Lentczner 1761 1209 Villa Street 1762 Mountain View, CA 94041 1763 United States of America 1764 markl@glyphic.com 1766 Comments on this draft are welcome. In the interests of openness, 1767 before contacting the authors directly, please post to the 1768 spf-discuss mailing list. 1770 To join the mailing list, please see 1771 http://spf.pobox.com/mailinglist.html 1773 Developers of SPF-conformant software SHOULD join the spf-devel 1774 mailing list. They also SHOULD consult the SPF Developers Guide at 1775 http://spf.pobox.com/developers-guide.html. While specifications 1776 published as RFCs are relatively static, the mailing list and 1777 developers guide are living resources. They augment this core 1778 protocol specification with generally accepted implementation 1779 practices which are outside the scope of this document. They also 1780 provide a forum for interoperability testing.