idnits 2.17.1 draft-ietf-spfbis-4408bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1246 has weird spacing: '...pe-from the e...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 5, 2012) is 4285 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CFWS' is mentioned on line 2070, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' -- Obsolete informational reference (is this intentional?): RFC 4408 (Obsoleted by RFC 7208) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Kitterman 3 Internet-Draft Agari 4 Obsoletes: 4408 (if approved) July 5, 2012 5 Intended status: Standards Track 6 Expires: January 6, 2013 8 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, 9 Version 1 10 draft-ietf-spfbis-4408bis-03.txt 12 Abstract 14 E-mail on the Internet can be forged in a number of ways. In 15 particular, existing protocols place no restriction on what a sending 16 host can use as the reverse-path of a message or the domain given on 17 the SMTP HELO/EHLO commands. This document describes version 1 of 18 the Sender Policy Framework (SPF) protocol, whereby a domain can 19 explicitly authorize the hosts that are allowed to use its domain 20 name, and a receiving host can check such authorization. This 21 document obsoletes RFC4408. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 6, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1.1. Protocol Status . . . . . . . . . . . . . . . . . . . . . 5 71 1.2. Experimental History . . . . . . . . . . . . . . . . . . . 6 72 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 73 1.3.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . 6 74 1.3.2. Imported Definitions . . . . . . . . . . . . . . . . . 6 75 1.3.3. Mail From Definition . . . . . . . . . . . . . . . . . 6 76 1.3.4. Deprecated . . . . . . . . . . . . . . . . . . . . . . 7 77 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 2.1. The HELO Identity . . . . . . . . . . . . . . . . . . . . 8 79 2.2. The MAIL FROM Identity . . . . . . . . . . . . . . . . . . 8 80 2.3. Publishing Authorization . . . . . . . . . . . . . . . . . 8 81 2.4. Checking Authorization . . . . . . . . . . . . . . . . . . 9 82 2.5. Interpreting the Result . . . . . . . . . . . . . . . . . 10 83 2.5.1. None . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 2.5.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 11 85 2.5.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 2.5.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 2.5.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . 11 88 2.5.6. TempError . . . . . . . . . . . . . . . . . . . . . . 12 89 2.5.7. PermError . . . . . . . . . . . . . . . . . . . . . . 12 90 3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 3.1. Publishing . . . . . . . . . . . . . . . . . . . . . . . . 13 92 3.1.1. DNS Resource Records . . . . . . . . . . . . . . . . . 13 93 3.1.2. Multiple DNS Records . . . . . . . . . . . . . . . . . 14 94 3.1.3. Multiple Strings in a Single DNS record . . . . . . . 14 95 3.1.4. Record Size . . . . . . . . . . . . . . . . . . . . . 14 96 3.1.5. Wildcard Records . . . . . . . . . . . . . . . . . . . 14 97 4. The check_host() Function . . . . . . . . . . . . . . . . . . 16 98 4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 16 99 4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 16 100 4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 16 101 4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 17 102 4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 17 103 4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 17 104 4.6.1. Term Evaluation . . . . . . . . . . . . . . . . . . . 18 105 4.6.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 18 106 4.6.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . 19 107 4.6.4. Evaluation Limits . . . . . . . . . . . . . . . . . . 19 108 4.7. Default Result . . . . . . . . . . . . . . . . . . . . . . 19 109 4.8. Domain Specification . . . . . . . . . . . . . . . . . . . 20 110 5. Mechanism Definitions . . . . . . . . . . . . . . . . . . . . 21 111 5.1. "all" . . . . . . . . . . . . . . . . . . . . . . . . . . 21 112 5.2. "include" . . . . . . . . . . . . . . . . . . . . . . . . 22 113 5.3. "a" . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 114 5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 115 5.5. "ptr" (deprecated) . . . . . . . . . . . . . . . . . . . . 24 116 5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 25 117 5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 26 118 6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 27 119 6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 27 120 6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 28 121 7. The Received-SPF Header Field . . . . . . . . . . . . . . . . 30 122 8. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 123 8.1. Macro Definitions . . . . . . . . . . . . . . . . . . . . 32 124 8.2. Expansion Examples . . . . . . . . . . . . . . . . . . . . 35 125 9. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 36 126 9.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 36 127 9.1.1. DNS Resource Considerations . . . . . . . . . . . . . 36 128 9.1.2. Administrator's Considerations . . . . . . . . . . . . 37 129 9.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 37 130 9.2.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . 37 131 9.2.2. Forwarding Services and Aliases . . . . . . . . . . . 37 132 9.3. Mail Services . . . . . . . . . . . . . . . . . . . . . . 39 133 9.4. MTA Relays . . . . . . . . . . . . . . . . . . . . . . . . 40 134 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 135 10.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 41 136 10.2. SPF-Authorized Email May Contain Other False Identities . 41 137 10.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 42 138 10.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 42 139 10.5. Untrusted Information Sources . . . . . . . . . . . . . . 42 140 10.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 43 141 11. Contributors and Acknowledgements . . . . . . . . . . . . . . 44 142 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 143 12.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 45 144 12.2. The Received-SPF Mail Header Field . . . . . . . . . . . . 45 145 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 146 13.1. Normative References . . . . . . . . . . . . . . . . . . . 46 147 13.2. Informative References . . . . . . . . . . . . . . . . . . 47 148 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 49 149 Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 52 150 B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 52 151 B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 53 152 B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 54 153 B.4. Multiple Requirements Example . . . . . . . . . . . . . . 54 154 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 55 155 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 57 157 1. Introduction 159 The current email infrastructure has the property that any host 160 injecting mail into the mail system can identify itself as any domain 161 name it wants. Hosts can do this at a variety of levels: in 162 particular, the session, the envelope, and the mail headers. 163 Although this feature is desirable in some circumstances, it is a 164 major obstacle to reducing Unsolicited Bulk email (UBE, aka spam). 165 Furthermore, many domain name holders are understandably concerned 166 about the ease with which other entities can make use of their domain 167 names, often with malicious intent. 169 This document defines a protocol by which domain owners can authorize 170 hosts to use their domain name in the "MAIL FROM" or "HELO" identity. 171 Compliant domain holders publish Sender Policy Framework (SPF) 172 records specifying which hosts are permitted to use their names, and 173 compliant mail receivers use the published SPF records to test the 174 authorization of sending Mail Transfer Agents (MTAs) using a given 175 "HELO" or "MAIL FROM" identity during a mail transaction. 177 An additional benefit to mail receivers is that after the use of an 178 identity is verified, local policy decisions about the mail can be 179 made based on the sender's domain, rather than the host's IP address. 180 This is advantageous because reputation of domain names is likely to 181 be more accurate than reputation of host IP addresses. Furthermore, 182 if a claimed identity fails verification, local policy can take 183 stronger action against such email, such as rejecting it. 185 1.1. Protocol Status 187 SPF has been in development since the summer of 2003 and has seen 188 deployment beyond the developers beginning in December 2003. The 189 design of SPF slowly evolved until the spring of 2004 and has since 190 stabilized. There have been quite a number of forms of SPF, some 191 written up as documents, some submitted as Internet Drafts, and many 192 discussed and debated in development forums. The protocol was 193 originally documented in [RFC4408], which this memo replaces. 195 The goal of this document is to clearly document the protocol defined 196 by earlier draft specifications of SPF as used in existing 197 implementations. This conception of SPF is sometimes called "SPF 198 Classic". It is understood that particular implementations and 199 deployments will differ from, and build upon, this work. It is hoped 200 that we have nonetheless captured the common understanding of SPF 201 version 1. 203 1.2. Experimental History 205 This document updates and replaces RFC 4408 that was part of a group 206 of simultaneously published Experimental RFCs (RFC 4405, RFC 4406, 207 RFC 4407, and RFC 4408) in 2006. At that time the IESG requested the 208 community observe the success or failure of the two approaches 209 documented in these RFCs during the two years following publication, 210 in order that a community consensus can be reached in the future. 212 SPF is widely deployed by large and small email providers alike. 213 There are multiple, interoperable implementations. 215 For SPF (as documented in RFC 4408) a careful effort was made to 216 collect and document lessons learned and errata during the two year 217 period. The errata list has been stable (no new submissions) and 218 only minor protocol lessons learned were identified. Resolution of 219 the IESG's experiment is documented in 220 [draft-ietf-spfbis-experiment]. 222 1.3. Terminology 224 1.3.1. Keywords 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 227 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 228 "OPTIONAL" in this document are to be interpreted as described in 229 [RFC2119]. 231 1.3.2. Imported Definitions 233 The ABNF tokens "ALPHA", "DIGIT", and "SP" are defined in [RFC5234]. 235 The token "local-part" is defined in [RFC5321]. 237 "dot-atom", "quoted-string", "comment", "CFWS", "FWS", and "CRLF" are 238 defined in [RFC5322] 240 1.3.3. Mail From Definition 242 This document is concerned with the portion of a mail message 243 commonly called "envelope sender", "return path", "reverse path", 244 "bounce address", "5321 FROM", or "MAIL FROM". Since these terms are 245 either not well defined or often used casually, this document defines 246 the "MAIL FROM" identity in Section 2.2. Note that other terms that 247 might superficially look like the common terms, such as "reverse- 248 path", are used only with the defined meanings from normative 249 documents. 251 1.3.4. Deprecated 253 There are several [RFC4408] features that are marked "deprecated". 254 In the context of this document, deprecated means that senders SHOULD 255 NOT publish SPF records that make use of the feature in question. 256 Its use is NOT RECOMMENDED and it might be removed entirely in future 257 updates to the protocol. Such features do, however, remain part of 258 the SPF protocol and receiving systems MUST support them unless this 259 specification says otherwise. 261 2. Operation 263 2.1. The HELO Identity 265 The "HELO" identity derives from either the SMTP HELO or EHLO command 266 (see [RFC5321]). These commands supply the SMTP client (sending 267 host) for the SMTP session. Note that requirements for the domain 268 presented in the EHLO or HELO command are not always clear to the 269 sending party, and SPF clients must be prepared for the "HELO" 270 identity to be malformed or an IP address literal. At the time of 271 this writing, many legitimate emails are delivered with invalid HELO 272 domains. 274 It is RECOMMENDED that SPF clients not only check the "MAIL FROM" 275 identity, but also separately check the "HELO" identity by applying 276 the check_host() function (Section 4) to the "HELO" identity as the 277 . 279 2.2. The MAIL FROM Identity 281 The "MAIL FROM" identity derives from the SMTP MAIL command (see 282 [RFC5321]). This command supplies the "reverse-path" for a message, 283 which generally consists of the sender mailbox, and is the mailbox to 284 which notification messages are to be sent if there are problems 285 delivering the message. 287 [RFC5321] allows the reverse-path to be null (see Section 4.5.5 in 288 RFC 5321). In this case, there is no explicit sender mailbox, and 289 such a message can be assumed to be a notification message from the 290 mail system itself. When the reverse-path is null, this document 291 defines the "MAIL FROM" identity to be the mailbox composed of the 292 localpart "postmaster" and the "HELO" identity (which might or might 293 not have been checked separately before). 295 SPF clients MUST check the "MAIL FROM" identity if a completed "HELO" 296 check has not reached a definitive policy result by applying the 297 check_host() function to the "MAIL FROM" identity as the . 299 2.3. Publishing Authorization 301 An SPF-compliant domain MUST publish a valid SPF record as described 302 in Section 3. This record authorizes the use of the domain name in 303 the "HELO" and "MAIL FROM" identities by the MTAs it specifies. 305 If domain owners choose to publish SPF records, it is RECOMMENDED 306 that they end in "-all", or redirect to other records that do, so 307 that a definitive determination of authorization can be made. 309 Domain holders can publish SPF records that explicitly authorize no 310 hosts if mail should never originate using that domain. 312 When changing SPF records, care must be taken to ensure that there is 313 a transition period so that the old policy remains valid until all 314 legitimate email has been checked. 316 2.4. Checking Authorization 318 A mail receiver can perform a set of SPF checks for each mail message 319 it receives. An SPF check tests the authorization of a client host 320 to emit mail with a given identity. Typically, such checks are done 321 by a receiving MTA, but can be performed elsewhere in the mail 322 processing chain so long as the required information is available and 323 reliable. At least the "MAIL FROM" identity MUST be checked, but it 324 is RECOMMENDED that the "HELO" identity also be checked beforehand. 326 Without explicit approval of the domain owner, checking other 327 identities against SPF version 1 records is NOT RECOMMENDED because 328 there are cases that are known to give incorrect results. For 329 example, almost all mailing lists rewrite the "MAIL FROM" identity 330 (see Section 9.2.1), but some do not change any other identities in 331 the message. The scenario described in Section 9.2.2, sub-section 332 1.2, is another example. Documents that define other identities 333 should define the method for explicit approval. 335 It is possible that mail receivers will use the SPF check as part of 336 a larger set of tests on incoming mail. The results of other tests 337 might influence whether or not a particular SPF check is performed. 338 For example, finding the sending host's IP address on a local white 339 list might cause all other tests to be skipped and all mail from that 340 host to be accepted. 342 When a mail receiver decides to perform an SPF check, it MUST use a 343 correctly-implemented check_host() function (Section 4) evaluated 344 with the correct parameters. Although the test as a whole is 345 optional, once it has been decided to perform a test it must be 346 performed as specified so that the correct semantics are preserved 347 between publisher and receiver. 349 To make the test, the mail receiver MUST evaluate the check_host() 350 function with the arguments set as follows: 352 - the IP address of the SMTP client that is emitting the 353 mail, either IPv4 or IPv6. 355 - the domain portion of the "MAIL FROM" or "HELO" identity. 357 - the "MAIL FROM" or "HELO" identity. 359 Note that the argument might not be a well-formed domain 360 name. For example, if the reverse-path was null, then the EHLO/HELO 361 domain is used, with its associated problems (see Section 2.1). In 362 these cases, check_host() is defined in Section 4.3 to return a 363 "none" result. 365 Although invalid, malformed, or non-existent domains cause SPF checks 366 to return "none" because no SPF record can be found, it has long been 367 the policy of many MTAs to reject email from such domains, especially 368 in the case of invalid "MAIL FROM". Rejecting email will prevent one 369 method of circumventing of SPF records. 371 Implementations must take care to correctly extract the from 372 the data given with the SMTP MAIL FROM command as many MTAs will 373 still accept such things as source routes (see [RFC5321], Appendix 374 C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). 375 These archaic features have been maliciously used to bypass security 376 systems. 378 2.5. Interpreting the Result 380 This section describes how software that performs the authorization 381 should interpret the results of the check_host() function. The 382 authorization check SHOULD be performed during the processing of the 383 SMTP transaction that sends the mail. This allows errors to be 384 returned directly to the sending MTA by way of SMTP replies. 386 Performing the authorization after the SMTP transaction has finished 387 can cause problems, such as the following: (1) It might be difficult 388 to accurately extract the required information from potentially 389 deceptive headers; (2) legitimate email might fail because the 390 sender's policy had since changed. 392 Generating non-delivery notifications to forged identities that have 393 failed the authorization check is generally abusive and against the 394 explicit wishes of the identity owner. 396 2.5.1. None 398 A result of "none" means that no records were published by the domain 399 or that no checkable sender domain could be determined from the given 400 identity. The checking software cannot ascertain whether or not the 401 client host is authorized. 403 2.5.2. Neutral 405 The domain owner has explicitly stated that he cannot or does not 406 want to assert whether or not the IP address is authorized. A 407 "neutral" result MUST be treated exactly like the "none" result; the 408 distinction exists only for informational purposes. Treating 409 "neutral" more harshly than "none" would discourage domain owners 410 from testing the use of SPF records (see Section 9.1). 412 2.5.3. Pass 414 A "pass" result means that the client is authorized to inject mail 415 with the given identity. The domain can now, in the sense of 416 reputation, be considered responsible for sending the message. 417 Further policy checks can now proceed with confidence in the 418 legitimate use of the identity. 420 2.5.4. Fail 422 A "fail" result is an explicit statement that the client is not 423 authorized to use the domain in the given identity. The checking 424 software can choose to mark the mail based on this or to reject the 425 mail outright. 427 If the checking software chooses to reject the mail during the SMTP 428 transaction, then it SHOULD use an SMTP reply code of 550 (see 429 [RFC5321]) and, if supported, the 5.7.1 enhanced status code (see 430 [RFC3463]), in addition to an appropriate reply text. The 431 check_host() function will return either a default explanation string 432 or one from the domain that published the SPF records (see 433 Section 6.2). If the information does not originate with the 434 checking software, it should be made clear that the text is provided 435 by the sender's domain. For example: 437 550-5.7.1 SPF MAIL FROM check failed: 438 550-5.7.1 The domain example.com explains: 439 550 5.7.1 Please see http://www.example.com/mailpolicy.html 441 2.5.5. Softfail 443 A "softfail" result should be treated as somewhere between a "fail" 444 and a "neutral". The domain believes the host is not authorized but 445 is not willing to make that strong of a statement. Receiving 446 software SHOULD NOT reject the message based solely on this result, 447 but MAY subject the message to closer scrutiny than normal. 449 The domain owner wants to discourage the use of this host and thus 450 desires limited feedback when a "softfail" result occurs. For 451 example, the recipient's Mail User Agent (MUA) could highlight the 452 "softfail" status, or the receiving MTA could give the sender a 453 message using greylisting, [RFC6647], with a note the first time the 454 message is received, but accept it on a later attempt based on 455 receiver policy. 457 2.5.6. TempError 459 A "temperror" result means that the SPF client encountered a 460 transient error while performing the check. Checking software can 461 choose to accept or temporarily reject the message. If the message 462 is rejected during the SMTP transaction for this reason, the software 463 SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 464 enhanced status code. 466 2.5.7. PermError 468 A "permerror" result means that the domain's published records could 469 not be correctly interpreted. This signals an error condition that 470 requires manual intervention to be resolved, as opposed to the 471 temperror result. If the message is rejected during the SMTP 472 transaction for this reason, the software SHOULD use an SMTP reply 473 code of 550 and, if supported, the 5.5.2 enhanced status code. Be 474 aware that if the domain owner uses macros (Section 8), it is 475 possible that this result is due to the checked identities having an 476 unexpected format. 478 3. SPF Records 480 An SPF record is a DNS Resource Record (RR) that declares which hosts 481 are, and are not, authorized to use a domain name for the "HELO" and 482 "MAIL FROM" identities. Loosely, the record partitions all hosts 483 into permitted and not-permitted sets (though some hosts might fall 484 into neither category). 486 The SPF record is a single string of text. An example record is the 487 following: 489 v=spf1 +mx a:colo.example.com/28 -all 491 This record has a version of "spf1" and three directives: "+mx", 492 "a:colo.example.com/28" (the + is implied), and "-all". 494 3.1. Publishing 496 Domain owners wishing to be SPF compliant must publish SPF records 497 for the hosts that are used in the "MAIL FROM" and "HELO" identities. 498 The SPF records are placed in the DNS tree at the host name it 499 pertains to, not a subdomain under it, such as is done with SRV 500 records. 502 The example above in Section 3 might be published via these lines in 503 a domain zone file: 505 example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" 506 smtp-out.example.com. TXT "v=spf1 a -all" 508 When publishing via TXT records, beware of other TXT records 509 published there for other purposes. They might cause problems with 510 size limits (see Section 3.1.4). 512 Domains publishing records SHOULD try to keep the number of "include" 513 mechanisms and chained "redirect" modifiers to a minimum. Domains 514 SHOULD also try to minimize the amount of other DNS information 515 needed to evaluate a record. Section 9.1.1 provides some suggestions 516 on how to achieve this. 518 3.1.1. DNS Resource Records 520 SPF records MUST be published as type TXT [RFC1035]. The character 521 content of the record is encoded as [US-ASCII]. Use of alternate DNS 522 RR types has been dropped. See Appendix A of 523 [draft-ietf-spfbis-experiment]. 525 3.1.2. Multiple DNS Records 527 A domain name MUST NOT have multiple records that would cause an 528 authorization check to select more than one record. See Section 4.5 529 for the selection rules. 531 3.1.3. Multiple Strings in a Single DNS record 533 As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS 534 record (either TXT or SPF RR types) can be composed of more than one 535 string. If a published record contains multiple strings, then the 536 record MUST be treated as if those strings are concatenated together 537 without adding spaces. For example: 539 IN TXT "v=spf1 .... first" "second string..." 541 MUST be treated as equivalent to 543 IN TXT "v=spf1 .... firstsecond string..." 545 TXT records containing multiple strings are useful in constructing 546 records that would exceed the 255-byte maximum length of a string 547 within a single TXT record. 549 3.1.4. Record Size 551 The published SPF record for a given domain name SHOULD remain small 552 enough that the results of a query for it will fit within 512 octets. 553 This will keep even older DNS implementations from falling over to 554 TCP. Since the answer size is dependent on many things outside the 555 scope of this document, it is only possible to give this guideline: 556 If the combined length of the DNS name and the text of all the 557 records of a given type is under 450 characters, then DNS answers 558 should fit in UDP packets. Note that when computing the sizes for 559 queries of the TXT format, one must take into account any other TXT 560 records published at the domain name. Records that are too long to 561 fit in a single UDP packet MAY be silently ignored by SPF clients. 563 3.1.5. Wildcard Records 565 Use of wildcard records for publishing is not recommended. Care must 566 be taken if wildcard records are used. If a domain publishes 567 wildcard MX records, it might want to publish wildcard declarations, 568 subject to the same requirements and problems. In particular, the 569 declaration must be repeated for any host that has any RR records at 570 all, and for subdomains thereof. For example, the example given in 571 [RFC1034], Section 4.3.3, could be extended with the following: 573 X.COM. MX 10 A.X.COM 574 X.COM. TXT "v=spf1 a:A.X.COM -all" 576 *.X.COM. MX 10 A.X.COM 577 *.X.COM. TXT "v=spf1 a:A.X.COM -all" 579 A.X.COM. A 1.2.3.4 580 A.X.COM. MX 10 A.X.COM 581 A.X.COM. TXT "v=spf1 a:A.X.COM -all" 583 *.A.X.COM. MX 10 A.X.COM 584 *.A.X.COM. TXT "v=spf1 a:A.X.COM -all" 586 Notice that SPF records must be repeated twice for every name within 587 the domain: once for the name, and once with a wildcard to cover the 588 tree under the name. 590 Use of wildcards is discouraged in general as they cause every name 591 under the domain to exist and queries against arbitrary names will 592 never return RCODE 3 (Name Error). 594 4. The check_host() Function 596 The check_host() function fetches SPF records, parses them, and 597 interprets them to determine whether a particular host is or is not 598 permitted to send mail with a given identity. Mail receivers that 599 perform this check MUST correctly evaluate the check_host() function 600 as described here. 602 Implementations MAY use a different algorithm than the canonical 603 algorithm defined here, so long as the results are the same in all 604 cases. 606 4.1. Arguments 608 The check_host() function takes these arguments: 610 - the IP address of the SMTP client that is emitting the 611 mail, either IPv4 or IPv6. 613 - the domain that provides the sought-after authorization 614 information; initially, the domain portion of the "MAIL 615 FROM" or "HELO" identity. 617 - the "MAIL FROM" or "HELO" identity. 619 The domain portion of will usually be the same as the 620 argument when check_host() is initially evaluated. However, 621 this will generally not be true for recursive evaluations (see 622 Section 5.2 below). 624 Actual implementations of the check_host() function might need 625 additional arguments. 627 4.2. Results 629 The function check_host() can return one of several results described 630 in Section 2.5. Based on the result, the action to be taken is 631 determined by the local policies of the receiver. 633 4.3. Initial Processing 635 If the is malformed (label longer than 63 characters, zero- 636 length label not at the end, etc.) or is not a fully qualified domain 637 name, or if the DNS lookup returns "domain does not exist" (RCODE 3), 638 check_host() immediately returns the result "none". 640 If the has no localpart, substitute the string "postmaster" 641 for the localpart. 643 4.4. Record Lookup 645 In accordance with how the records are published (see Section 3.1 646 above), a DNS query needs to be made for the name, querying 647 for type TXT only. 649 If all DNS lookups that are made return a server failure (RCODE 2), 650 or other error (RCODE other than 0 or 3), or time out, then 651 check_host() exits immediately with the result "temperror". 652 Alternatively, for a server failure (RCODE 2) result, check_host() 653 MAY track failures and treat multiple failures within 24 hours for 654 the same domain as "permerror". 656 This alternative is intended to shorten the queue time of messages 657 that cannot be accepted, by returning a permanent negative completion 658 reply code to the client, instead of a transient one. Saving queries 659 is accomplished according to [RFC2308]. 661 4.5. Selecting Records 663 Records begin with a version section: 665 record = version terms *SP 666 version = "v=spf1" 668 Starting with the set of records that were returned by the lookup, 669 discard records that do not begin with a version section of exactly 670 "v=spf1". Note that the version section is terminated either by an 671 SP character or the end of the record. A record with a version 672 section of "v=spf10" does not match and must be discarded. 674 There should be exactly one record remaining and evaluation can 675 proceed. If there are two or more records remaining, then 676 check_host() exits immediately with the result of "permerror". 678 If no matching records are returned, an SPF client MUST assume that 679 the domain makes no SPF declarations. SPF processing MUST stop and 680 return "none". 682 4.6. Record Evaluation 684 After one SPF record has been selected, the check_host() function 685 parses and interprets it to find a result for the current test. If 686 there are any syntax errors, check_host() returns immediately with 687 the result "permerror". 689 Implementations MAY choose to parse the entire record first and 690 return "permerror" if the record is not syntactically well formed. 692 However, in all cases, any syntax errors anywhere in the record MUST 693 be detected. 695 4.6.1. Term Evaluation 697 There are two types of terms: mechanisms and modifiers. A record 698 contains an ordered list of these as specified in the following 699 Augmented Backus-Naur Form (ABNF). 701 terms = *( 1*SP ( directive / modifier ) ) 703 directive = [ qualifier ] mechanism 704 qualifier = "+" / "-" / "?" / "~" 705 mechanism = ( all / include 706 / A / MX / PTR / IP4 / IP6 / exists ) 707 modifier = redirect / explanation / unknown-modifier 708 unknown-modifier = name "=" macro-string 709 ; where name is not any known modifier 711 name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) 713 Most mechanisms allow a ":" or "/" character after the name. 715 Modifiers always contain an equals ('=') character immediately after 716 the name, and before any ":" or "/" characters that might be part of 717 the macro-string. 719 Terms that do not contain any of "=", ":", or "/" are mechanisms, as 720 defined in Section 5. 722 As per the definition of the ABNF notation in [RFC5234], mechanism 723 and modifier names are case-insensitive. 725 4.6.2. Mechanisms 727 Each mechanism is considered in turn from left to right. If there 728 are no more mechanisms, the result is specified in Section 4.7. 730 When a mechanism is evaluated, one of three things can happen: it can 731 match, not match, or throw an exception. 733 If it matches, processing ends and the qualifier value is returned as 734 the result of that record. If it does not match, processing 735 continues with the next mechanism. If it throws an exception, 736 mechanism processing ends and the exception value is returned. 738 The possible qualifiers, and the results they return are as follows: 740 "+" pass 741 "-" fail 742 "~" softfail 743 "?" neutral 745 The qualifier is optional and defaults to "+". 747 When a mechanism matches and the qualifier is "-", then a "fail" 748 result is returned and the explanation string is computed as 749 described in Section 6.2. 751 The specific mechanisms are described in Section 5. 753 4.6.3. Modifiers 755 Modifiers are not mechanisms: they do not return match or not-match. 756 Instead they provide additional information. Although modifiers do 757 not directly affect the evaluation of the record, the "redirect" 758 modifier has an effect after all the mechanisms have been evaluated. 760 4.6.4. Evaluation Limits 762 SPF implementations MUST limit the number of mechanisms and modifiers 763 ("terms") that do DNS lookups to at most 10 per during SPF record 764 evaluation. Specifically, the "include", "a", "mx", "ptr", and 765 "exists" mechanisms as well as the "redirect" modifier count against 766 this limit. The "all", "ip4", and "ip6" mechanisms do not count 767 against this limit. If this number is exceeded during a check, a 768 permerror MUST be returned. The "exp" modifier does not count 769 against this limit because the DNS lookup to fetch the explanation 770 string occurs after the SPF record evaluatation has been completed. 772 When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, 773 there MUST be a limit of no more than 10 MX or PTR RRs looked up and 774 checked. If more than 10 "mx" or "ptr" records are returned for this 775 further lookup, a permerror MUST be returned. This limit is per 776 mechanism or macro in the record and in addition to the lookup limits 777 above. 779 4.7. Default Result 781 If none of the mechanisms match and there is no "redirect" modifier, 782 then the check_host() returns a result of "neutral", just as if 783 "?all" were specified as the last directive. If there is a 784 "redirect" modifier, check_host() proceeds as defined in Section 6.1. 786 Note that records SHOULD always use either a "redirect" modifier or 787 an "all" mechanism to explicitly terminate processing. 789 For example: 791 v=spf1 +mx -all 792 or 793 v=spf1 +mx redirect=_spf.example.com 795 4.8. Domain Specification 797 Several of these mechanisms and modifiers have a domain-spec section. 798 The domain-spec string is macro expanded (see Section 8). The 799 resulting string is the common presentation form of a fully-qualified 800 DNS name: a series of labels separated by periods. This domain is 801 called the in the rest of this document. 803 Note: The result of the macro expansion is not subject to any further 804 escaping. Hence, this facility cannot produce all characters that 805 are legal in a DNS label (e.g., the control characters). However, 806 this facility is powerful enough to express legal host names and 807 common utility labels (such as "_spf") that are used in DNS. 809 For several mechanisms, the is optional. If it is not 810 provided, the is used as the . 812 5. Mechanism Definitions 814 This section defines two types of mechanisms. 816 Basic mechanisms contribute to the language framework. They do not 817 specify a particular type of authorization scheme. 819 all 820 include 822 Designated sender mechanisms are used to designate a set of 823 addresses as being permitted or not permitted to use the for 824 sending mail. 826 a 827 mx 828 ptr (deprecated) 829 ip4 830 ip6 831 exists 833 The following conventions apply to all mechanisms that perform a 834 comparison between and an IP address at any point: 836 If no CIDR-length is given in the directive, then and the IP 837 address are compared for equality. (Here, CIDR is Classless Inter- 838 Domain Routing.) 840 If a CIDR-length is specified, then only the specified number of 841 high-order bits of and the IP address are compared for equality. 843 When any mechanism fetches host addresses to compare with , when 844 is an IPv4 address, A records are fetched, when is an IPv6 845 address, AAAA records are fetched. Even if the SMTP connection is 846 via IPv6, an IPv4-mapped IPv6 IP address (see [RFC4291], Section 847 2.5.5) MUST still be considered an IPv4 address and MUST be evaluated 848 using IPv4 mechanisms (i.e. "ip4" and "a"). 850 Several mechanisms rely on information fetched from DNS. For these 851 DNS queries, except where noted, if the DNS server returns an error 852 (RCODE other than 0 or 3) or the query times out, the mechanism 853 throws the exception "temperror". If the server returns "domain does 854 not exist" (RCODE 3), then evaluation of the mechanism continues as 855 if the server returned no error (RCODE 0) and zero answer records. 857 5.1. "all" 859 all = "all" 860 The "all" mechanism is a test that always matches. It is used as the 861 rightmost mechanism in a record to provide an explicit default. 863 For example: 865 v=spf1 a mx -all 867 Mechanisms after "all" will never be tested. Any "redirect" modifier 868 (Section 6.1) has no effect when there is an "all" mechanism. 870 5.2. "include" 872 include = "include" ":" domain-spec 874 The "include" mechanism triggers a recursive evaluation of 875 check_host(). The domain-spec is expanded as per Section 8. Then 876 check_host() is evaluated with the resulting string as the . 877 The and arguments remain the same as in the current 878 evaluation of check_host(). 880 In hindsight, the name "include" was poorly chosen. Only the 881 evaluated result of the referenced SPF record is used, rather than 882 acting as if the referenced SPF record was literally included in the 883 first. For example, evaluating a "-all" directive in the referenced 884 record does not terminate the overall processing and does not 885 necessarily result in an overall "fail". (Better names for this 886 mechanism would have been "if-pass", "on-pass", etc.) 888 The "include" mechanism makes it possible for one domain to designate 889 multiple administratively-independent domains. For example, a vanity 890 domain "example.net" might send mail using the servers of 891 administratively-independent domains example.com and example.org. 893 Example.net could say 895 IN TXT "v=spf1 include:example.com include:example.org -all" 897 This would direct check_host() to, in effect, check the records of 898 example.com and example.org for a "pass" result. Only if the host 899 were not permitted for either of those domains would the result be 900 "fail". 902 Whether this mechanism matches, does not match, or throws an 903 exception depends on the result of the recursive evaluation of 904 check_host(): 906 +---------------------------------+---------------------------------+ 907 | A recursive check_host() result | Causes the "include" mechanism | 908 | of: | to: | 909 +---------------------------------+---------------------------------+ 910 | pass | match | 911 | | | 912 | fail | not match | 913 | | | 914 | softfail | not match | 915 | | | 916 | neutral | not match | 917 | | | 918 | temperror | throw temperror | 919 | | | 920 | permerror | throw permerror | 921 | | | 922 | none | throw permerror | 923 +---------------------------------+---------------------------------+ 925 The "include" mechanism is intended for crossing administrative 926 boundaries. Although it is possible to use includes to consolidate 927 multiple domains that share the same set of designated hosts, domains 928 are encouraged to use redirects where possible, and to minimize the 929 number of includes within a single administrative domain. For 930 example, if example.com and example.org were managed by the same 931 entity, and if the permitted set of hosts for both domains was 932 "mx:example.com", it would be possible for example.org to specify 933 "include:example.com", but it would be preferable to specify 934 "redirect=example.com" or even "mx:example.com". 936 5.3. "a" 938 This mechanism matches if is one of the 's IP 939 addresses. 941 A = "a" [ ":" domain-spec ] [ dual-cidr-length ] 943 An address lookup is done on the . The is compared 944 to the returned address(es). If any address matches, the mechanism 945 matches. 947 5.4. "mx" 949 This mechanism matches if is one of the MX hosts for a domain 950 name. 952 MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] 953 check_host() first performs an MX lookup on the . Then 954 it performs an address lookup on each MX name returned. The is 955 compared to each returned IP address. To prevent Denial of Service 956 (DoS) attacks, more than 10 MX names MUST NOT be looked up during the 957 evaluation of an "mx" mechanism (see Section 10). If any address 958 matches, the mechanism matches. 960 Note regarding implicit MXs: If the has no MX records, 961 check_host() MUST NOT pretend the target is its single MX, and MUST 962 NOT default to an A or AAAA lookup on the directly. 963 This behavior breaks with the legacy "implicit MX" rule. See 964 [RFC5321], Section 5. If such behavior is desired, the publisher 965 should specify an "a" directive. 967 5.5. "ptr" (deprecated) 969 This mechanism tests whether the DNS reverse-mapping for exists 970 and correctly points to a domain name within a particular domain. 971 This mechanism is deprecated and SHOULD NOT be used. 973 PTR = "ptr" [ ":" domain-spec ] 975 First, the 's name is looked up using this procedure: perform a 976 DNS reverse-mapping for , looking up the corresponding PTR record 977 in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa." 978 if it is an IPv6 address. For each record returned, validate the 979 domain name by looking up its IP address. To prevent DoS attacks, 980 more than 10 PTR names MUST NOT be looked up during the evaluation of 981 a "ptr" mechanism (see Section 10). If is among the returned IP 982 addresses, then that domain name is validated. In pseudocode: 984 sending-domain_names := ptr_lookup(sending-host_IP); 985 if more than 10 sending-domain_names are found, use at most 10. 986 for each name in (sending-domain_names) { 987 IP_addresses := a_lookup(name); 988 if the sending-domain_IP is one of the IP_addresses { 989 validated-sending-domain_names += name; 990 } 991 } 993 Check all validated domain names to see if they end in the 994 domain. If any do, this mechanism matches. If no 995 validated domain name can be found, or if none of the validated 996 domain names end in the , this mechanism fails to match. 997 If a DNS error occurs while doing the PTR RR lookup, then this 998 mechanism fails to match. If a DNS error occurs while doing an A RR 999 lookup, then that domain name is skipped and the search continues. 1001 Pseudocode: 1003 for each name in (validated-sending-domain_names) { 1004 if name ends in , return match. 1005 if name is , return match. 1006 } 1007 return no-match. 1009 This mechanism matches if the is either an ancestor of 1010 a validated domain name or if the and a validated 1011 domain name are the same. For example: "mail.example.com" is within 1012 the domain "example.com", but "mail.bad-example.com" is not. 1014 Note: This mechanism has been deprecated because it is slow, it is 1015 not as reliable as other mechanisms in cases of DNS errors, and it 1016 places a large burden on the arpa name servers. If used, proper PTR 1017 records must be in place for the domain's hosts and the "ptr" 1018 mechanism should be one of the last mechanisms checked. After many 1019 yaers of SPF deployment experience it has been concluded it is 1020 unnecessary and more reliable alternatives used instead. 1022 5.6. "ip4" and "ip6" 1024 These mechanisms test whether is contained within a given IP 1025 network. 1027 IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] 1028 IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] 1030 ip4-cidr-length = "/" 1*DIGIT 1031 ip6-cidr-length = "/" 1*DIGIT 1032 dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] 1034 ip4-network = qnum "." qnum "." qnum "." qnum 1035 qnum = DIGIT ; 0-9 1036 / %x31-39 DIGIT ; 10-99 1037 / "1" 2DIGIT ; 100-199 1038 / "2" %x30-34 DIGIT ; 200-249 1039 / "25" %x30-35 ; 250-255 1040 ; as per conventional dotted quad notation. e.g., 192.0.2.0 1041 ip6-network = 1042 ; e.g., 2001:DB8::CD30 1044 The is compared to the given network. If CIDR-length high-order 1045 bits match, the mechanism matches. 1047 If ip4-cidr-length is omitted, it is taken to be "/32". If 1048 ip6-cidr-length is omitted, it is taken to be "/128". It is not 1049 permitted to omit parts of the IP address instead of using CIDR 1050 notations. That is, use 192.0.2.0/24 instead of 192.0.2. 1052 5.7. "exists" 1054 This mechanism is used to construct an arbitrary domain name that is 1055 used for a DNS A record query. It allows for complicated schemes 1056 involving arbitrary parts of the mail envelope to determine what is 1057 permitted. 1059 exists = "exists" ":" domain-spec 1061 The domain-spec is expanded as per Section 8. The resulting domain 1062 name is used for a DNS A RR lookup. If any A record is returned, 1063 this mechanism matches. The lookup type is A even when the 1064 connection type is IPv6. 1066 Domains can use this mechanism to specify arbitrarily complex 1067 queries. For example, suppose example.com publishes the record: 1069 v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all 1071 The might expand to 1072 "1.2.0.192.someuser._spf.example.com". This makes fine-grained 1073 decisions possible at the level of the user and client IP address. 1075 This mechanism enables queries that mimic the style of tests that 1076 existing anti-spam DNS blacklists (DNSBL) use. 1078 6. Modifier Definitions 1080 Modifiers are name/value pairs that provide additional information. 1081 Modifiers always have an "=" separating the name and the value. 1083 The modifiers defined in this document ("redirect" and "exp") MAY 1084 appear anywhere in the record, but SHOULD appear at the end, after 1085 all mechanisms. Ordering of these two modifiers does not matter. 1086 These two modifiers MUST NOT appear in a record more than once each. 1087 If they do, then check_host() exits with a result of "permerror". 1089 Unrecognized modifiers MUST be ignored no matter where in a record, 1090 or how often. This allows implementations of this document to 1091 gracefully handle records with modifiers that are defined in other 1092 specifications. 1094 6.1. redirect: Redirected Query 1096 If all mechanisms fail to match, and a "redirect" modifier is 1097 present, then processing proceeds as follows: 1099 redirect = "redirect" "=" domain-spec 1101 The domain-spec portion of the redirect section is expanded as per 1102 the macro rules in Section 8. Then check_host() is evaluated with 1103 the resulting string as the . The and 1104 arguments remain the same as in the current evaluation of 1105 check_host(). 1107 The result of this new evaluation of check_host() is then considered 1108 the result of the current evaluation with the exception that if no 1109 SPF record is found, or if the target-name is malformed, the result 1110 is a "permerror" rather than "none". 1112 Note that the newly-queried domain can itself specify redirect 1113 processing. 1115 This facility is intended for use by organizations that wish to apply 1116 the same record to multiple domains. For example: 1118 la.example.com. TXT "v=spf1 redirect=_spf.example.com" 1119 ny.example.com. TXT "v=spf1 redirect=_spf.example.com" 1120 sf.example.com. TXT "v=spf1 redirect=_spf.example.com" 1121 _spf.example.com. TXT "v=spf1 mx:example.com -all" 1123 In this example, mail from any of the three domains is described by 1124 the same record. This can be an administrative advantage. 1126 Note: In general, the domain "A" cannot reliably use a redirect to 1127 another domain "B" not under the same administrative control. Since 1128 the stays the same, there is no guarantee that the record at 1129 domain "B" will correctly work for mailboxes in domain "A", 1130 especially if domain "B" uses mechanisms involving localparts. An 1131 "include" directive is generally be more appropriate. 1133 For clarity, it is RECOMMENDED that any "redirect" modifier appear as 1134 the very last term in a record. 1136 6.2. exp: Explanation 1138 explanation = "exp" "=" domain-spec 1140 If check_host() results in a "fail" due to a mechanism match (such as 1141 "-all"), and the "exp" modifier is present, then the explanation 1142 string returned is computed as described below. If no "exp" modifier 1143 is present, then either a default explanation string or an empty 1144 explanation string MUST be returned. 1146 The domain-spec is macro expanded (see Section 8) and becomes the 1147 . The DNS TXT record for the is fetched. 1149 If there are any DNS processing errors (any RCODE other than 0), or 1150 if no records are returned, or if more than one record is returned, 1151 or if there are syntax errors in the explanation string, then proceed 1152 as if no exp modifier was given. 1154 The fetched TXT record's strings are concatenated with no spaces, and 1155 then treated as an explain-string, which is macro-expanded. This 1156 final result is the explanation string. Implementations MAY limit 1157 the length of the resulting explanation string to allow for other 1158 protocol constraints and/or reasonable processing limits. Since the 1159 explanation string is intended for an SMTP response and [RFC5321] 1160 Section 2.4 says that responses are in [US-ASCII], the explanation 1161 string is also limited to US-ASCII. 1163 Software evaluating check_host() can use this string to communicate 1164 information from the publishing domain in the form of a short message 1165 or URL. Software SHOULD make it clear that the explanation string 1166 comes from a third party. For example, it can prepend the macro 1167 string "%{o} explains: " to the explanation, such as shown in 1168 Section 2.5.4. 1170 Suppose example.com has this record: 1172 v=spf1 mx -all exp=explain._spf.%{d} 1174 Here are some examples of possible explanation TXT records at 1175 explain._spf.example.com: 1177 "Mail from example.com should only be sent by its own servers." 1178 -- a simple, constant message 1180 "%{i} is not one of %{d}'s designated mail servers." 1181 -- a message with a little more information, including the IP 1182 address that failed the check 1184 "See http://%{d}/why.html?s=%{S}&i=%{I}" 1185 -- a complicated example that constructs a URL with the 1186 arguments to check_host() so that a web page can be 1187 generated with detailed, custom instructions 1189 Note: During recursion into an "include" mechanism, an exp= modifier 1190 from the MUST NOT be used. In contrast, when executing 1191 a "redirect" modifier, an exp= modifier from the original domain MUST 1192 NOT be used. 1194 7. The Received-SPF Header Field 1196 It is RECOMMENDED that SMTP receivers record the result of SPF 1197 processing in the message header. If an SMTP receiver chooses to do 1198 so, it SHOULD use the "Received-SPF" header field defined here for 1199 each identity that was checked. This information is intended for the 1200 recipient. (Information intended for the sender is described in 1201 Section 6.2, Explanation.) 1203 The Received-SPF header field is a trace field (see [RFC5322] Section 1204 3.6.7) and SHOULD be prepended to the existing header, above the 1205 Received: field that is generated by the SMTP receiver. It MUST 1206 appear above all other Received-SPF fields in the message. The 1207 header field has the following format: 1209 header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] 1210 [ key-value-list ] CRLF 1212 result = "pass" / "fail" / "softfail" / "neutral" / 1213 "none" / "temperror" / "permerror" 1215 key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) 1216 [";"] 1218 key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) 1220 key = "client-ip" / "envelope-from" / "helo" / 1221 "problem" / "receiver" / "identity" / 1222 mechanism / name 1224 identity = "mailfrom" ; for the "MAIL FROM" identity 1225 / "helo" ; for the "HELO" identity 1226 / name ; other identities 1228 dot-atom = 1229 quoted-string = 1230 comment = 1231 CFWS = 1232 FWS = 1233 CRLF = 1235 The header field SHOULD include a "(...)" style comment after the 1236 result, conveying supporting information for the result, such as 1237 , , and . 1239 The following key-value pairs are designed for later machine parsing. 1240 SPF clients SHOULD give enough information so that the SPF results 1241 can be verified. That is, at least "client-ip", "helo", and, if the 1242 "MAIL FROM" identity was checked, "envelope-from". 1244 client-ip the IP address of the SMTP client 1246 envelope-from the envelope sender mailbox 1248 helo the host name given in the HELO or EHLO command 1250 mechanism the mechanism that matched (if no mechanisms matched, 1251 substitute the word "default") 1253 problem if an error was returned, details about the error 1255 receiver the host name of the SPF client 1257 identity the identity that was checked; see the ABNF 1258 rule 1260 Other keys MAY be defined by SPF clients. 1262 SPF clients MUST make sure that the Received-SPF header field does 1263 not contain invalid characters, is not excessively long, and does not 1264 contain malicious data that has been provided by the sender. 1266 Examples of various header styles that could be generated are the 1267 following: 1269 Received-SPF: pass (mybox.example.org: domain of 1270 myname@example.com designates 192.0.2.1 as permitted sender) 1271 receiver=mybox.example.org; client-ip=192.0.2.1; 1272 envelope-from="myname@example.com"; helo=foo.example.com; 1274 Received-SPF: fail (mybox.example.org: domain of 1275 myname@example.com does not designate 1276 192.0.2.1 as permitted sender) 1277 identity=mailfrom; client-ip=192.0.2.1; 1278 envelope-from="myname@example.com"; 1280 8. Macros 1282 8.1. Macro Definitions 1284 Many mechanisms and modifiers perform macro expansion on the term. 1286 domain-spec = macro-string domain-end 1287 domain-end = ( "." toplabel [ "." ] ) / macro-expand 1289 toplabel = ( *alphanum ALPHA *alphanum ) / 1290 ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) 1291 ; LDH rule plus additional TLD restrictions 1292 ; (see [RFC3696], Section 2 for background) 1293 alphanum = ALPHA / DIGIT 1295 explain-string = *( macro-string / SP ) 1297 macro-string = *( macro-expand / macro-literal ) 1298 macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) 1299 / "%%" / "%_" / "%-" 1300 macro-literal = %x21-24 / %x26-7E 1301 ; visible characters except "%" 1302 macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / 1303 "c" / "r" / "t" / "v" 1304 transformers = *DIGIT [ "r" ] 1305 delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" 1307 A literal "%" is expressed by "%%". 1309 "%_" expands to a single " " space. 1310 "%-" expands to a URL-encoded space, viz., "%20". 1312 The following macro letters are expanded in term arguments: 1314 s = 1315 l = local-part of 1316 o = domain of 1317 d = 1318 i = 1319 p = the validated domain name of (deprecated) 1320 v = the string "in-addr" if is ipv4, or "ip6" if is ipv6 1321 h = HELO/EHLO domain 1323 The following macro letters are allowed only in "exp" text: 1325 c = SMTP client IP (easily readable format) 1326 r = domain name of host performing the check 1327 t = current timestamp 1329 A '%' character not followed by a '{', '%', '-', or '_' character is 1330 a syntax error. So 1331 -exists:%(ir).sbl.spamhaus.example.org 1332 is incorrect and will cause check_host() to return a "permerror". 1333 Instead, say 1334 -exists:%{ir}.sbl.spamhaus.example.org 1336 Optional transformers are the following: 1338 *DIGIT = zero or more digits 1339 'r' = reverse value, splitting on dots by default 1341 If transformers or delimiters are provided, the replacement value for 1342 a macro letter is split into parts. After performing any reversal 1343 operation and/or removal of left-hand parts, the parts are rejoined 1344 using "." and not the original splitting characters. 1346 By default, strings are split on "." (dots). Note that no special 1347 treatment is given to leading, trailing, or consecutive delimiters, 1348 and so the list of parts might contain empty strings. Older 1349 implementations of SPF prohibit trailing dots in domain names, so 1350 trailing dots should not be published by domain owners, although they 1351 must be accepted by implementations conforming to this document. 1352 Macros MAY specify delimiter characters that are used instead of ".". 1354 The 'r' transformer indicates a reversal operation: if the client IP 1355 address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1" 1356 and the macro %{ir} would expand to "1.2.0.192". 1358 The DIGIT transformer indicates the number of right-hand parts to 1359 use, after optional reversal. If a DIGIT is specified, the value 1360 MUST be nonzero. If no DIGITs are specified, or if the value 1361 specifies more parts than are available, all the available parts are 1362 used. If the DIGIT was 5, and only 3 parts were available, the macro 1363 interpreter would pretend the DIGIT was 3. Implementations MUST 1364 support at least a value of 128, as that is the maximum number of 1365 labels in a domain name. 1367 The "s" macro expands to the argument. It is an email 1368 address with a localpart, an "@" character, and a domain. The "l" 1369 macro expands to just the localpart. The "o" macro expands to just 1370 the domain part. Note that these values remain the same during 1371 recursive and chained evaluations due to "include" and/or "redirect". 1372 Note also that if the original had no localpart, the 1373 localpart was set to "postmaster" in initial processing (see 1374 Section 4.3). 1376 For IPv4 addresses, both the "i" and "c" macros expand to the 1377 standard dotted-quad format. 1379 For IPv6 addresses, the "i" macro expands to a dot-format address; it 1380 is intended for use in %{ir}. The "c" macro MAY expand to any of the 1381 hexadecimal colon-format addresses specified in [RFC4291], Section 1382 2.2. It is intended for humans to read. 1384 The "p" macro expands to the validated domain name of . The 1385 procedure for finding the validated domain name is defined in 1386 Section 5.5. If the is present in the list of validated 1387 domains, it SHOULD be used. Otherwise, if a subdomain of the 1388 is present, it SHOULD be used. Otherwise, any name from the 1389 list MAY be used. If there are no validated domain names or if a DNS 1390 error occurs, the string "unknown" is used. This macro is deprecated 1391 and SHOULD NOT be used. 1393 The "r" macro expands to the name of the receiving MTA. This SHOULD 1394 be a fully qualified domain name, but if one does not exist (as when 1395 the checking is done by a MUA) or if policy restrictions dictate 1396 otherwise, the word "unknown" SHOULD be substituted. The domain name 1397 can be different from the name found in the MX record that the client 1398 MTA used to locate the receiving MTA. 1400 The "t" macro expands to the decimal representation of the 1401 approximate number of seconds since the Epoch (Midnight, January 1, 1402 1970, UTC). This is the same value as is returned by the POSIX 1403 time() function in most standards-compliant libraries. 1405 When the result of macro expansion is used in a domain name query, if 1406 the expanded domain name exceeds 253 characters (the maximum length 1407 of a domain name), the left side is truncated to fit, by removing 1408 successive domain labels until the total length does not exceed 253 1409 characters. 1411 Uppercased macros expand exactly as their lowercased equivalents, and 1412 are then URL escaped. URL escaping must be performed for characters 1413 not in the "unreserved" set, which is defined in [RFC3986]. 1415 Note: Care must be taken so that macro expansion for legitimate email 1416 does not exceed the 63-character limit on DNS labels. The localpart 1417 of email addresses, in particular, can have more than 63 characters 1418 between dots. 1420 Note: Domains should avoid using the "s", "l", "o", or "h" macros in 1421 conjunction with any mechanism directive. Although these macros are 1422 powerful and allow per-user records to be published, they severely 1423 limit the ability of implementations to cache results of check_host() 1424 and they reduce the effectiveness of DNS caches. 1426 Implementations should be aware that if no directive processed during 1427 the evaluation of check_host() contains an "s", "l", "o", or "h" 1428 macro, then the results of the evaluation can be cached on the basis 1429 of and alone for as long as the shortest Time To Live 1430 (TTL) of all the DNS records involved. 1432 8.2. Expansion Examples 1434 The is strong-bad@email.example.com. 1435 The IPv4 SMTP client IP is 192.0.2.3. 1436 The IPv6 SMTP client IP is 2001:DB8::CB01. 1437 The PTR domain name of the client IP is mx.example.org. 1439 macro expansion 1440 ------- ---------------------------- 1441 %{s} strong-bad@email.example.com 1442 %{o} email.example.com 1443 %{d} email.example.com 1444 %{d4} email.example.com 1445 %{d3} email.example.com 1446 %{d2} example.com 1447 %{d1} com 1448 %{dr} com.example.email 1449 %{d2r} example.email 1450 %{l} strong-bad 1451 %{l-} strong.bad 1452 %{lr} strong-bad 1453 %{lr-} bad.strong 1454 %{l1r-} strong 1456 macro-string expansion 1457 -------------------------------------------------------------------- 1458 %{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com 1459 %{lr-}.lp._spf.%{d2} bad.strong.lp._spf.example.com 1461 %{lr-}.lp.%{ir}.%{v}._spf.%{d2} 1462 bad.strong.lp.3.2.0.192.in-addr._spf.example.com 1464 %{ir}.%{v}.%{l1r-}.lp._spf.%{d2} 1465 3.2.0.192.in-addr.strong.lp._spf.example.com 1467 %{d2}.trusted-domains.example.net 1468 example.com.trusted-domains.example.net 1470 IPv6: 1471 %{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0. 1472 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com 1474 9. Implications 1476 This section outlines the major implications that adoption of this 1477 document will have on various entities involved in Internet email. 1478 It is intended to make clear to the reader where this document 1479 knowingly affects the operation of such entities. This section is 1480 not a "how-to" manual, or a "best practices" document, and it is not 1481 a comprehensive list of what such entities should do in light of this 1482 document. 1484 This section is non-normative. [RFC5598] describes the Internet 1485 email architecture. This section is organized based on the different 1486 segments of the architecture. 1488 9.1. Sending Domains 1490 Originating ADMDs (ADministrative Management Domains - [RFC5598] 1491 Section 2.2.1 and Section 2.3) that wish to be compliant with this 1492 specification will need to determine the list of relays ([RFC5598] 1493 Section 2.2.2) that they allow to use their domain name in the "HELO" 1494 and "MAIL FROM" identities when relaying to other ADMDs. It is 1495 recognized that forming such a list is not just a simple technical 1496 exercise, but involves policy decisions with both technical and 1497 administrative considerations. 1499 9.1.1. DNS Resource Considerations 1501 Minimizing the DNS resources required for SPF lookups can be done by 1502 choosing directives that require less DNS information and placing 1503 lower-cost mechanisms earlier in the SPF record. 1505 For example, consider a domain set up as follows: 1507 example.com. IN MX 10 mx.example.com. 1508 mx.example.com. IN A 192.0.2.1 1509 a.example.com. IN TXT "v=spf1 mx:example.com -all" 1510 b.example.com. IN TXT "v=spf1 a:mx.example.com -all" 1511 c.example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all" 1513 Evaluating check_host() for the domain "a.example.com" requires the 1514 MX records for "example.com", and then the A records for the listed 1515 hosts. Evaluating for "b.example.com" requires only the A records. 1516 Evaluating for "c.example.com" requires none. 1518 Section 4.6.4 specifies the limits receivers have to use. It is 1519 essential to publish records that do not exceed these requirements. 1520 As an example, if you have more than 10 MX records, do not use the 1521 'MX" mechanism to describe them in your SPF record. 1523 9.1.2. Administrator's Considerations 1525 There might be administrative considerations: using "a" over "ip4" or 1526 "ip6" allows hosts to be renumbered easily. Using "mx" over "a" 1527 allows the set of mail hosts to be changed easily. Unless such 1528 changes are common, it is better to use the less resource intensive 1529 mechanisms like "ip4" and "ip6". 1531 Validating correct deployment is difficult. [RFC6652] describes one 1532 mechanism for soliciting feedback on SPF failures. Another approach 1533 that can be helpful to publish records that include a "tracking 1534 exists:" mechanism. By looking at the name server logs, a rough list 1535 can then be generated. For example: 1537 v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all 1539 Regardless of the method used, understanding the ADMD's outbound mail 1540 architecture is essential to effective deployment. 1542 9.2. Mediators 1544 Broadly speaking, there are two types of mediating ADMDs that can 1545 affect SPF deployment of other ADMDs: mailing lists (see [RFC5598] 1546 Section 5.3) and ReSenders ([RFC5598] Section 5.2). 1548 9.2.1. Mailing Lists 1550 Mailing lists must be aware of how they re-inject mail that is sent 1551 to the list. Mailing lists MUST comply with the requirements in 1552 [RFC5321], Section 3.10, and [RFC1123], Section 5.3.6, that say that 1553 the reverse-path MUST be changed to be the mailbox of a person or 1554 other entity who administers the list. Whereas the reasons for 1555 changing the reverse-path are many and long-standing, SPF adds 1556 enforcement to this requirement. 1558 In practice, almost all mailing list software in use already complies 1559 with this requirement. Mailing lists that do not comply might 1560 encounter problems depending on how access to the list is restricted. 1561 Such lists that are entirely internal to a domain (only people in the 1562 domain can send to or receive from the list) are not affected. 1564 9.2.2. Forwarding Services and Aliases 1566 Forwarding services take mail that is received at a mailbox and 1567 direct it to some external mailbox. At the time of this writing, the 1568 near-universal practice of such services is to use the original "MAIL 1569 FROM" of a message when re-injecting it for delivery to the external 1570 mailbox. [RFC1123] and [RFC5321] describe this action as an "alias" 1571 rather than a "mail list". This means that the external mailbox's 1572 MTA sees all such mail in a connection from a host of the forwarding 1573 service, and so the "MAIL FROM" identity will not, in general, pass 1574 authorization. 1576 There are three places that techniques can be used to ameliorate this 1577 problem. 1579 1. The beginning, when email is first sent (Originating ADMDs). 1581 1. "Neutral" results could be given for IP addresses that might 1582 be forwarders, instead of "fail" results. For example: 1584 "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all" 1586 This would cause a lookup on an anti-spam DNS blacklist 1587 (DNSBL) and cause a result of "fail" only for email coming 1588 from listed sources. All other email, including email sent 1589 through forwarders, would receive a "neutral" result. By 1590 checking the DNSBL after the known good sources, problems 1591 with incorrect listing on the DNSBL are greatly reduced. 1593 2. The "MAIL FROM" identity could have additional information in 1594 the localpart that cryptographically identifies the mail as 1595 coming from an authorized source. In this case, such an SPF 1596 record could be used: 1598 "v=spf1 mx exists:%{l}._spf_verify.%{d} -all" 1600 Then, a specialized DNS server can be set up to serve the 1601 _spf_verify subdomain that validates the localpart. Although 1602 this requires an extra DNS lookup, this happens only when the 1603 email would otherwise be rejected as not coming from a known 1604 good source. 1605 Note that due to the 63-character limit for domain labels, 1606 this approach only works reliably if the localpart signature 1607 scheme is guaranteed either to only produce localparts with a 1608 maximum of 63 characters or to gracefully handle truncated 1609 localparts. 1611 3. Similarly, a specialized DNS server could be set up that will 1612 rate-limit the email coming from unexpected IP addresses. 1614 "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all" 1616 4. SPF allows the creation of per-user policies for special 1617 cases. For example, the following SPF record and appropriate 1618 wildcard DNS records can be used: 1620 "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}" 1622 2. The middle, when email is forwarded (Mediating ADMDs). 1624 1. Forwarding services can solve the problem by rewriting the 1625 "MAIL FROM" to be in their own domain. This means that mail 1626 rejected from the external mailbox will have to be forwarded 1627 back to the original sender by the forwarding service. 1628 Various schemes to do this exist though they vary widely in 1629 complexity and resource requirements on the part of the 1630 forwarding service. 1632 2. Several popular MTAs can be forced from "alias" semantics to 1633 "mailing list" semantics by configuring an additional alias 1634 with "owner-" prepended to the original alias name (e.g., an 1635 alias of "friends: george@example.com, fred@example.org" 1636 would need another alias of the form "owner-friends: 1637 localowner"). 1639 3. The end, when email is received (Receiving ADMDs). 1641 1. If the owner of the external mailbox wishes to trust the 1642 forwarding service, he can direct the external mailbox's MTA 1643 to skip SPF tests when the client host belongs to the 1644 forwarding service. 1646 2. Tests against other identities, such as the "HELO" identity, 1647 MAY be used to override a failed test against the "MAIL FROM" 1648 identity. 1650 3. For larger domains, it might not be possible to have a 1651 complete or accurate list of forwarding services used by the 1652 owners of the domain's mailboxes. In such cases, whitelists 1653 of generally-recognized forwarding services could be 1654 employed. 1656 9.3. Mail Services 1658 MSPs (Mail Service Providers - [RFC5598] Section 2.3) that offer mail 1659 services to third-party domains, such as sending of bulk mail, might 1660 want to adjust their setup in light of the authorization check 1661 described in this document. If the "MAIL FROM" identity used for 1662 such email uses the domain of the service provider, then the provider 1663 needs only to ensure that its sending host is authorized by its own 1664 SPF record, if any. 1666 If the "MAIL FROM" identity does not use the mail service provider's 1667 domain, then extra care must be taken. The SPF record format has 1668 several options for the third-party domain to authorize the service 1669 provider's MTAs to send mail on its behalf. For mail service 1670 providers, such as ISPs, that have a wide variety of customers using 1671 the same MTA, steps should be taken to prevent cross-customer forgery 1672 (see Section 10.4). 1674 9.4. MTA Relays 1676 Relays are described in [RFC5598] Section 2.2.2. The authorization 1677 check generally precludes the use of arbitrary MTA relays between 1678 sender and receiver of an email message. 1680 Within an organization, MTA relays can be effectively deployed. 1681 However, for purposes of this document, such relays are effectively 1682 transparent. The SPF authorization check is a check between border 1683 MTAs of different ADMDs. 1685 For mail senders, this means that published SPF records must 1686 authorize any MTAs that actually send across the Internet. Usually, 1687 these are just the border MTAs as internal MTAs simply forward mail 1688 to these MTAs for delivery. 1690 The receiving ADMD will generally want to perform the authorization 1691 check at the boundary MTAs, specifically including all secondary MXs. 1692 This allows mail that fails to be rejected during the SMTP session 1693 rather than sending a failure report. Internal MTAs then do not 1694 perform the authorization test. To perform the authorization test 1695 other than at the boundary, the host that first transferred the 1696 message to the organization must be determined, which can be 1697 difficult to extract from the message header. Testing other than at 1698 the boundary is likely to produce unreliable results. 1700 10. Security Considerations 1702 10.1. Processing Limits 1704 As with most aspects of email, there are a number of ways that 1705 malicious parties could use the protocol as an avenue for a 1706 Denial-of-Service (DoS) attack. The processing limits outlined in 1707 Section 4.6.4 are designed to prevent attacks such as the following: 1709 o A malicious party could create an SPF record with many references 1710 to a victim's domain and send many emails to different SPF 1711 clients; those SPF clients would then create a DoS attack. In 1712 effect, the SPF clients are being used to amplify the attacker's 1713 bandwidth by using fewer bytes in the SMTP session than are used 1714 by the DNS queries. Using SPF clients also allows the attacker to 1715 hide the true source of the attack. 1717 o Whereas implementations of check_host() are supposed to limit the 1718 number of DNS lookups, malicious domains could publish records 1719 that exceed these limits in an attempt to waste computation effort 1720 at their targets when they send them mail. Malicious domains 1721 could also design SPF records that cause particular 1722 implementations to use excessive memory or CPU usage, or to 1723 trigger bugs. 1725 o Malicious parties could send a large volume of mail purporting to 1726 come from the intended target to a wide variety of legitimate mail 1727 hosts. These legitimate machines would then present a DNS load on 1728 the target as they fetched the relevant records. 1730 Of these, the case of a third party referenced in the SPF record is 1731 the easiest for a DoS attack to effectively exploit. As a result, 1732 limits that might seem reasonable for an individual mail server can 1733 still allow an unreasonable amount of bandwidth amplification. 1734 Therefore, the processing limits need to be quite low. 1736 MTAs or other processors SHOULD impose a limit on the maximum amount 1737 of elapsed time to evaluate check_host(). Such a limit SHOULD allow 1738 at least 20 seconds. If such a limit is exceeded, the result of 1739 authorization SHOULD be "temperror". 1741 10.2. SPF-Authorized Email May Contain Other False Identities 1743 The "MAIL FROM" and "HELO" identity authorizations must not be 1744 construed to provide more assurance than they do. It is entirely 1745 possible for a malicious sender to inject a message using his own 1746 domain in the identities used by SPF, to have that domain's SPF 1747 record authorize the sending host, and yet the message can easily 1748 list other identities in its header. Unless the user or the MUA 1749 takes care to note that the authorized identity does not match the 1750 other more commonly-presented identities (such as the From: header 1751 field), the user might be lulled into a false sense of security. 1753 10.3. Spoofed DNS and IP Data 1755 There are two aspects of this protocol that malicious parties could 1756 exploit to undermine the validity of the check_host() function: 1758 o The evaluation of check_host() relies heavily on DNS. A malicious 1759 attacker could attack the DNS infrastructure and cause 1760 check_host() to see spoofed DNS data, and then return incorrect 1761 results. This could include returning "pass" for an value 1762 where the actual domain's record would evaluate to "fail". See 1763 [RFC3833] for a description of DNS weaknesses. 1765 o The client IP address, , is assumed to be correct. A 1766 malicious attacker could spoof TCP sequence numbers to make mail 1767 appear to come from a permitted host for a domain that the 1768 attacker is impersonating. 1770 10.4. Cross-User Forgery 1772 By definition, SPF policies just map domain names to sets of 1773 authorized MTAs, not whole email addresses to sets of authorized 1774 users. Although the "l" macro (Section 8) provides a limited way to 1775 define individual sets of authorized MTAs for specific email 1776 addresses, it is generally impossible to verify, through SPF, the use 1777 of specific email addresses by individual users of the same MTA. 1779 It is up to mail services and their MTAs to directly prevent 1780 cross-user forgery: based on SMTP AUTH ([RFC4954]), users should be 1781 restricted to using only those email addresses that are actually 1782 under their control (see [RFC6409], Section 6.1). Another means to 1783 verify the identity of individual users is message cryptography such 1784 as PGP ([RFC4880]) or S/MIME ([RFC5751]). 1786 10.5. Untrusted Information Sources 1788 An SPF compliant receiver gathers information from the SMTP commands 1789 it receives and from the published DNS records of the sending domain 1790 holder, (e.g., "HELO" domain name, the "MAIL FROM" address from the 1791 envelope, and SPF DNS records published by the domain holder). 1793 This information, passed to the receiver in the Received-SPF: trace 1794 fields, may be returned to the client MTA as an SMTP rejection 1795 message. If such an SMTP rejection message is generated, the 1796 information from the trace fields must be checked for such problems 1797 as invalid characters and excessively long lines. 1799 When the authorization check fails, an explanation string could be 1800 included in the reject response. Both the sender and the rejecting 1801 receiver need to be aware that the explanation was determined by the 1802 publisher of the SPF record checked and, in general, not the 1803 receiver. The explanation can contain malicious URLs, or it might be 1804 offensive or misleading. 1806 Explanations returned to sender domains due to exp modifiers, 1807 (Section 6.2), were generated by the sender policy published by the 1808 domain holders themselves. As long as messages are only returned 1809 with non-delivery notification to domains publishing the explanation 1810 strings from their own DNS SPF records, the only affected parties are 1811 the original publishers of the domain's SPF records. 1813 In practice, such non-delivery notifications can be misdirected, such 1814 as when an MTA accepts an email and only later generates the 1815 notification to a forged address, or when an email forwarder does not 1816 direct the bounce back to the original sender. 1818 10.6. Privacy Exposure 1820 Checking SPF records causes DNS queries to be sent to the domain 1821 owner. These DNS queries, especially if they are caused by the 1822 "exists" mechanism, can contain information about who is sending 1823 email and likely to which MTA the email is being sent. This can 1824 introduce some privacy concerns, which are more or less of an issue 1825 depending on local laws and the relationship between the domain owner 1826 and the person sending the email. 1828 11. Contributors and Acknowledgements 1830 This document is largely based on the work of Meng Weng Wong, Mark 1831 Lentczner, and Wayne Schlitt. Although, as this section 1832 acknowledges, many people have contributed to this document, a very 1833 large portion of the writing and editing are due to Meng, Mark, and 1834 Wayne. 1836 This design owes a debt of parentage to [RMX] by Hadmut Danisch and 1837 to [DMP] by Gordon Fecyk. The idea of using a DNS record to check 1838 the legitimacy of an email address traces its ancestry further back 1839 through messages on the namedroppers mailing list by Paul Vixie 1840 [Vixie] (based on suggestion by Jim Miller) and by David Green 1841 [Green]. 1843 Philip Gladstone contributed the concept of macros to the 1844 specification, multiplying the expressiveness of the language and 1845 making per-user and per-IP lookups possible. 1847 The authors of bothe this document and [RFC4408] would also like to 1848 thank the literally hundreds of individuals who have participated in 1849 the development of this design. They are far too numerous to name, 1850 but they include the following: 1852 The participants in the SPFbis working group. 1853 The folks on the spf-discuss mailing list. 1854 The folks on the SPAM-L mailing list. 1855 The folks on the IRTF ASRG mailing list. 1856 The folks on the IETF MARID mailing list. 1857 The folks on #perl. 1859 12. IANA Considerations 1861 12.1. The SPF DNS Record Type 1863 Per [RFC4408], the IANA assigned the Resource Record Type and Qtype 1864 from the DNS Parameters Registry for the SPF RR type with code 99. 1865 The format of this type is identical to the TXT RR [RFC1035]. The 1866 character content of the record is encoded as [US-ASCII]. Use of 1867 this record type is obsolete for SPF Version 1. 1869 IANA is requested to add (to be changed to "has added" upon 1870 publication) an annotation to the SPF RRTYPE saying "(OBSOLETE - use 1871 TXT)" in the DNS Parameters registry. 1873 12.2. The Received-SPF Mail Header Field 1875 Per [RFC3864], the "Received-SPF:" header field is added to the IANA 1876 Permanent Message Header Field Registry. The following is the 1877 registration template: 1879 Header field name: Received-SPF 1880 Applicable protocol: mail ([RFC5322]) 1881 Status: Standards Track 1882 Author/Change controller: IETF 1883 Specification document(s): [RFC4408], RFC XXXX 1885 13. References 1887 13.1. Normative References 1889 [RFC1035] Mockapetris, P., "Domain names - implementation and 1890 specification", STD 13, RFC 1035, November 1987. 1892 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1893 and Support", STD 3, RFC 1123, October 1989. 1895 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1896 Requirement Levels", BCP 14, RFC 2119, March 1997. 1898 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 1899 RFC 3463, January 2003. 1901 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1902 Procedures for Message Header Fields", BCP 90, RFC 3864, 1903 September 2004. 1905 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1906 Resource Identifier (URI): Generic Syntax", STD 66, 1907 RFC 3986, January 2005. 1909 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1910 Architecture", RFC 4291, February 2006. 1912 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1913 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1915 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1916 October 2008. 1918 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1919 October 2008. 1921 [US-ASCII] 1922 American National Standards Institute (formerly United 1923 States of America Standards Institute), "USA Code for 1924 Information Interchange, X3.4", 1968. 1926 ANSI X3.4-1968 has been replaced by newer versions with 1927 slight modifications, but the 1968 version remains 1928 definitive for the Internet. 1930 13.2. Informative References 1932 [DMP] Fecyk, G., "Designated Mailers Protocol". 1934 Work In Progress 1936 [Green] Green, D., "Domain-Authorized SMTP Mail", 2002. 1938 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1939 STD 13, RFC 1034, November 1987. 1941 [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, 1942 August 1996. 1944 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1945 NCACHE)", RFC 2308, March 1998. 1947 [RFC3696] Klensin, J., "Application Techniques for Checking and 1948 Transformation of Names", RFC 3696, February 2004. 1950 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 1951 Name System (DNS)", RFC 3833, August 2004. 1953 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 1954 for Authorizing Use of Domains in E-Mail, Version 1", 1955 RFC 4408, April 2006. 1957 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1958 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1960 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 1961 for Authentication", RFC 4954, July 2007. 1963 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 1964 July 2009. 1966 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1967 Mail Extensions (S/MIME) Version 3.2 Message 1968 Specification", RFC 5751, January 2010. 1970 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 1971 STD 72, RFC 6409, November 2011. 1973 [RFC6647] Kucherawy, M. and D. Crocker, "Email Greylisting: An 1974 Applicability Statement for SMTP", RFC 6647, June 2012. 1976 [RFC6652] Kitterman, S., "Sender Policy Framework (SPF) 1977 Authentication Failure Reporting Using the Abuse Reporting 1978 Format", RFC 6652, June 2012. 1980 [RMX] Danisch, H., "The RMX DNS RR Type for light weight sender 1981 authentication". 1983 Work In Progress 1985 [Vixie] Vixie, P., "Repudiating MAIL FROM", 2002. 1987 [draft-ietf-spfbis-experiment] 1988 Kucherawy, M., "Resolution of The SPF and Sender ID 1989 Experiments", draft-ietf-spfbis-experiment (work in 1990 progress), 2012. 1992 Appendix A. Collected ABNF 1994 This section is normative and any discrepancies with the ABNF 1995 fragments in the preceding text are to be resolved in favor of this 1996 grammar. 1998 See [RFC5234] for ABNF notation. Please note that as per this ABNF 1999 definition, literal text strings (those in quotes) are case- 2000 insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx". 2002 record = version terms *SP 2003 version = "v=spf1" 2005 terms = *( 1*SP ( directive / modifier ) ) 2007 directive = [ qualifier ] mechanism 2008 qualifier = "+" / "-" / "?" / "~" 2009 mechanism = ( all / include 2010 / A / MX / PTR / IP4 / IP6 / exists ) 2012 all = "all" 2013 include = "include" ":" domain-spec 2014 A = "a" [ ":" domain-spec ] [ dual-cidr-length ] 2015 MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] 2016 PTR = "ptr" [ ":" domain-spec ] 2017 IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] 2018 IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] 2019 exists = "exists" ":" domain-spec 2021 modifier = redirect / explanation / unknown-modifier 2022 redirect = "redirect" "=" domain-spec 2023 explanation = "exp" "=" domain-spec 2024 unknown-modifier = name "=" macro-string 2025 ; where name is not any known modifier 2027 ip4-cidr-length = "/" 1*DIGIT 2028 ip6-cidr-length = "/" 1*DIGIT 2029 dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] 2031 ip4-network = qnum "." qnum "." qnum "." qnum 2032 qnum = DIGIT ; 0-9 2033 / %x31-39 DIGIT ; 10-99 2034 / "1" 2DIGIT ; 100-199 2035 / "2" %x30-34 DIGIT ; 200-249 2036 / "25" %x30-35 ; 250-255 2037 ; conventional dotted quad notation. e.g., 192.0.2.0 2038 ip6-network = 2039 ; e.g., 2001:DB8::CD30 2041 domain-spec = macro-string domain-end 2042 domain-end = ( "." toplabel [ "." ] ) / macro-expand 2044 toplabel = ( *alphanum ALPHA *alphanum ) / 2045 ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) 2046 ; LDH rule plus additional TLD restrictions 2047 ; (see [RFC3696], Section 2 for background) 2048 alphanum = ALPHA / DIGIT 2050 explain-string = *( macro-string / SP ) 2052 macro-string = *( macro-expand / macro-literal ) 2053 macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) 2054 / "%%" / "%_" / "%-" 2055 macro-literal = %x21-24 / %x26-7E 2056 ; visible characters except "%" 2057 macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / 2058 "c" / "r" / "t" / "v" 2059 transformers = *DIGIT [ "r" ] 2060 delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" 2062 name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) 2064 header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] 2065 [ key-value-list ] CRLF 2067 result = "pass" / "fail" / "softfail" / "neutral" / 2068 "none" / "temperror" / "permerror" 2070 key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) 2071 [";"] 2073 key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) 2075 key = "client-ip" / "envelope-from" / "helo" / 2076 "problem" / "receiver" / identity / 2077 mechanism / name 2079 identity = "mailfrom" ; for the "MAIL FROM" identity 2080 / "helo" ; for the "HELO" identity 2081 / name ; other identities 2083 ALPHA = 2084 DIGIT = <0-9 as per [RFC5234]> 2085 SP = 2086 dot-atom = 2087 quoted-string = 2088 comment = 2089 CFWS = 2090 FWS = 2091 CRLF = 2093 Appendix B. Extended Examples 2095 These examples are based on the following DNS setup: 2097 ; A domain with two mail servers, two hosts 2098 ; and two servers at the domain name 2099 $ORIGIN example.com. 2100 @ MX 10 mail-a 2101 MX 20 mail-b 2102 A 192.0.2.10 2103 A 192.0.2.11 2104 amy A 192.0.2.65 2105 bob A 192.0.2.66 2106 mail-a A 192.0.2.129 2107 mail-b A 192.0.2.130 2108 www CNAME example.com. 2110 ; A related domain 2111 $ORIGIN example.org. 2112 @ MX 10 mail-c 2113 mail-c A 192.0.2.140 2115 ; The reverse IP for those addresses 2116 $ORIGIN 2.0.192.in-addr.arpa. 2117 10 PTR example.com. 2118 11 PTR example.com. 2119 65 PTR amy.example.com. 2120 66 PTR bob.example.com. 2121 129 PTR mail-a.example.com. 2122 130 PTR mail-b.example.com. 2123 140 PTR mail-c.example.org. 2125 ; A rogue reverse IP domain that claims to be 2126 ; something it's not 2127 $ORIGIN 0.0.10.in-addr.arpa. 2128 4 PTR bob.example.com. 2130 B.1. Simple Examples 2132 These examples show various possible published records for 2133 example.com and which values if would cause check_host() to 2134 return "pass". Note that is "example.com". 2136 v=spf1 +all 2137 -- any passes 2139 v=spf1 a -all 2140 -- hosts 192.0.2.10 and 192.0.2.11 pass 2142 v=spf1 a:example.org -all 2143 -- no sending hosts pass since example.org has no A records 2145 v=spf1 mx -all 2146 -- sending hosts 192.0.2.129 and 192.0.2.130 pass 2148 v=spf1 mx:example.org -all 2149 -- sending host 192.0.2.140 passes 2151 v=spf1 mx mx:example.org -all 2152 -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass 2154 v=spf1 mx/30 mx:example.org/30 -all 2155 -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes 2157 v=spf1 ptr -all 2158 -- sending host 192.0.2.65 passes (reverse DNS is valid and is in 2159 example.com) 2160 -- sending host 192.0.2.140 fails (reverse DNS is valid, but not 2161 in example.com) 2162 -- sending host 10.0.0.4 fails (reverse IP is not valid) 2164 v=spf1 ip4:192.0.2.128/28 -all 2165 -- sending host 192.0.2.65 fails 2166 -- sending host 192.0.2.129 passes 2168 B.2. Multiple Domain Example 2170 These examples show the effect of related records: 2172 example.org: "v=spf1 include:example.com include:example.net -all" 2174 This record would be used if mail from example.org actually came 2175 through servers at example.com and example.net. Example.org's 2176 designated servers are the union of example.com's and example.net's 2177 designated servers. 2179 la.example.org: "v=spf1 redirect=example.org" 2180 ny.example.org: "v=spf1 redirect=example.org" 2181 sf.example.org: "v=spf1 redirect=example.org" 2183 These records allow a set of domains that all use the same mail 2184 system to make use of that mail system's record. In this way, only 2185 the mail system's record needs to be updated when the mail setup 2186 changes. These domains' records never have to change. 2188 B.3. DNSBL Style Example 2190 Imagine that, in addition to the domain records listed above, there 2191 are these: 2193 $ORIGIN _spf.example.com. 2194 mary.mobile-users A 127.0.0.2 2195 fred.mobile-users A 127.0.0.2 2196 15.15.168.192.joel.remote-users A 127.0.0.2 2197 16.15.168.192.joel.remote-users A 127.0.0.2 2199 The following records describe users at example.com who mail from 2200 arbitrary servers, or who mail from personal servers. 2202 example.com: 2204 v=spf1 mx 2205 include:mobile-users._spf.%{d} 2206 include:remote-users._spf.%{d} 2207 -all 2209 mobile-users._spf.example.com: 2211 v=spf1 exists:%{l1r+}.%{d} 2213 remote-users._spf.example.com: 2215 v=spf1 exists:%{ir}.%{l1r+}.%{d} 2217 B.4. Multiple Requirements Example 2219 Say that your sender policy requires both that the IP address is 2220 within a certain range and that the reverse DNS for the IP matches. 2221 This can be done several ways, including the following: 2223 example.com. SPF ( "v=spf1 " 2224 "-include:ip4._spf.%{d} " 2225 "-include:ptr._spf.%{d} " 2226 "+all" ) 2227 ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all" 2228 ptr._spf.example.com. SPF "v=spf1 -ptr +all" 2230 This example shows how the "-include" mechanism can be useful, how an 2231 SPF record that ends in "+all" can be very restrictive, and the use 2232 of De Morgan's Law. 2234 Appendix C. Change History 2236 Changes since RFC 4408 (to be removed prior to publication) 2238 Moved to standards track 2240 Authors updated 2242 IESG Note regarding experimental use replaced with discussion of 2243 results 2245 Process errata: 2247 Add %v macro to ABNF grammar 2249 Replace "uric" by "unreserved" 2251 Recommend an SMTP reply code for optional permerror rejections 2253 Correct syntax in Received-SPF examples 2255 Fix unknown-modifier clause is too greedy in ABNF 2257 Correct use of empty domain-spec on exp modifier 2259 Fix minor typo errata 2261 Convert to spfbis working group draft, 2262 draft-ietf-spfbis-4408bis-00 2264 Addressed Ticket #1, RFC 4408 Section 2.5.6 - Temporary errors by 2265 giving the option to turn repeated SERVFAIL into permerror and 2266 adding RFC 2308 reference. 2268 Clarified text about IPv4 mapped addresses to resolve test suite 2269 ambiguity 2271 Clarified ambiguity about result when more than 10 "mx" or "ptr" 2272 records are returned for lookup to specify permerror. This 2273 resolves one of the test suite ambiguities 2275 Made all references to result codes lower case per issue #7 2277 Adjusted section 2.2 Requirement to check mail from per issue #15 2279 Added missing "v" element in macro-letter in the collected ABNF 2280 per issue #16 - section 8.1 was already fixed in the pre-WG draft 2281 Marked ptr and "p" macro deprecated/SHOULD NOT use per issue #27 2283 Expunged lower case may from the draft per issue #8 2285 Expunged "x-" name as an obsolete concept 2287 Updated obslete references: RFC2821 to RFC5321, RFC2822 to 2288 RFC5322, and RFC4234 to RFC5234 2290 Refer to RFC6647 to describe greylisting instead of trying to 2291 describe it directly. 2293 Updated informative references to the current versions. 2295 Added definition for deprecated since there are questions. 2297 Start to rework section 9 with some RFC5598 terms. 2299 Added mention of RFC 6552 feedback reports in section 9. 2301 Added draft-ietf-spfbis-experiment as an informational reference. 2303 Drop Type SPF. 2305 Try and clarify informational nature of RFC3696 2307 Fix ABNF nits and add missing definitions per Bill's ABNF checker. 2309 Make DNS lookup time limit SHOULD instead of MAY. 2311 Reorganize and clarify processing limits. Move hard limits to new 2312 section 4.6.4, Evaluation Limits. Move advice to non-normative 2313 section 9. 2315 Removed paragraph in section 10.1 about limiting total data 2316 volumes as it is unused (and removable per the charter) and serves 2317 no purpose (it isn't something that actually can be implemented in 2318 any reasonable way). 2320 Author's Address 2322 Scott Kitterman 2323 Agari 2324 3611 Scheel Dr 2325 Ellicott City, MD 21042 2326 United States of America 2328 Email: scott@kitterman.com