idnits 2.17.1 draft-ietf-spfbis-4408bis-21.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 6 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 1733 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 (September 26, 2013) is 3837 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 2209, but not defined ** Obsolete normative reference: RFC 5451 (Obsoleted by RFC 7001) ** Downref: Normative reference to an Informational RFC: RFC 5598 -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- 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: 2 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Kitterman 3 Internet-Draft Kitterman Technical Services 4 Obsoletes: 4408 (if approved) September 26, 2013 5 Intended status: Standards Track 6 Expires: March 30, 2014 8 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, 9 Version 1 10 draft-ietf-spfbis-4408bis-21 12 Abstract 14 Email 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 "MAIL FROM" 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 ADministrative 19 Management Domains (ADMDs) can explicitly authorize the hosts that 20 are allowed to use its domain names, and a receiving host can check 21 such authorization. 23 This document obsoletes RFC4408. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 30, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 73 1.1.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . 6 74 1.1.2. Imported Definitions . . . . . . . . . . . . . . . . . 6 75 1.1.3. MAIL FROM Definition . . . . . . . . . . . . . . . . . 7 76 1.1.4. HELO Definition . . . . . . . . . . . . . . . . . . . 7 77 1.2. check_host() . . . . . . . . . . . . . . . . . . . . . . . 7 78 2. Operational Overview . . . . . . . . . . . . . . . . . . . . . 8 79 2.1. Publishing Authorization . . . . . . . . . . . . . . . . . 8 80 2.2. Checking Authorization . . . . . . . . . . . . . . . . . . 8 81 2.3. The "HELO" Identity . . . . . . . . . . . . . . . . . . . 9 82 2.4. The "MAIL FROM" Identity . . . . . . . . . . . . . . . . . 10 83 2.5. Location of Checks . . . . . . . . . . . . . . . . . . . . 10 84 2.6. Results of Evaluation . . . . . . . . . . . . . . . . . . 11 85 2.6.1. None . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 2.6.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 11 87 2.6.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 2.6.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 2.6.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . 11 90 2.6.6. Temperror . . . . . . . . . . . . . . . . . . . . . . 11 91 2.6.7. Permerror . . . . . . . . . . . . . . . . . . . . . . 12 92 3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 3.1. DNS Resource Records . . . . . . . . . . . . . . . . . . . 13 94 3.2. Multiple DNS Records . . . . . . . . . . . . . . . . . . . 14 95 3.3. Multiple Strings in a Single DNS record . . . . . . . . . 14 96 3.4. Record Size . . . . . . . . . . . . . . . . . . . . . . . 15 97 3.5. Wildcard Records . . . . . . . . . . . . . . . . . . . . . 15 98 4. The check_host() Function . . . . . . . . . . . . . . . . . . 17 99 4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 17 100 4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 17 101 4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 18 102 4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 18 103 4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 18 104 4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 19 105 4.6.1. Term Evaluation . . . . . . . . . . . . . . . . . . . 19 106 4.6.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 19 107 4.6.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . 20 108 4.6.4. DNS Lookup Limits . . . . . . . . . . . . . . . . . . 20 109 4.7. Default Result . . . . . . . . . . . . . . . . . . . . . . 21 110 4.8. Domain Specification . . . . . . . . . . . . . . . . . . . 22 111 5. Mechanism Definitions . . . . . . . . . . . . . . . . . . . . 23 112 5.1. "all" . . . . . . . . . . . . . . . . . . . . . . . . . . 24 113 5.2. "include" . . . . . . . . . . . . . . . . . . . . . . . . 24 114 5.3. "a" . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 115 5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 116 5.5. "ptr" (do not use) . . . . . . . . . . . . . . . . . . . . 26 117 5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 28 118 5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 28 119 6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 30 120 6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 30 121 6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 31 122 7. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 123 7.1. Formal Specification . . . . . . . . . . . . . . . . . . . 33 124 7.2. Macro Definitions . . . . . . . . . . . . . . . . . . . . 33 125 7.3. Macro Processing Details . . . . . . . . . . . . . . . . . 34 126 7.4. Expansion Examples . . . . . . . . . . . . . . . . . . . . 36 127 8. Result Handling . . . . . . . . . . . . . . . . . . . . . . . 38 128 8.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 129 8.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . . . 38 130 8.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 131 8.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 132 8.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . . . 39 133 8.6. Temperror . . . . . . . . . . . . . . . . . . . . . . . . 40 134 8.7. Permerror . . . . . . . . . . . . . . . . . . . . . . . . 40 135 9. Recording the Result . . . . . . . . . . . . . . . . . . . . . 41 136 9.1. The Received-SPF Header Field . . . . . . . . . . . . . . 41 137 9.2. SPF Results in the Authentication-Results Header Field . . 43 138 10. Effects on Infrastructure . . . . . . . . . . . . . . . . . . 45 139 10.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 45 140 10.1.1. DNS Resource Considerations . . . . . . . . . . . . . 45 141 10.1.2. Administrator's Considerations . . . . . . . . . . . . 46 142 10.1.3. Bounces . . . . . . . . . . . . . . . . . . . . . . . 47 143 10.2. Receivers . . . . . . . . . . . . . . . . . . . . . . . . 47 144 10.3. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 47 145 11. Security Considerations . . . . . . . . . . . . . . . . . . . 49 146 11.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 49 147 11.2. SPF-Authorized Email May Contain Other False Identities . 50 148 11.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 50 149 11.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 50 150 11.5. Untrusted Information Sources . . . . . . . . . . . . . . 51 151 11.5.1. Recorded Results . . . . . . . . . . . . . . . . . . . 51 152 11.5.2. External Explanations . . . . . . . . . . . . . . . . 51 153 11.5.3. Macro Expansion . . . . . . . . . . . . . . . . . . . 52 154 11.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 52 155 11.7. Delivering Mail Producing a 'Fail' Result . . . . . . . . 52 156 12. Collected ABNF . . . . . . . . . . . . . . . . . . . . . . . . 53 157 13. Contributors and Acknowledgements . . . . . . . . . . . . . . 56 158 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 159 14.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 57 160 14.2. The Received-SPF Mail Header Field . . . . . . . . . . . . 57 161 14.3. SPF Modifier Registry . . . . . . . . . . . . . . . . . . 57 162 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 163 15.1. Normative References . . . . . . . . . . . . . . . . . . . 58 164 15.2. Informative References . . . . . . . . . . . . . . . . . . 59 166 Appendix A. Extended Examples . . . . . . . . . . . . . . . . . . 61 167 A.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 61 168 A.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 62 169 A.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 63 170 A.4. Multiple Requirements Example . . . . . . . . . . . . . . 63 171 Appendix B. Changes in implementation requirements from RFC 172 4408 . . . . . . . . . . . . . . . . . . . . . . . . 64 173 Appendix C. Further Testing Advice . . . . . . . . . . . . . . . 65 174 Appendix D. SPF/Mediator Interactions . . . . . . . . . . . . . . 66 175 D.1. Originating ADMDs . . . . . . . . . . . . . . . . . . . . 66 176 D.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 67 177 D.3. Receiving ADMDs . . . . . . . . . . . . . . . . . . . . . 67 178 Appendix E. Mail Services . . . . . . . . . . . . . . . . . . . . 68 179 Appendix F. MTA Relays . . . . . . . . . . . . . . . . . . . . . 69 180 Appendix G. Local Policy Considerations . . . . . . . . . . . . . 70 181 G.1. Policy For SPF Pass . . . . . . . . . . . . . . . . . . . 70 182 G.2. Policy For SPF Fail . . . . . . . . . . . . . . . . . . . 70 183 G.3. Policy For SPF Permerror . . . . . . . . . . . . . . . . . 71 184 G.4. Policy For SPF Temperror . . . . . . . . . . . . . . . . . 71 185 Appendix H. Protocol Status . . . . . . . . . . . . . . . . . . . 73 186 Appendix I. Change History . . . . . . . . . . . . . . . . . . . 74 187 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 77 189 1. Introduction 191 The current email infrastructure has the property that any host 192 injecting mail into the system can use any DNS domain name it wants 193 in each of the various identifiers specified by [RFC5321] and 194 [RFC5322]. Although this feature is desirable in some circumstances, 195 it is a major obstacle to reducing Unsolicited Bulk Email (UBE, aka 196 spam). Furthermore, many domain owning ADMDs (as described in 197 [RFC5598]) are understandably concerned about the ease with which 198 other entities can make use of their domain names, often with 199 malicious intent. 201 This document defines a protocol by which ADMDs can authorize hosts 202 to use their domain names in the "MAIL FROM" or "HELO" identities. 203 Compliant ADMDs publish Sender Policy Framework (SPF) records in the 204 DNS specifying which hosts are permitted to use their names, and 205 compliant mail receivers use the published SPF records to test the 206 authorization of sending Mail Transfer Agents (MTAs) using a given 207 "HELO" or "MAIL FROM" identity during a mail transaction. 209 An additional benefit to mail receivers is that after the use of an 210 identity is verified, local policy decisions about the mail can be 211 made based on the sender's domain, rather than the host's IP address. 212 This is advantageous because reputation of domain names is likely to 213 be more accurate than reputation of host IP addresses since domains 214 are likely to be more stable over a longer period. Furthermore, if a 215 claimed identity fails verification, local policy can take stronger 216 action against such email, such as rejecting it. 218 1.1. Terminology 220 1.1.1. Keywords 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 224 "OPTIONAL" in this document are to be interpreted as described in 225 [RFC2119]. 227 1.1.2. Imported Definitions 229 ABNF (Augmented Backus-Naur Form) ABNF is defined in [RFC5234], as 230 are the tokens "ALPHA", "DIGIT", and "SP" (space). 232 The tokens "Local-part", "Domain", and "Mailbox are defined in 233 [RFC5321]. 235 "dot-atom", "quoted-string", "comment", "CFWS" (comment folded white 236 space), "FWS" (folded white space), and "CRLF" (carriage-return/ 237 line-feed) are defined in [RFC5322]. 239 1.1.3. MAIL FROM Definition 241 This document is concerned with the identity of the sender of a mail 242 message, as referred to in [RFC5321]: 244 "The transaction starts with a MAIL command that gives the sender 245 identification." 247 Since there are many other names for this identity, it is important 248 to choose a name that is: 250 1. commonly used 252 2. well defined 254 As such, throughout this document the term "MAIL FROM" will be used, 255 which is defined as the RFC5321.MailFrom (reverse-path) identity 256 described in [RFC5598]. 258 1.1.4. HELO Definition 260 This document also makes use of the HELO/EHLO identity. The "HELO" 261 identity derives from either the SMTP HELO or EHLO command (see 262 [RFC5321]). Since HELO and EHLO can, in many cases, be used 263 interchangeably, they are identified commonly as "HELO" in this 264 document. This means RFC5321.HELO/.EHLO as defined in [RFC5598]. 265 These commands supply the identity of the SMTP client (sending host) 266 for the SMTP session. 268 1.2. check_host() 270 Section 4 introduces an algorithm to evaluate an SPF policy against 271 an arriving email transaction. In an early implementation, this 272 algorithm was encoded in a function called check_host(). That name 273 is used in this document as symbolic of the SPF evaluation algorithm, 274 but of course implementers are not required to use this name. 276 2. Operational Overview 278 2.1. Publishing Authorization 280 An SPF-compliant domain publishes valid SPF records as described in 281 Section 3. These records authorize the use of the relevant domain 282 names in the "HELO" and "MAIL FROM" identities by the MTAs specified 283 therein. 285 SPF results can be used to make both positive (source is authorized) 286 and negative (source is not authorized) determinations. If ADMDs 287 choose to publish SPF records and want to support receivers making 288 negative authorization determinations, it is necessary for them to 289 publish records that end in "-all", or redirect to other records that 290 do, otherwise, no definitive determination of authorization can be 291 made. Potential issues and mitigations associated with negative 292 determinations are discussed in Section 10. 294 ADMDs that wish to declare that no hosts are authorized to use their 295 DNS domain names in the HELO or MAIL FROM commands during SMTP 296 sessions can publish SPF records that say so for domain names that 297 are neither used in the domain part of email addresses nor expected 298 to originate mail. 300 When changing SPF records, care has to be taken to ensure that there 301 is a transition period so that the old policy remains valid until all 302 legitimate email can reasonably expect to have been checked. 303 [RFC5321] Section 4.5.4.1 discusses how long a message might be in 304 transit. While offline checks are possible, the closer to the 305 original transmission time checks are performed, the more likely they 306 are to get an SPF result that matches the sending ADMD intent at the 307 time the message was sent. 309 2.2. Checking Authorization 311 A mail receiver can perform a set of SPF checks for each mail message 312 it receives. An SPF check tests the authorization of a client host 313 to emit mail with a given identity. Typically, such checks are done 314 by a receiving MTA, but can be performed elsewhere in the mail 315 processing chain so long as the required information is available and 316 reliable. The "MAIL FROM" and "HELO" identities are checked as 317 described in Section 2.4 and Section 2.3 respectively. 319 Without explicit approval of the publishing ADMD, checking other 320 identities against SPF version 1 records is NOT RECOMMENDED because 321 there are cases that are known to give incorrect results. For 322 example, almost all mailing lists rewrite the "MAIL FROM" identity 323 (see Section 10.3), but some do not change any other identities in 324 the message. Documents that define other identities will have to 325 define the method for explicit approval. 327 It is possible that mail receivers will use the SPF check as part of 328 a larger set of tests on incoming mail. The results of other tests 329 might influence whether or not a particular SPF check is performed. 330 For example, finding the sending host's IP address on a local white 331 list might cause all other tests to be skipped and all mail from that 332 host to be accepted. 334 When a mail receiver decides to perform an SPF check, it has to use a 335 correctly-implemented check_host() function (Section 4) evaluated 336 with the correct parameters. Although the test as a whole is 337 optional, once it has been decided to perform a test it has to be 338 performed as specified so that the correct semantics are preserved 339 between publisher and receiver. 341 To make the test, the mail receiver MUST evaluate the check_host() 342 function with the arguments described in Section 4.1. 344 Although invalid, malformed, or non-existent domains cause SPF checks 345 to return "none" because no SPF record can be found, it has long been 346 the policy of many MTAs to reject email from such domains, especially 347 in the case of invalid "MAIL FROM". Rejecting email will prevent one 348 method of circumventing of SPF records. 350 Implementations have to take care to correctly extract the 351 from the data given with the SMTP MAIL FROM command as many MTAs will 352 still accept such things as source routes (see [RFC5321], Appendix 353 C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). 354 These archaic features have been maliciously used to bypass security 355 systems. 357 2.3. The "HELO" Identity 359 It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" 360 identity, but also separately check the "HELO" identity by applying 361 the check_host() function (Section 4) to the "HELO" identity as the 362 . Checking "HELO" promotes consistency of results and can 363 reduce DNS resource usage. If a conclusive determination about the 364 message can be made based on a check of "HELO", then the use of DNS 365 resources to process the typically more complex "MAIL FROM" can be 366 avoided. Additionally, since SPF records published for "HELO" 367 identities refer to a single host, when available, they are a very 368 reliable source of host authorization status. Checking "HELO" before 369 "MAIL FROM" is the RECOMMENDED sequence if both are checked. 371 Note that requirements for the domain presented in the EHLO or HELO 372 command are not always clear to the sending party, and SPF verifiers 373 have to be prepared for the identity to be an IP address literal (see 374 [RFC5321] section 4.1.3), or simply be malformed. This SPF check can 375 only be performed when the "HELO" string is a valid, multi-label 376 domain name. 378 2.4. The "MAIL FROM" Identity 380 SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check 381 has either not been performed or has not reached a definitive policy 382 result by applying the check_host() function to the "MAIL FROM" 383 identity as the . 385 [RFC5321] allows the reverse-path to be null (see Section 4.5.5 in 386 [RFC5321]). In this case, there is no explicit sender mailbox, and 387 such a message can be assumed to be a notification message from the 388 mail system itself. When the reverse-path is null, this document 389 defines the "MAIL FROM" identity to be the mailbox composed of the 390 local-part "postmaster" and the "HELO" identity (which might or might 391 not have been checked separately before). 393 2.5. Location of Checks 395 The authorization check SHOULD be performed during the processing of 396 the SMTP transaction that receives the mail. This reduces the 397 complexity of determining the correct IP address to use as an input 398 to check_host() and allows errors to be returned directly to the 399 sending MTA by way of SMTP replies. Appendix C of [RFC5451] provides 400 a more thorough discussion of this topic. 402 The authorization check is performed during the SMTP transaction at 403 the time of the MAIL command, and uses the MAIL FROM value and the 404 client IP address. Performing the check at later times or with other 405 input can cause problems such as the following: 407 o It might be difficult to accurately extract the required 408 information from potentially deceptive headers. 410 o Legitimate email might fail the authorization check because the 411 sender's policy has since changed. 413 Generating non-delivery notifications to forged identities that have 414 failed the authorization check often constitutes backscatter, i.e., 415 inactionable, nuisance rejection notices. Operators are strongly 416 advised to avoid such practices. Section 2 of [RFC3834] describes 417 backscatter and the problems it causes. 419 2.6. Results of Evaluation 421 Section 4 defines check_host(), a model function definition that uses 422 the inputs defined above and the sender's policy published in the DNS 423 to reach a conclusion about client authorization. An SPF verifier 424 implements something semantically equivalent to the function defined 425 there. 427 This section enumerates and briefly defines the possible outputs of 428 that function. Note, however, that the protocol establishes no 429 normative requirements for handling any particular result. 430 Discussion of handling options for each result can be found in 431 Section 8. 433 2.6.1. None 435 A result of "none" means either (a) no syntactically valid DNS domain 436 name was extracted from the SMTP session that could be used as the 437 one to be authorized, or (b) no SPF records were retrieved from the 438 DNS. 440 2.6.2. Neutral 442 A "neutral" result means that the ADMD has explicitly stated that it 443 is not asserting whether the IP address is authorized. 445 2.6.3. Pass 447 A "pass" result is an explicit statement that the client is 448 authorized to inject mail with the given identity. 450 2.6.4. Fail 452 A "fail" result is an explicit statement that the client is not 453 authorized to use the domain in the given identity. 455 2.6.5. Softfail 457 A "softfail" result is a weak statement by the publishing ADMD that 458 the host is probably not authorized. It has not published a 459 stronger, more definitive policy that results in a "fail". 461 2.6.6. Temperror 463 A "temperror" result means the SPF verifier encountered a transient 464 (generally DNS) error while performing the check. A later retry may 465 succeed without further DNS operator action. 467 2.6.7. Permerror 469 A "permerror" result means the domain's published records could not 470 be correctly interpreted. This signals an error condition that 471 definitely requires DNS operator intervention to be resolved. 473 3. SPF Records 475 An SPF record is a DNS record that declares which hosts are, and are 476 not, authorized to use a domain name for the "HELO" and "MAIL FROM" 477 identities. Loosely, the record partitions hosts into permitted and 478 not-permitted sets (though some hosts might fall into neither 479 category). 481 The SPF record is expressed as a single string of text found in the 482 RDATA of a single DNS TXT resource record; multiple SPF records are 483 not permitted for the same owner name. The record format and the 484 process for selecting records is described below in Section 4. An 485 example record is the following: 487 v=spf1 +mx a:colo.example.com/28 -all 489 This record has a version of "spf1" and three directives: "+mx", 490 "a:colo.example.com/28" (the + is implied), and "-all". 492 Each SPF record is placed in the DNS tree at the owner name it 493 pertains to, not in a subdomain under the owner name. This is 494 similar to how SRV records [RFC2782] are done. 496 The example in this section might be published via these lines in a 497 domain zone file: 499 example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" 501 Since TXT records have multiple uses, beware of other TXT records 502 published there for other purposes. They might cause problems with 503 size limits (see Section 3.4) and care has to be taken to ensure only 504 SPF records are used for SPF processing. 506 ADMDs publishing SPF records ought to keep the amount of DNS 507 information needed to evaluate a record to a minimum. Section 4.6.4 508 and Section 10.1.1 provide some suggestions about "include" 509 mechanisms and chained "redirect" modifiers. 511 3.1. DNS Resource Records 513 SPF records MUST be published as a DNS TXT (type 16) Resource Record 514 (RR) [RFC1035] only. The character content of the record is encoded 515 as [US-ASCII]. Use of alternative DNS RR types was supported in 516 SPF's experimental phase, but has been discontinued. 518 In 2003, when SPF was first being developed, the requirements for 519 assignment of a new DNS RR type were considerably more stringent than 520 they are now. Additionally, support for easy deployment of new DNS 521 RR types was not widely deployed in DNS servers and provisioning 522 systems. As a result, developers of SPF found it easier and more 523 practical to use the TXT RR type for SPF records. 525 In its review of [RFC4408] the SPFbis working group concluded that 526 its dual RR type transition model was fundamentally flawed since it 527 contained no common RR type that implementers were required to serve 528 and required to check. Many alternatives were considered to resolve 529 this issue, but ultimately the working group concluded that 530 significant migration to the SPF RR type in the forseeable future was 531 very unlikely and that the best solution for resolving this 532 interoperability issue was to drop support for the SPF RR type from 533 SPF version 1. See Appendix A of [RFC6686] for further information. 535 The circumstances surrounding SPF's initial deployment a decade ago 536 are unique. If a future update to SPF were developed that did not 537 reuse existing SPF records, it could use the SPF RR type. SPF's use 538 of the TXT RR type for structured data should in no way be taken as 539 precedent for future protocol designers. Further discussion of 540 design considerations when using new DNS RR types can be found in 541 [RFC5507]. 543 3.2. Multiple DNS Records 545 A domain name MUST NOT have multiple records that would cause an 546 authorization check to select more than one record. See Section 4.5 547 for the selection rules. 549 3.3. Multiple Strings in a Single DNS record 551 As defined in [RFC1035] sections 3.3 and 3.3.14, a single text DNS 552 record can be composed of more than one string. If a published 553 record contains multiple character-strings, then the record MUST be 554 treated as if those strings are concatenated together without adding 555 spaces. For example: 557 IN TXT "v=spf1 .... first" "second string..." 559 is equivalent to: 561 IN TXT "v=spf1 .... firstsecond string..." 563 TXT records containing multiple strings are useful in constructing 564 records that would exceed the 255-octet maximum length of a 565 character-string within a single TXT record. 567 3.4. Record Size 569 The published SPF record for a given domain name SHOULD remain small 570 enough that the results of a query for it will fit within 512 octets. 571 This UDP limit is defined in [RFC1035] section 2.3.4, although it was 572 raised by [RFC2671]. Staying below 512 octets ought to prevent older 573 DNS implementations from failing over to TCP,and will work with UDP 574 in the absence of EDNS0 [RFC6891] support. Since the answer size is 575 dependent on many things outside the scope of this document, it is 576 only possible to give this guideline: If the size of the DNS message, 577 the combined length of the DNS name and the text of all the records 578 of a given type is under 450 octets, then DNS answers ought to fit in 579 UDP packets. Records that are too long to fit in a single UDP packet 580 could be silently ignored by SPF verifiers due to firewall and other 581 issues that interfere with the operation of DNS over TCP or using 582 ENDS0. 584 Note that when computing the sizes for replies to queries of the TXT 585 format, one has to take into account any other TXT records published 586 at the domain name. Similarly, the sizes for replies to all queries 587 related to SPF have to be evaluated to fit in a single 512 octet UDP 588 packet (i.e. DNS message size limited to 450 octects). 590 3.5. Wildcard Records 592 Use of wildcard records for publishing is discouraged and care has to 593 be taken if they are used. If a zone includes wildcard MX records, 594 it might want to publish wildcard declarations, subject to the same 595 requirements and problems. In particular, the declaration MUST be 596 repeated for any host that has any RR records at all, and for 597 subdomains thereof. Consider the example in [RFC1034], Section 598 4.3.3. Based on that, we can do the following: 600 EXAMPLE.COM. MX 10 A.EXAMPLE.COM 601 EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all" 603 *.EXAMPLE.COM. MX 10 A.EXAMPLE.COM 604 *.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all" 606 A.EXAMPLE.COM. A 203.0.113.1 607 A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM 608 A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all" 610 *.A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM 611 *.A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all" 613 SPF records have to be listed twice for every name within the zone: 614 once for the name, and once with a wildcard to cover the tree under 615 the name, in order to cover all domains in use in outgoing mail. 617 4. The check_host() Function 619 This description is not an application programming interface 620 definition, but rather a function description used to illustrate the 621 algorithm. A compliant SPF implementation MUST produce results 622 semantically equivalent to this description. 624 The check_host() function fetches SPF records, parses them, and 625 evaluates them to determine whether a particular host is or is not 626 permitted to send mail with a given identity. Receiving ADMDs that 627 perform this check MUST correctly evaluate the check_host() function 628 as described here. 630 Implementations MAY use a different algorithm than the canonical 631 algorithm defined here, so long as the results are the same in all 632 cases. 634 4.1. Arguments 636 The check_host() function takes these arguments: 638 - the IP address of the SMTP client that is emitting the 639 mail, either IPv4 or IPv6. 641 - the domain that provides the sought-after authorization 642 information; initially, the domain portion of the "MAIL 643 FROM" or "HELO" identity. 645 - the "MAIL FROM" or "HELO" identity. 647 For recursive evaluations, the domain portion of might not 648 be the same as the argument when check_host() is initially 649 evaluated. In most other cases it will be the same. (See 650 Section 5.2 below). The overall DNS lookup limit for SPF terms 651 described below in Section 4.6.4 must be tracked as a single global 652 limit for all evaluations, not just for a single instance of a 653 recursive evaluation. 655 Note that the argument might not be a well-formed domain 656 name. For example, if the reverse-path was null, then the EHLO/HELO 657 domain is used, with its associated problems (see Section 2.3). In 658 these cases, check_host() is defined in Section 4.3 to return a 659 "none" result. 661 4.2. Results 663 The function check_host() can return one of several results described 664 in Section 2.6. Based on the result, the action to be taken is 665 determined by the local policies of the receiver. This is discussed 666 in Section 8. 668 4.3. Initial Processing 670 If the is malformed (e.g. label longer than 63 characters, 671 zero-length label not at the end, etc.) or is not a multi-label 672 domain name, or if the DNS lookup returns "domain does not exist" 673 (RCODE 3), check_host() immediately returns the result "none". DNS 674 RCODES are defined in [RFC1035]. Properly formed domains are fully 675 qualified domains as defined in [RFC1983]. That is, in the DNS they 676 are implicitly qualified relative to the root (see section 3.1 of 677 [RFC1034]). Internationalized domain names MUST be encoded as 678 A-labels, as described in Section 2.3 of [RFC5890]. 680 If the has no local-part, substitute the string "postmaster" 681 for the local-part. 683 4.4. Record Lookup 685 In accordance with how the records are published (see Section 3 686 above), a DNS query needs to be made for the name, querying 687 for type TXT only. 689 If the DNS lookup returns a server failure (RCODE 2), or other error 690 (RCODE other than 0 or 3), or time out, then check_host() terminates 691 immediately with the result "temperror". 693 4.5. Selecting Records 695 Records begin with a version section: 697 record = version terms *SP 698 version = "v=spf1" 700 Starting with the set of records that were returned by the lookup, 701 discard records that do not begin with a version section of exactly 702 "v=spf1". Note that the version section is terminated either by an 703 SP character or the end of the record. As an example, a record with 704 a version section of "v=spf10" does not match and is discarded. 706 If the resultant record set includes no records, check_host() 707 produces the "none" result. If the resultant record set includes 708 more than one record, check_host() produces the "permerror" result. 710 4.6. Record Evaluation 712 The check_host() function parses and interprets the SPF record to 713 find a result for the current test. If there are any syntax errors 714 anywhere in the record, check_host() returns immediately with the 715 result "permerror", without further interpretation. 717 4.6.1. Term Evaluation 719 There are two types of terms: mechanisms (defined in Section 5) and 720 modifiers (defined in Section 6). A record contains an ordered list 721 of these as specified in the following Augmented Backus-Naur Form 722 (ABNF). 724 terms = *( 1*SP ( directive / modifier ) ) 726 directive = [ qualifier ] mechanism 727 qualifier = "+" / "-" / "?" / "~" 728 mechanism = ( all / include 729 / a / mx / ptr / ip4 / ip6 / exists ) 730 modifier = redirect / explanation / unknown-modifier 731 unknown-modifier = name "=" macro-string 732 ; where name is not any known modifier 734 name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) 736 Most mechanisms allow a ":" or "/" character after the name. 738 Modifiers always contain an equals ('=') character immediately after 739 the name, and before any ":" or "/" characters that might be part of 740 the macro-string. 742 Terms that do not contain any of "=", ":", or "/" are mechanisms, as 743 defined in Section 5. 745 As per the definition of the ABNF notation in [RFC5234], mechanism 746 and modifier names are case-insensitive. 748 4.6.2. Mechanisms 750 Each mechanism is considered in turn from left to right. If there 751 are no more mechanisms, the result is the default result as described 752 in Section 4.7. 754 When a mechanism is evaluated, one of three things can happen: it can 755 match, not match, or return an exception. 757 If it matches, processing ends and the qualifier value is returned as 758 the result of that record. If it does not match, processing 759 continues with the next mechanism. If it returns an exception, 760 mechanism processing ends and the exception value is returned. 762 The possible qualifiers, and the results they cause check_host() to 763 return are as follows: 765 "+" pass 766 "-" fail 767 "~" softfail 768 "?" neutral 770 The qualifier is optional and defaults to "+". 772 When a mechanism matches and the qualifier is "-", then a "fail" 773 result is returned and the explanation string is computed as 774 described in Section 6.2. 776 The specific mechanisms are described in Section 5. 778 4.6.3. Modifiers 780 Modifiers are not mechanisms. They do not return match or not-match. 781 Instead, they provide additional information. Although modifiers do 782 not directly affect the evaluation of the record, the "redirect" 783 modifier has an effect after all the mechanisms have been evaluated. 785 4.6.4. DNS Lookup Limits 787 Some mechanisms and modifiers (collectively, "terms") cause DNS 788 queries at the time of evaluation, and some do not. The following 789 terms cause DNS queries: the "include", "a", "mx", "ptr", and 790 "exists" mechanisms and the "redirect" modifier. SPF implementations 791 MUST limit the total number of those terms to 10 during SPF 792 evaluation, to avoid unreasonable load on the DNS. If this limit is 793 exceeded, the implementation MUST return "permerror". The other 794 terms: the "all", "ip4", and "ip6" mechanisms and the "exp" modifier 795 do not cause DNS queries at the time of SPF evaluation (the "exp" 796 modifier only causes a lookup at a later time), and their use is not 797 subject to this limit. 799 When evaluating the "mx" mechanism, the number of "MX" resource 800 records queried is included in the overall limit of 10 mechanisms/ 801 modifiers that cause DNS lookups described above. In addition to 802 that limit, the evaluation of each "MX" record MUST NOT result in 803 querying more than 10 address records, either "A" or "AAAA" resource 804 records. If this limit is exceeded, the "mx" mechanism MUST produce 805 a "permerror" result. 807 When evaluating the "ptr" mechanism or the %{p} macro, the number of 808 "PTR" resource records queried is included in the overall limit of 10 809 mechanisms/modifiers that cause DNS lookups described above. In 810 addition to that limit, the evaluation of each "PTR" record MUST NOT 811 result in querying more than 10 address records, either "A" or "AAAA" 812 resource records. If this limit is exceeded, all records other than 813 the first 10 MUST be ignored. 815 The reason for the disparity is that the set of and contents of the 816 MX record are under control of the publishing ADMD, while the set of 817 and contents of PTR records are under control of the owner of the IP 818 address actually making the connection. 820 These limits are per mechanism or macro in the record, and are in 821 addition to the lookup limits specified above. 823 MTAs or other processors SHOULD impose a limit on the maximum amount 824 of elapsed time to evaluate check_host(). Such a limit SHOULD allow 825 at least 20 seconds. If such a limit is exceeded, the result of 826 authorization SHOULD be "temperror". 828 As described at the end of Section 11.1, there may be cases where it 829 is useful to limit the number of "terms" for which DNS queries return 830 either a positive answer (RCODE 0) with an answer count of 0, or a no 831 such record (RCODE 3) answer. These are sometimes collectively 832 referred to as "void lookups". SPF implementations SHOULD limit 833 "void lookups" to two. An implementation MAY choose to make such a 834 limit configurable. In this case, a default of two is RECOMMENDED. 836 4.7. Default Result 838 If none of the mechanisms match and there is no "redirect" modifier, 839 then the check_host() returns a result of "neutral", just as if 840 "?all" were specified as the last directive. If there is a 841 "redirect" modifier, check_host() proceeds as defined in Section 6.1. 843 It is better to use either a "redirect" modifier or an "all" 844 mechanism to explicitly terminate processing. Although there is an 845 implicit "?all" at the end of every record that is not explicitly 846 terminated, it aids debugging efforts when it is explicitly provided. 848 For example: 850 v=spf1 +mx -all 851 or 852 v=spf1 +mx redirect=_spf.example.com 854 4.8. Domain Specification 856 Several of these mechanisms and modifiers have a domain-spec section. 857 The domain-spec string is subject to macro expansion (see Section 7). 858 The resulting string is the common presentation form of a fully- 859 qualified DNS name: a series of labels separated by periods. This 860 domain is called the in the rest of this document. 862 Note: The result of the macro expansion is not subject to any further 863 escaping. Hence, this facility cannot produce all characters that 864 are legal in a DNS label (e.g., the control characters). However, 865 this facility is powerful enough to express legal host names and 866 common utility labels (such as "_spf") that are used in DNS. 868 For several mechanisms, the domain-spec is optional. If it is not 869 provided, the from the check_host() arguments (see 870 Section 4.1) is used as the . "domain" and domain-spec 871 are syntactically identical after macro expansion. "domain" is an 872 input value for check_host() while domain-spec is computed by 873 check_host(). 875 The result of evaluating check_host() with a syntactically invalid 876 domain is undefined. 878 5. Mechanism Definitions 880 This section defines two types of mechanisms: basic language 881 framework mechanisms and designated sender mechanisms. 883 Basic mechanisms contribute to the language framework. They do not 884 specify a particular type of authorization scheme. The basic 885 mechanisms are as follows: 887 all 888 include 890 Designated sender mechanisms are used to identify a set of 891 addresses as being permitted or not permitted to use the for 892 sending mail. The designated sender mechanisms are as follows: 894 a 895 mx 896 ptr (do not use) 897 ip4 898 ip6 899 exists 901 The following conventions apply to all mechanisms that perform a 902 comparison between and an IP address at any point: 904 If no CIDR prefix length is given in the directive, then and the 905 IP address are compared for equality. (Here, CIDR is Classless 906 Inter-Domain Routing, described in [RFC4632].) 908 If a CIDR prefix length is specified, then only the specified number 909 of high-order bits of and the IP address are compared for 910 equality. 912 When any mechanism fetches host addresses to compare with , when 913 is an IPv4, "A" records are fetched; when is an IPv6 914 address, "AAAA" records are fetched. SPF implementations on IPv6 915 servers need to handle both "AAAA" and "A" records, for clients on 916 IPv4 mapped IPv6 addresses [RFC4291]. IPv4 addresses are only 917 listed in an SPF record using the "ip4" mechanism. 919 Several mechanisms rely on information fetched from the DNS. For 920 these DNS queries, except where noted, if the DNS server returns an 921 error (RCODE other than 0 or 3) or the query times out, the mechanism 922 stops and the topmost check_host() returns "temperror". If the 923 server returns "domain does not exist" (RCODE 3), then evaluation of 924 the mechanism continues as if the server returned no error (RCODE 0) 925 and zero answer records. 927 5.1. "all" 929 all = "all" 931 The "all" mechanism is a test that always matches. It is used as the 932 rightmost mechanism in a record to provide an explicit default. 934 For example: 936 v=spf1 a mx -all 938 Mechanisms after "all" will never be tested. Mechanisms listed after 939 "all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST be 940 ignored when there is an "all" mechanism in the record regardless of 941 the relative ordering of the terms. 943 5.2. "include" 945 include = "include" ":" domain-spec 947 The "include" mechanism triggers a recursive evaluation of 948 check_host(). 950 1. The domain-spec is expanded as per Section 7. 952 2. check_host() is evaluated with the resulting string as the 953 . The and arguments remain the same as in 954 the current evaluation of check_host(). 956 3. The recursive evaluation returns match, not match, or an error. 958 4. If it returns match, then the appropriate result for the include: 959 mechanism is used (e.g. include or +include produces a "pass" 960 result and -include produces "fail"). 962 5. If it returns no match or an error, the parent check_host() 963 resumes processing as per the table below, with the previous 964 value of restored. 966 In hindsight, the name "include" was poorly chosen. Only the 967 evaluated result of the referenced SPF record is used, rather than 968 literally including the mechanisms of the referenced record in the 969 first. For example, evaluating a "-all" directive in the referenced 970 record does not terminate the overall processing and does not 971 necessarily result in an overall "fail". (Better names for this 972 mechanism would have been "if-match", "on-match", etc.) 974 The "include" mechanism makes it possible for one domain to designate 975 multiple administratively-independent domains. For example, a vanity 976 domain "example.net" might send mail using the servers of 977 administratively-independent domains example.com and example.org. 979 Example.net could say 981 IN TXT "v=spf1 include:example.com include:example.org -all" 983 This would direct check_host() to, in effect, check the records of 984 example.com and example.org for a "pass" result. Only if the host 985 were not permitted for either of those domains would the result be 986 "fail". 988 Whether this mechanism matches, does not match, or returns an 989 exception depends on the result of the recursive evaluation of 990 check_host(): 992 +---------------------------------+---------------------------------+ 993 | A recursive check_host() result | Causes the "include" mechanism | 994 | of: | to: | 995 +---------------------------------+---------------------------------+ 996 | pass | match | 997 | | | 998 | fail | not match | 999 | | | 1000 | softfail | not match | 1001 | | | 1002 | neutral | not match | 1003 | | | 1004 | temperror | return temperror | 1005 | | | 1006 | permerror | return permerror | 1007 | | | 1008 | none | return permerror | 1009 +---------------------------------+---------------------------------+ 1011 The "include" mechanism is intended for crossing administrative 1012 boundaries. When remaining within one administrative authority, 1013 "include" is usually not the best choice. For example, if 1014 example.com and example.org were managed by the same entity, and if 1015 the permitted set of hosts for both domains was "mx:example.com", it 1016 would be possible for example.org to specify "include:example.com", 1017 but it would be preferable to specify "redirect=example.com" or even 1018 "mx:example.com". 1020 With the "include" mechanism an administratively external set of 1021 hosts can be authorized, but determination of sender policy is still 1022 a function of the original domain's SPF record (as determined by the 1023 "all" mechanism in that record). The redirect modifier is more 1024 suitable for consolidating both authorizations and policy into a 1025 common set to be shared within an ADMD. Redirect is much more like a 1026 common code element to be shared among records in a single ADMD. It 1027 is possible to control both authorized hosts and policy for an 1028 arbitrary number of domains from a single record. 1030 5.3. "a" 1032 This mechanism matches if is one of the 's IP 1033 addresses. For clarity, this means the "a" mechanism also matches 1034 AAAA records. 1036 a = "a" [ ":" domain-spec ] [ dual-cidr-length ] 1038 An address lookup is done on the using the type of 1039 lookup (A or AAAA) appropriate for the connection type (IPv4 or 1040 IPv6). The is compared to the returned address(es). If any 1041 address matches, the mechanism matches. 1043 5.4. "mx" 1045 This mechanism matches if is one of the MX hosts for a domain 1046 name. 1048 mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ] 1050 check_host() first performs an MX lookup on the . Then 1051 it performs an address lookup on each MX name returned. The is 1052 compared to each returned IP address. To prevent Denial of Service 1053 (DoS) attacks, the processing limits defined in Section 4.6.4 MUST be 1054 followed. If the MX lookup limit is exceeded, then "permerror" is 1055 returned and the evaluation is terminated. If any address matches, 1056 the mechanism matches. 1058 Note regarding implicit MXes: If the has no MX record, 1059 check_host() MUST NOT apply the implicit MX rules of[RFC5321] by 1060 querying for an A or AAAA record for the same name. 1062 5.5. "ptr" (do not use) 1064 This mechanism tests whether the DNS reverse-mapping for exists 1065 and correctly points to a domain name within a particular domain. 1066 This mechanism SHOULD NOT be published. See the note at the end of 1067 this section for more information. 1069 ptr = "ptr" [ ":" domain-spec ] 1070 The 's name is looked up using this procedure: 1072 o Perform a DNS reverse-mapping for : Look up the corresponding 1073 PTR record in "in-addr.arpa." if the address is an IPv4 one and in 1074 "ip6.arpa." if it is an IPv6 address. 1076 o For each record returned, validate the domain name by looking up 1077 its IP addresses. To prevent DoS attacks, the PTR processing 1078 limits defined in Section 4.6.4 MUST be applied. If they are 1079 exceeded, processing is terminated and the mechanism does not 1080 match. 1082 o If is among the returned IP addresses, then that domain name 1083 is validated. 1085 Check all validated domain names to see if they either match the 1086 domain or are a subdomain of the domain. 1087 If any do, this mechanism matches. If no validated domain name can 1088 be found, or if none of the validated domain names match or are a 1089 subdomain of the , this mechanism fails to match. If a 1090 DNS error occurs while doing the PTR RR lookup, then this mechanism 1091 fails to match. If a DNS error occurs while doing an A RR lookup, 1092 then that domain name is skipped and the search continues. 1094 Pseudocode: 1096 sending-domain_names := ptr_lookup(sending-host_IP); 1097 if more than 10 sending-domain_names are found, use at most 10. 1098 for each name in (sending-domain_names) { 1099 IP_addresses := a_lookup(name); 1100 if the sending-domain_IP is one of the IP_addresses { 1101 validated-sending-domain_names += name; 1102 } 1103 } 1105 for each name in (validated-sending-domain_names) { 1106 if name ends in , return match. 1107 if name is , return match. 1108 } 1109 return no-match. 1111 This mechanism matches if the is either a subdomain of 1112 a validated domain name or if the and a validated 1113 domain name are the same. For example: "mail.example.com" is within 1114 the domain "example.com", but "mail.bad-example.com" is not. 1116 Note: This mechanism is slow, it is not as reliable as other 1117 mechanisms in cases of DNS errors, and it places a large burden on 1118 the .arpa name servers. If used, proper PTR records have to be in 1119 place for the domain's hosts and the "ptr" mechanism SHOULD be one of 1120 the last mechanisms checked. After many years of SPF deployment 1121 experience, it has been concluded it is unnecessary and more reliable 1122 alternatives should be used instead. It is, however, still in use as 1123 part of the SPF protocol, so compliant check_host() implementations 1124 MUST support it. 1126 5.6. "ip4" and "ip6" 1128 These mechanisms test whether is contained within a given IP 1129 network. 1131 ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ] 1132 ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ] 1134 ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32 1135 ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128 1136 dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] 1138 ip4-network = qnum "." qnum "." qnum "." qnum 1139 qnum = DIGIT ; 0-9 1140 / %x31-39 DIGIT ; 10-99 1141 / "1" 2DIGIT ; 100-199 1142 / "2" %x30-34 DIGIT ; 200-249 1143 / "25" %x30-35 ; 250-255 1144 ; as per conventional dotted quad notation. e.g., 192.0.2.0 1145 ip6-network = 1146 ; e.g., 2001:DB8::CD30 1148 The is compared to the given network. If CIDR prefix length 1149 high-order bits match, the mechanism matches. 1151 If ip4-cidr-length is omitted, it is taken to be "/32". If 1152 ip6-cidr-length is omitted, it is taken to be "/128". It is not 1153 permitted to omit parts of the IP address instead of using CIDR 1154 notations. That is, use 192.0.2.0/24 instead of 192.0.2. 1156 5.7. "exists" 1158 This mechanism is used to construct an arbitrary domain name that is 1159 used for a DNS A record query. It allows for complicated schemes 1160 involving arbitrary parts of the mail envelope to determine what is 1161 permitted. 1163 exists = "exists" ":" domain-spec 1165 The domain-spec is expanded as per Section 7. The resulting domain 1166 name is used for a DNS A RR lookup (even when the connection type is 1167 IPv6). If any A record is returned, this mechanism matches. 1169 Domains can use this mechanism to specify arbitrarily complex 1170 queries. For example, suppose example.com publishes the record: 1172 v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all 1174 The might expand to 1175 "1.2.0.192.someuser._spf.example.com". This makes fine-grained 1176 decisions possible at the level of the user and client IP address. 1178 6. Modifier Definitions 1180 Modifiers are name/value pairs that provide additional information. 1181 Modifiers always have an "=" separating the name and the value. 1183 The modifiers defined in this document ("redirect" and "exp") SHOULD 1184 appear at the end of the record, after all mechanisms, though 1185 syntactically they can appear anywhere in the record. Ordering of 1186 these two modifiers does not matter. These two modifiers MUST NOT 1187 appear in a record more than once each. If they do, then 1188 check_host() exits with a result of "permerror". 1190 Unrecognized modifiers MUST be ignored no matter where in a record, 1191 they appear or how often. This allows implementations of this 1192 document to gracefully handle records with modifiers that are defined 1193 in other specifications. 1195 6.1. redirect: Redirected Query 1197 The redirect modifier is intended for consolidating both 1198 authorizations and policy into a common set to be shared within a 1199 single ADMD. It is possible to control both authorized hosts and 1200 policy for an arbitrary number of domains from a single record. 1202 redirect = "redirect" "=" domain-spec 1204 If all mechanisms fail to match, and a "redirect" modifier is 1205 present, then processing proceeds as follows: 1207 The domain-spec portion of the redirect section is expanded as per 1208 the macro rules in Section 7. Then check_host() is evaluated with 1209 the resulting string as the . The and 1210 arguments remain the same as in the current evaluation of 1211 check_host(). 1213 The result of this new evaluation of check_host() is then considered 1214 the result of the current evaluation with the exception that if no 1215 SPF record is found, or if the is malformed, the result 1216 is a "permerror" rather than "none". 1218 Note that the newly-queried domain can itself specify redirect 1219 processing. 1221 This facility is intended for use by organizations that wish to apply 1222 the same record to multiple domains. For example: 1224 la.example.com. TXT "v=spf1 redirect=_spf.example.com" 1225 ny.example.com. TXT "v=spf1 redirect=_spf.example.com" 1226 sf.example.com. TXT "v=spf1 redirect=_spf.example.com" 1227 _spf.example.com. TXT "v=spf1 mx:example.com -all" 1229 In this example, mail from any of the three domains is described by 1230 the same record. This can be an administrative advantage. 1232 Note: In general, the domain "A" cannot reliably use a redirect to 1233 another domain "B" not under the same administrative control. Since 1234 the stays the same, there is no guarantee that the record at 1235 domain "B" will correctly work for mailboxes in domain "A", 1236 especially if domain "B" uses mechanisms involving local-parts. An 1237 "include" directive will generally be more appropriate. 1239 For clarity, any "redirect" modifier SHOULD appear as the very last 1240 term in a record. Any "redirect" modifier MUST be ignored if there 1241 is an "all" mechanism anywhere in the record. 1243 6.2. exp: Explanation 1245 explanation = "exp" "=" domain-spec 1247 If check_host() results in a "fail" due to a mechanism match (such as 1248 "-all"), and the "exp" modifier is present, then the explanation 1249 string returned is computed as described below. If no "exp" modifier 1250 is present, then either a default explanation string or an empty 1251 explanation string MUST be returned to the calling application. 1253 The domain-spec is macro expanded (see Section 7) and becomes the 1254 . The DNS TXT RRset for the is fetched. 1256 If there are any DNS processing errors (any RCODE other than 0), or 1257 if no records are returned, or if more than one record is returned, 1258 or if there are syntax errors in the explanation string, then proceed 1259 as if no "exp" modifier was given. 1261 The fetched TXT record's strings are concatenated with no spaces, and 1262 then treated as an explain-string, which is macro-expanded. This 1263 final result is the explanation string. Implementations MAY limit 1264 the length of the resulting explanation string to allow for other 1265 protocol constraints and/or reasonable processing limits. Since the 1266 explanation string is intended for an SMTP response and [RFC5321] 1267 Section 2.4 says that responses are in [US-ASCII], the explanation 1268 string MUST be limited to [US-ASCII]. 1270 Software evaluating check_host() can use this string to communicate 1271 information from the publishing domain in the form of a short message 1272 or URL. Software SHOULD make it clear that the explanation string 1273 comes from a third party. For example, it can prepend the macro 1274 string "%{o} explains: " to the explanation, such as shown in 1275 Section 8.4. 1277 Suppose example.com has this record: 1279 v=spf1 mx -all exp=explain._spf.%{d} 1281 Here are some examples of possible explanation TXT records at 1282 explain._spf.example.com: 1284 "Mail from example.com should only be sent by its own servers." 1285 -- a simple, constant message 1287 "%{i} is not one of %{d}'s designated mail servers." 1288 -- a message with a little more information, including the IP 1289 address that failed the check 1291 "See http://%{d}/why.html?s=%{S}&i=%{I}" 1292 -- a complicated example that constructs a URL with the 1293 arguments to check_host() so that a web page can be 1294 generated with detailed, custom instructions 1296 Note: During recursion into an "include" mechanism, an "exp" modifier 1297 from the MUST NOT be used. In contrast, when executing 1298 a "redirect" modifier, an "exp" modifier from the original domain 1299 MUST NOT be used. This is because "include" is meant to cross 1300 administrative boundaries and the explanation provided should be the 1301 one from the receiving ADMD, while "redirect" is meant to operate as 1302 a tool to consolidate policy records within an ADMD an so the 1303 redirected explanation is the one that ought to have priority. 1305 7. Macros 1307 When evaluating an SPF policy record, certain character sequences are 1308 intended to be replaced by parameters of the message or of the 1309 connection. These character sequences are referred to as "macros". 1311 7.1. Formal Specification 1313 The ABNF description for a macro is as follows: 1315 domain-spec = macro-string domain-end 1316 domain-end = ( "." toplabel [ "." ] ) / macro-expand 1318 toplabel = ( *alphanum ALPHA *alphanum ) / 1319 ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) 1320 alphanum = ALPHA / DIGIT 1322 explain-string = *( macro-string / SP ) 1324 macro-string = *( macro-expand / macro-literal ) 1325 macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) 1326 / "%%" / "%_" / "%-" 1327 macro-literal = %x21-24 / %x26-7E 1328 ; visible characters except "%" 1329 macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / 1330 "c" / "r" / "t" / "v" 1331 transformers = *DIGIT [ "r" ] 1332 delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" 1334 The "toplabel" construction is subject to the LDH rule plus 1335 additional top-level domain (TLD) restrictions. See Section 2 of 1336 [RFC3696] for background. 1338 Some special cases: 1340 o A literal "%" is expressed by "%%". 1342 o "%_" expands to a single " " space. 1344 o "%-" expands to a URL-encoded space, viz., "%20". 1346 7.2. Macro Definitions 1348 The following macro letters are expanded in term arguments: 1350 s = 1351 l = local-part of 1352 o = domain of 1353 d = 1354 i = 1355 p = the validated domain name of (do not use) 1356 v = the string "in-addr" if is ipv4, or "ip6" if is ipv6 1357 h = HELO/EHLO domain 1359 , , and are defined in Section 2.2. 1361 The following macro letters are allowed only in "exp" text: 1363 c = SMTP client IP (easily readable format) 1364 r = domain name of host performing the check 1365 t = current timestamp 1367 7.3. Macro Processing Details 1369 A '%' character not followed by a '{', '%', '-', or '_' character is 1370 a syntax error. So: 1372 -exists:%(ir).sbl.example.org 1374 is incorrect and will cause check_host() to yield a "permerror". 1375 Instead, the following is legal: 1377 -exists:%{ir}.sbl.example.org 1379 Optional transformers are the following: 1381 *DIGIT = zero or more digits 1382 'r' = reverse value, splitting on dots by default 1384 If transformers or delimiters are provided, the replacement value for 1385 a macro letter is split into parts separated by one or more of the 1386 specified delimiter characters. After performing any reversal 1387 operation and/or removal of left-hand parts, the parts are rejoined 1388 using "." and not the original splitting characters. 1390 By default, strings are split on "." (dots). Note that no special 1391 treatment is given to leading, trailing, or consecutive delimiters in 1392 input strings, and so the list of parts might contain empty strings. 1393 Some older implementations of SPF prohibit trailing dots in domain 1394 names, so trailing dots SHOULD NOT be published, although they MUST 1395 be accepted by implementations conforming to this document. Macros 1396 can specify delimiter characters that are used instead of ".". 1398 The "r" transformer indicates a reversal operation: if the client IP 1399 address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1" 1400 and the macro %{ir} would expand to "1.2.0.192". 1402 The DIGIT transformer indicates the number of right-hand parts to 1403 use, after optional reversal. If a DIGIT is specified, the value 1404 MUST be nonzero. If no DIGITs are specified, or if the value 1405 specifies more parts than are available, all the available parts are 1406 used. If the DIGIT was 5, and only 3 parts were available, the macro 1407 interpreter would pretend the DIGIT was 3. Implementations MUST 1408 support at least a value of 127, as that is the maximum number of 1409 labels in a domain name (less the zero-length label at the end). 1411 The "s" macro expands to the argument. It is an email 1412 address with a local-part, an "@" character, and a domain. The "l" 1413 macro expands to just the local-part. The "o" macro expands to just 1414 the domain part. Note that these values remain the same during 1415 recursive and chained evaluations due to "include" and/or "redirect". 1416 Note also that if the original had no local-part, the local- 1417 part was set to "postmaster" in initial processing (see Section 4.3). 1419 For IPv4 addresses, both the "i" and "c" macros expand to the 1420 standard dotted-quad format. 1422 For IPv6 addresses, the "i" macro expands to a dot-format address; it 1423 is intended for use in %{ir}. The "c" macro can expand to any of the 1424 hexadecimal colon-format addresses specified in [RFC4291], Section 1425 2.2. It is intended for humans to read. 1427 The "p" macro expands to the validated domain name of . The 1428 procedure for finding the validated domain name is defined in 1429 Section 5.5. If the is present in the list of validated 1430 domains, it SHOULD be used. Otherwise, if a subdomain of the 1431 is present, it SHOULD be used. Otherwise, any name from the 1432 list can be used. If there are no validated domain names or if a DNS 1433 error occurs, the string "unknown" is used. 1435 This macro SHOULD NOT be published (see Section 5.5 for the 1436 discussion). 1438 The "h" macro expands to the parameter that was provided to the SMTP 1439 server via the HELO or EHLO SMTP verb. For sessions where that verb 1440 was provided more than once, the most recent instance is used. 1442 The "r" macro expands to the name of the receiving MTA. This SHOULD 1443 be a fully qualified domain name, but if one does not exist (as when 1444 the checking is done by a MUA) or if policy restrictions dictate 1445 otherwise, the word "unknown" SHOULD be substituted. The domain name 1446 can be different from the name found in the MX record that the client 1447 MTA used to locate the receiving MTA. 1449 The "t" macro expands to the decimal representation of the 1450 approximate number of seconds since the Epoch (Midnight, January 1, 1451 1970, UTC) at the time of the evaluation. This is the same value as 1452 is returned by the POSIX time() function in most standards-compliant 1453 libraries. 1455 When the result of macro expansion is used in a domain name query, if 1456 the expanded domain name exceeds 253 characters (the maximum length 1457 of a domain name in this format), the left side is truncated to fit, 1458 by removing successive domain labels (and their following dots) until 1459 the total length does not exceed 253 characters. 1461 Uppercase macros expand exactly as their lowercase equivalents, and 1462 are then URL escaped. URL escaping MUST be performed for characters 1463 not in the "unreserved" set, which is defined in [RFC3986]. 1465 Care has to be taken by the sending ADMD so that macro expansion for 1466 legitimate email does not exceed the 63-character limit on DNS 1467 labels. The local-part of email addresses, in particular, can have 1468 more than 63 characters between dots. 1470 To minimize DNS lookup resource requirements, it is better if sending 1471 ADMDs avoid using the "s", "l", "o", or "h" macros in conjunction 1472 with any mechanism directive. Although these macros are powerful and 1473 allow per-user records to be published, they severely limit the 1474 ability of implementations to cache results of check_host() and they 1475 reduce the effectiveness of DNS caches. 1477 If no directive processed during the evaluation of check_host() 1478 contains an "s", "l", "o", or "h" macro, then the results of the 1479 evaluation can be cached on the basis of and alone for 1480 as long as the DNS record involved with the shortest TTL has not 1481 expired. 1483 7.4. Expansion Examples 1485 The is strong-bad@email.example.com. 1486 The IPv4 SMTP client IP is 192.0.2.3. 1487 The IPv6 SMTP client IP is 2001:DB8::CB01. 1488 The PTR domain name of the client IP is mx.example.org. 1490 macro expansion 1491 ------- ---------------------------- 1492 %{s} strong-bad@email.example.com 1493 %{o} email.example.com 1494 %{d} email.example.com 1495 %{d4} email.example.com 1496 %{d3} email.example.com 1497 %{d2} example.com 1498 %{d1} com 1499 %{dr} com.example.email 1500 %{d2r} example.email 1501 %{l} strong-bad 1502 %{l-} strong.bad 1503 %{lr} strong-bad 1504 %{lr-} bad.strong 1505 %{l1r-} strong 1507 macro-string expansion 1508 -------------------------------------------------------------------- 1509 %{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com 1510 %{lr-}.lp._spf.%{d2} bad.strong.lp._spf.example.com 1512 %{lr-}.lp.%{ir}.%{v}._spf.%{d2} 1513 bad.strong.lp.3.2.0.192.in-addr._spf.example.com 1515 %{ir}.%{v}.%{l1r-}.lp._spf.%{d2} 1516 3.2.0.192.in-addr.strong.lp._spf.example.com 1518 %{d2}.trusted-domains.example.net 1519 example.com.trusted-domains.example.net 1521 IPv6: 1522 %{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0. 1523 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 1525 8. Result Handling 1527 This section provides guidance for SPF verifier operators in response 1528 to the various possible outputs of check_host() on a message. 1529 Definitions of SPF results are presented in Section 2.6; this section 1530 provides more detail on each for use in developing local policy for 1531 message handling. 1533 Every operating environment is different. There are some receivers 1534 for whom strict adherence to SPF is appropriate, and definitive 1535 treatment of messages that are evaluated to be explicitly 1536 unauthorized ("fail" and sometimes "softfail") is the norm. There 1537 are others for which the "false negative" cases are more of a 1538 concern. This concern is typically handled by merely recording the 1539 result in the header and allowing the message to pass on for 1540 additional processing. There are still others where SPF is one of 1541 several inputs to the message handling decision. As such, there is 1542 no comprehensive normative requirement for message handling in 1543 response to any particular result. This section is provided to 1544 present a complete picture of the likely cause of each result and, 1545 where available, the experience gained during experimental 1546 deployment. 1548 There are essentially two classes of handling choices: 1550 o Handling within the SMTP session that attempted to deliver the 1551 message, such as by returning a permanent SMTP error (rejection) 1552 or temporary SMTP error ("try again later"); 1554 o Permitting the message to pass (a successful SMTP reply code) and 1555 adding an additional header field that indicates the result 1556 returned by check_host() and other salient details; this is 1557 discussed in more detail in Section 9. 1559 8.1. None 1561 With a "none" result, the SPF verifier has no information at all 1562 about the authorization or lack thereof of the client to use the 1563 checked identity or identities. The check_host() function completed 1564 without errors but was not able to reach any conclusion. 1566 8.2. Neutral 1568 A "neutral" result indicates that although a policy for the identity 1569 was discovered, there is no definite assertion (positive or negative) 1570 about the client. 1572 A "neutral" result MUST be treated exactly like the "none" result; 1573 the distinction exists only for informational purposes. Treating 1574 "neutral" more harshly than "none" would discourage ADMDs from 1575 testing the use of SPF records (see Section 10.1). 1577 8.3. Pass 1579 A "pass" result means that the client is authorized to inject mail 1580 with the given identity. The domain can now, in the sense of 1581 reputation, be considered responsible for sending the message. 1582 Further policy checks can now proceed with confidence in the 1583 legitimate use of the identity. This is further discussed in 1584 Appendix G.1. 1586 8.4. Fail 1588 A "fail" result is an explicit statement that the client is not 1589 authorized to use the domain in the given identity. Disposition of 1590 SPF fail messages is a matter of local policy. See Appendix G.2 for 1591 considerations on developing local policy. 1593 If the checking software chooses to reject the mail during the SMTP 1594 transaction, then it SHOULD use an SMTP reply code of 550 (see 1595 [RFC5321]) and, if supported, the 5.7.1 enhanced status code (see 1596 [RFC3463], Section 3.8), in addition to an appropriate reply text. 1597 The check_host() function will return either a default explanation 1598 string or one from the domain that published the SPF records (see 1599 Section 6.2). If the information does not originate with the 1600 checking software, it is good to make it clear that the text is 1601 provided by the sender's domain. For example: 1603 550-5.7.1 SPF MAIL FROM check failed: 1604 550-5.7.1 The domain example.com explains: 1605 550 5.7.1 Please see http://www.example.com/mailpolicy.html 1607 If the checking software chooses not to reject the mail during the 1608 SMTP transaction, then it SHOULD add a Received-SPF or 1609 Authentication-Results header field (see Section 9) to communicate 1610 this result to downstream message processors. While this is true for 1611 all SPF results, it is of particular importance for "fail" results 1612 since the message is explicitly not authorized by the ADMD. 1614 8.5. Softfail 1616 A "softfail" result ought to be treated as somewhere between "fail" 1617 and "neutral"/"none". The ADMD believes the host is not authorized 1618 but is not willing to make a strong policy statement. Receiving 1619 software SHOULD NOT reject the message based solely on this result, 1620 but MAY subject the message to closer scrutiny than normal. 1622 The ADMD wants to discourage the use of this host and thus desires 1623 limited feedback when a "softfail" result occurs. For example, the 1624 recipient's Mail User Agent (MUA) could highlight the "softfail" 1625 status, or the receiving MTA could give the sender a message using 1626 greylisting, [RFC6647], with a note the first time the message is 1627 received, but accept it on a later attempt based on receiver policy. 1629 8.6. Temperror 1631 A "temperror" result means the SPF verifier encountered a transient 1632 (generally DNS) error while performing the check. Checking software 1633 can choose to accept or temporarily reject the message. If the 1634 message is rejected during the SMTP transaction for this reason, the 1635 software SHOULD use an SMTP reply code of 451 and, if supported, the 1636 4.4.3 enhanced status code (see [RFC3463], Section 3.5). These 1637 errors can be caused by problems in either the sender's or receiver's 1638 DNS software. See Appendix G.4 for considerations on developing 1639 local policy. 1641 8.7. Permerror 1643 A "permerror" result means the domain's published records could not 1644 be correctly interpreted. This signals an error condition that 1645 definitely requires DNS operator intervention to be resolved. If the 1646 message is rejected during the SMTP transaction for this reason, the 1647 software SHOULD use an SMTP reply code of 550 and, if supported, the 1648 5.5.2 enhanced status code (see [RFC3463], Section 3.6). Be aware 1649 that if the ADMD uses macros (Section 7), it is possible that this 1650 result is due to the checked identities having an unexpected format. 1651 It is also possible that this result is generated by certain SPF 1652 verifiers due to the input arguments having an unexpected format; see 1653 Section 4.8. See Appendix G.3 for considerations on developing local 1654 policy. 1656 9. Recording the Result 1658 To provide downstream agents, such as MUAs, with the information they 1659 might need in terms of evaluating or representing the apparent safety 1660 of the message content, it is RECOMMENDED that SMTP receivers record 1661 the result of SPF processing in the message header. For SPF verifier 1662 operators that choose to record SPF results in the header of the 1663 message for processing by internal filters or MUAs, two methods are 1664 presented. Section 9.1 defines the Received-SPF field, which is the 1665 results field originally defined for SPF use. Section 9.2 discusses 1666 Authentication-Results [RFC5451] which was specified more recently 1667 and is designed for use by SPF and other authentication methods. 1669 Both are in common use, and hence both are included here. However, 1670 it is important to note that they were designed to serve slightly 1671 different purposes. Received-SPF is intended to include enough 1672 information to enable reconstruction of the SPF evaluation of the 1673 message, while Authentication-Results is designed only to relay the 1674 result itself and related output details of likely use to end users 1675 (e.g., what property of the message was actually authenticated and 1676 what it contained), leaving reconstructive work to the purview of 1677 system logs and the Received field contents. Also, Received-SPF 1678 relies on compliance of agents within the receiving ADMD to adhere to 1679 the header field ordering rules of [RFC5321] and [RFC5322], while 1680 Authentication-Results includes some provisions to protect against 1681 non-compliant implementations. 1683 An SPF verifier operator could choose to use both to serve different 1684 downstream agents. In such cases, care needs to be taken to ensure 1685 both fields are conveying the same details, or unexpected results can 1686 occur. 1688 9.1. The Received-SPF Header Field 1690 The Received-SPF header field is a trace field (see [RFC5322] Section 1691 3.6.7) and SHOULD be prepended to the existing header, above the 1692 Received: field that is generated by the SMTP receiver. It MUST 1693 appear above all other Received-SPF fields in the message. The 1694 header field has the following format: 1696 header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] 1697 [ key-value-list ] CRLF 1699 result = "pass" / "fail" / "softfail" / "neutral" / 1700 "none" / "temperror" / "permerror" 1702 key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) 1703 [";"] 1705 key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) 1707 key = "client-ip" / "envelope-from" / "helo" / 1708 "problem" / "receiver" / "identity" / 1709 "mechanism" / name 1711 identity = "mailfrom" ; for the "MAIL FROM" identity 1712 / "helo" ; for the "HELO" identity 1713 / name ; other identities 1715 dot-atom = 1716 quoted-string = 1717 comment = 1718 CFWS = 1719 FWS = 1720 CRLF = 1722 The header field SHOULD include a "(...)" style comment after the 1723 result, conveying supporting information for the result, such as 1724 , , and . 1726 The following key-value pairs are designed for later machine parsing. 1727 SPF verifiers SHOULD give enough information so that the SPF results 1728 can be verified. That is, at least "client-ip", "helo", and, if the 1729 "MAIL FROM" identity was checked, "envelope-from". 1731 client-ip the IP address of the SMTP client 1733 envelope-from the envelope sender mailbox 1735 helo the host name given in the HELO or EHLO command 1737 mechanism the mechanism that matched (if no mechanisms matched, 1738 substitute the word "default") 1740 problem if an error was returned, details about the error 1741 receiver the host name of the SPF verifier 1743 identity the identity that was checked; see the ABNF 1744 rule 1746 Other keys MAY be defined by SPF verifiers. 1748 SPF verifiers MUST make sure that the Received-SPF header field does 1749 not contain invalid characters, is not excessively long (See 1750 [RFC5322] Section 2.1.1), and does not contain malicious data that 1751 has been provided by the sender. 1753 Examples of various header field styles that could be generated are 1754 the following: 1756 Received-SPF: pass (mybox.example.org: domain of 1757 myname@example.com designates 192.0.2.1 as permitted sender) 1758 receiver=mybox.example.org; client-ip=192.0.2.1; 1759 envelope-from="myname@example.com"; helo=foo.example.com; 1761 Received-SPF: fail (mybox.example.org: domain of 1762 myname@example.com does not designate 1763 192.0.2.1 as permitted sender) 1764 identity=mailfrom; client-ip=192.0.2.1; 1765 envelope-from="myname@example.com"; 1767 Received-SPF: pass (mybox.example.org: domain of 1768 myname@example.com designates 192.0.2.1 as permitted sender) 1769 receiver=mybox.example.org; client-ip=192.0.2.1; 1770 mechanism=ip4:192.0.2.1; envelope-from="myname@example.com"; 1771 helo=foo.example.com; 1773 9.2. SPF Results in the Authentication-Results Header Field 1775 As mentioned in Section 9, the Authentication-Results header field is 1776 designed to communicate lists of tests a border MTA did and their 1777 results. The specified elements of the field provide less 1778 information than the Received-SPF field: 1780 Authentication-Results: myhost.example.org; spf=pass 1781 smtp.mailfrom=example.net 1783 Received-SPF: pass (myhost.example.org: domain of 1784 myname@example.com designates 192.0.2.1 as permitted sender) 1785 receiver=mybox.example.org; client-ip=192.0.2.1; 1786 envelope-from="myname@example.com"; helo=foo.example.com; 1788 It is, however, possible to add CFWS in the "reason" part of an 1789 Authentication-Results header field and provide the equivalent 1790 information, if desired. 1792 As an example, an expanded Authentication-Results header field might 1793 look like (for a "MAIL FROM" check in this example): 1795 Authentication-Results: myhost.example.org; spf=pass 1796 reason="client-ip=192.0.2.1; smtp.helo=foo.example.com" 1797 smtp.mailfrom=user@example.net 1799 10. Effects on Infrastructure 1801 This section outlines the major implications that adoption of this 1802 protocol will have on various entities involved in Internet email. 1803 It is intended to make clear to the reader where this protocol 1804 knowingly affects the operation of such entities. This section is 1805 not a "how-to" manual, or a "best practices" document, and it is not 1806 a comprehensive list of what such entities ought do in light of this 1807 specification. 1809 This section provides operational advice and instruction only. It is 1810 non-normative. 1812 [RFC5598] describes the Internet email architecture. This section is 1813 organized based on the different segments of the architecture. 1815 10.1. Sending Domains 1817 Originating ADMDs (ADministrative Management Domains - [RFC5598] 1818 Section 2.2.1 and Section 2.3) that wish to be compliant with this 1819 specification will need to determine the list of relays ([RFC5598] 1820 Section 2.2.2) that they allow to use their domain name in the "HELO" 1821 and "MAIL FROM" identities when relaying to other ADMDs. It is 1822 recognized that forming such a list is not just a simple technical 1823 exercise, but involves policy decisions with both technical and 1824 administrative considerations. 1826 10.1.1. DNS Resource Considerations 1828 Minimizing the DNS resources needed for SPF lookups can be done by 1829 choosing directives that require less DNS information and by placing 1830 lower-cost mechanisms earlier in the SPF record. 1832 Section 4.6.4 specifies the limits receivers have to use. It is 1833 essential to publish records that do not exceed these requirements. 1834 It is also required to carefully weigh the cost and the 1835 maintainability of licit solutions. 1837 For example, consider a domain set up as follows: 1839 example.com. IN MX 10 mx.example.com. 1840 IN MX 20 mx2.example.com. 1841 mx.example.com. IN A 192.0.2.1 1842 mx2.example.com. IN A 192.0.2.129 1844 Assume the administrative point is to authorize (pass) mx and mx2 1845 while failing every other host. Compare the following solutions: 1847 Best record: 1848 example.com. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.129 -all" 1850 Good record: 1851 $ORIGIN example.com. 1852 @ IN TXT "v=spf1 a:authorized-spf.example.com -all" 1853 authorized-spf IN A 192.0.2.1 1854 IN A 192.0.2.129 1856 Expensive record: 1857 example.com. IN TXT "v=spf1 mx:example.com -all" 1859 Wasteful, bad record: 1860 example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 mx -all" 1862 10.1.2. Administrator's Considerations 1864 There might be administrative considerations: using "a" over "ip4" or 1865 "ip6" allows hosts to be renumbered easily at the cost of a DNS query 1866 per receiver. Using "mx" over "a" allows the set of mail hosts to be 1867 changed easily. Unless such changes are common, it is better to use 1868 the less resource intensive mechanisms like "ip4" and "ip6" over "a" 1869 or "a" over "mx". 1871 In some specific cases, standard advice on record content is 1872 appropriate. Publishing SPF records for domains that send no mail is 1873 a well established best practice. The record for a domain that sends 1874 no mail is: 1876 www.example.com. IN TXT "v=spf1 -all" 1878 Publishing SPF records for individual hosts is also best practice. 1879 The hostname is generally the identity used in the 5321.HELO/.EHLO 1880 command. In the case of messages with a null 5321.MailFrom, this is 1881 used as the domain for 5321.MailFrom SPF checks, in addition to being 1882 used in 5321.HELO/.EHLO based SPF checks. The standard SPF record 1883 for an individual host that is involved in mail processing is: 1885 relay.example.com. IN TXT "v=spf1 a -all" 1887 Validating correct deployment is difficult. [RFC6652] describes one 1888 mechanism for soliciting feedback on SPF failures. Another 1889 suggestion can be found in Appendix C. 1891 Regardless of the method used, understanding the ADMD's outbound mail 1892 architecture is essential to effective deployment. 1894 10.1.3. Bounces 1896 As explained in Section 1.1.3, [RFC5321] allows the MAIL FROM to be 1897 null, which is typical of some Delivery Status Notification 1898 [RFC3464], commonly called email bounces. In this case the only 1899 entity available for performing an SPF check is the "HELO" identity 1900 defined in Section 1.1.4. SPF functionality is enhanced by 1901 administrators ensuring this identity is set correctly and has an 1902 appropriate SPF record. It is normal to have the HELO identity set 1903 to the hostname instead of the domain. Zone file generation for 1904 significant numbers of hosts can be consolidated using the redirect 1905 modifier and scripted for initial deployment. Specific deployment 1906 advice is given above in Section 10.1.2. 1908 10.2. Receivers 1910 SPF results can be used in combination with other methods to 1911 determine the final local disposition (either positive or negative) 1912 of a message. It can also be considered dispositive on its own. 1914 An attempt to have one organization (sender) direct the email 1915 handling policies of another (receiver) is inherently challenging and 1916 often controversial. As stated elsewhere in this document, there is 1917 no comprehensive normative requirement for specific handling of a 1918 message based on SPF results. The information presented in Section 8 1919 and in Appendix G is offered for receiver consideration when forming 1920 local handling policies. 1922 The primary considerations are that SPF might return "pass" for mail 1923 that is ultimately harmful (e.g., spammers that arrange for SPF to 1924 pass using disposable domain names, or virus or spam outbreaks from 1925 within trusted sources), and might also return "fail" for mail that 1926 is ultimately legitimate (e.g., legitimate mail that has traversed a 1927 mail alias). It is important take both of these cases under 1928 consideration when establishing local handling policy. 1930 10.3. Mediators 1932 Mediators are a type of User actor [RFC5598]. That is, a mediator 1933 takes 'delivery' of a message and posts a 'submission' of a new 1934 message. The mediator can make the newly-posted message be as 1935 similar or as different from the original message as they wish. 1936 Examples include mailing lists (see [RFC5598] Section 5.3) and 1937 ReSenders ([RFC5598] Section 5.2). This is discussed in [RFC5321], 1938 Section 3.9. For the operation of SPF, the essential concern is the 1939 email address in the 5321.MailFrom command for the new message. 1941 Because SPF evaluation is based on the IP address of the "last" 1942 sending SMTP server, the address of the mediator will be used, rather 1943 than the address of the SMTP server that sent the message to the 1944 mediator. Some mediators retain the email address from the original 1945 message, while some use a new address. 1947 If the address is the same as for the original message, and the 1948 original message had an associated SPF record, then the SPF 1949 evaluation will fail unless mitigations such as those described in 1950 Appendix D are used. 1952 11. Security Considerations 1954 11.1. Processing Limits 1956 As with most aspects of email, there are a number of ways that 1957 malicious parties could use the protocol as an avenue for a 1958 Denial-of-Service (DoS) attack. The processing limits outlined in 1959 Section 4.6.4 are designed to prevent attacks such as the following: 1961 o A malicious party could create an SPF record with many references 1962 to a victim's domain and send many emails to different SPF 1963 verifiers; those SPF verifiers would then create a DoS attack. In 1964 effect, the SPF verifiers are being used to amplify the attacker's 1965 bandwidth by using fewer octets in the SMTP session than are used 1966 by the DNS queries. Using SPF verifiers also allows the attacker 1967 to hide the true source of the attack. This potential attack is 1968 based on large volumes of mail being transmitted. 1970 o Whereas implementations of check_host() are supposed to limit the 1971 number of DNS lookups, malicious domains could publish records 1972 that exceed these limits in an attempt to waste computation effort 1973 at their targets when they send them mail. Malicious domains 1974 could also design SPF records that cause particular 1975 implementations to use excessive memory or CPU usage, or to 1976 trigger bugs. If a receiver is configured to accept mail with an 1977 SPF result of "temperror", such an attack might result in mail 1978 that would otherwise have been rejected due to an SPF "fail" 1979 result being accepted. This potential attack is based on 1980 specially crafted SPF records being used to exhaust DNS resources 1981 of the victim. 1983 o Malicious parties could send a large volume of mail purporting to 1984 come from the intended target to a wide variety of legitimate mail 1985 hosts. These legitimate machines would then present a DNS load on 1986 the target as they fetched the relevant records. 1988 o Malicious parties could, in theory, use SPF records as a vehicle 1989 for DNS lookup amplification for a denial-of-service-attack. In 1990 this scenario, the attacker publishes an SPF record in its own DNS 1991 that uses "a" and "mx" mechanisms directed toward the intended 1992 victim, e.g. "a:example.com a:foo.example.com a:bar.example.com 1993 ..." and then distributes mail with a MAIL FROM value including 1994 its own domain in large volume to a wide variety of destinations. 1995 Any such destination operating an SPF verifier will begin querying 1996 all of the names associated with the "a" mechanisms in that 1997 record. The names used in the record needn't exist for the attack 1998 to be effective. Operational experience since publication of 1999 [RFC4408] suggests that mitigation of this class of attack can be 2000 accomplished with minimal impact on the deployed base by having 2001 the verifier abort processing and return "permerror" 2002 (Section 2.6.7) once more than two "void lookups" have been 2003 encountered (defined in Section 4.6.4). 2005 Of these, the case of a third party referenced in the SPF record is 2006 the easiest for a DoS attack to effectively exploit. As a result, 2007 limits that might seem reasonable for an individual mail server can 2008 still allow an unreasonable amount of bandwidth amplification. 2009 Therefore, the processing limits need to be quite low. 2011 11.2. SPF-Authorized Email May Contain Other False Identities 2013 The "MAIL FROM" and "HELO" identity authorizations do not provide 2014 assurance about the authorization/authenticity of other identities 2015 used in the message. It is entirely possible for a malicious sender 2016 to inject a message using his own domain in the identities used by 2017 SPF, to have that domain's SPF record authorize the sending host, and 2018 yet the message can easily list other identities in its header. 2019 Unless the user or the MUA takes care to note that the authorized 2020 identity does not match the other more commonly-presented identities 2021 (such as the From: header field), the user might be lulled into a 2022 false sense of security. 2024 11.3. Spoofed DNS and IP Data 2026 There are two aspects of this protocol that malicious parties could 2027 exploit to undermine the validity of the check_host() function: 2029 o The evaluation of check_host() relies heavily on DNS. A malicious 2030 attacker could attack the DNS infrastructure and cause 2031 check_host() to see spoofed DNS data, and then return incorrect 2032 results. This could include returning "pass" for an value 2033 where the actual domain's record would evaluate to "fail". See 2034 [RFC3833] for a description of DNS weaknesses and see [RFC4033] 2035 for a countermeasure. 2037 o The client IP address, , is assumed to be correct. In a 2038 modern, correctly configured system the risk of this not being 2039 true is nil. 2041 11.4. Cross-User Forgery 2043 By definition, SPF policies just map domain names to sets of 2044 authorized MTAs, not whole email addresses to sets of authorized 2045 users. Although the "l" macro (Section 7) provides a limited way to 2046 define individual sets of authorized MTAs for specific email 2047 addresses, it is generally impossible to verify, through SPF, the use 2048 of specific email addresses by individual users of the same MTA. 2050 It is up to mail services and their MTAs to directly prevent 2051 cross-user forgery: based on SMTP AUTH ([RFC4954]), users have to be 2052 restricted to using only those email addresses that are actually 2053 under their control (see [RFC6409], Section 6.1). Another means to 2054 verify the identity of individual users is message cryptography such 2055 as PGP ([RFC4880]) or S/MIME ([RFC5751]). 2057 11.5. Untrusted Information Sources 2059 An SPF compliant receiver gathers information from the SMTP commands 2060 it receives and from the published DNS records of the sending domain 2061 holder, (e.g., "HELO" domain name, the "MAIL FROM" address from the 2062 envelope, and SPF DNS records published by the domain holder). These 2063 parameters are not validated in the SMTP process. 2065 All of these pieces of information are generated by actors outside of 2066 the authority of the receiver, and thus are not guaranteed to be 2067 accurate or legitimate. 2069 11.5.1. Recorded Results 2071 This information, passed to the receiver in the Received-SPF: or 2072 Authentication-Results: trace fields, can be returned to the client 2073 MTA as an SMTP rejection message. If such an SMTP rejection message 2074 is generated, the information from the trace fields has to be checked 2075 for such problems as invalid characters and excessively long lines. 2077 11.5.2. External Explanations 2079 When the authorization check fails, an explanation string could be 2080 included in the reject response. Both the sender and the rejecting 2081 receiver need to be aware that the explanation was determined by the 2082 publisher of the SPF record checked and, in general, not the 2083 receiver. The explanation can contain malicious URLs, or it might be 2084 offensive or misleading. 2086 Explanations returned to sender domains due to "exp" modifiers 2087 (Section 6.2) were generated by the sender policy published by the 2088 domain holders themselves. As long as messages are only returned 2089 with non-delivery notification ([RFC3464]) to domains publishing the 2090 explanation strings from their own DNS SPF records, the only affected 2091 parties are the original publishers of the domain's SPF records. 2093 In practice, such non-delivery notifications can be misdirected, such 2094 as when an MTA accepts an email and only later generates the 2095 notification to a forged address, or when an email forwarder does not 2096 direct the bounce back to the original sender. 2098 11.5.3. Macro Expansion 2100 Macros (Section 7) allow senders to inject arbitrary text (any non- 2101 null [US-ASCII] character) into receiver DNS queries. It is 2102 necessary to be prepared for hostile or unexpected content. 2104 11.6. Privacy Exposure 2106 Checking SPF records causes DNS queries to be sent to the domain 2107 owner. These DNS queries, especially if they are caused by the 2108 "exists" mechanism, can contain information about who is sending 2109 email and likely to which MTA the email is being sent. This can 2110 introduce some privacy concerns, which are more or less of an issue 2111 depending on local laws and the relationship between the ADMD and the 2112 person sending the email. 2114 11.7. Delivering Mail Producing a 'Fail' Result 2116 Operators that choose to deliver mail for which SPF produces a "fail" 2117 result need to understand that they are admitting content that is 2118 explicitly not authorized by the purported sender. While there are 2119 known failure modes that can be considered "false negatives", the 2120 distinct choice to admit those messages increases end-user exposure 2121 to likely harm. This is especially true for domains belonging to 2122 known good actors that are typically well-behaved; unauthorized mail 2123 from those sources might well be subjected to much higher skepticism 2124 and content analysis. 2126 SPF does not, however, include the capacity for identifying good 2127 actors from bad ones, nor does it handle the concept of known actors 2128 versus unknown ones. Those notions are out of scope for this 2129 specification. 2131 12. Collected ABNF 2133 This section is normative and any discrepancies with the ABNF 2134 fragments in the preceding text are to be resolved in favor of this 2135 grammar. 2137 See [RFC5234] for ABNF notation. Please note that as per this ABNF 2138 definition, literal text strings (those in quotes) are case- 2139 insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx". 2141 record = version terms *SP 2142 version = "v=spf1" 2144 terms = *( 1*SP ( directive / modifier ) ) 2146 directive = [ qualifier ] mechanism 2147 qualifier = "+" / "-" / "?" / "~" 2148 mechanism = ( all / include 2149 / a / mx / ptr / ip4 / ip6 / exists ) 2151 all = "all" 2152 include = "include" ":" domain-spec 2153 a = "a" [ ":" domain-spec ] [ dual-cidr-length ] 2154 mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ] 2155 ptr = "ptr" [ ":" domain-spec ] 2156 ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ] 2157 ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ] 2158 exists = "exists" ":" domain-spec 2160 modifier = redirect / explanation / unknown-modifier 2161 redirect = "redirect" "=" domain-spec 2162 explanation = "exp" "=" domain-spec 2163 unknown-modifier = name "=" macro-string 2164 ; where name is not any known modifier 2166 ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32 2167 ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128 2168 dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] 2170 ip4-network = qnum "." qnum "." qnum "." qnum 2171 qnum = DIGIT ; 0-9 2172 / %x31-39 DIGIT ; 10-99 2173 / "1" 2DIGIT ; 100-199 2174 / "2" %x30-34 DIGIT ; 200-249 2175 / "25" %x30-35 ; 250-255 2176 ; conventional dotted quad notation. e.g., 192.0.2.0 2177 ip6-network = 2178 ; e.g., 2001:DB8::CD30 2180 domain-spec = macro-string domain-end 2181 domain-end = ( "." toplabel [ "." ] ) / macro-expand 2183 toplabel = ( *alphanum ALPHA *alphanum ) / 2184 ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) 2185 ; LDH rule plus additional TLD restrictions 2186 ; (see [RFC3696], Section 2 for background) 2187 alphanum = ALPHA / DIGIT 2189 explain-string = *( macro-string / SP ) 2191 macro-string = *( macro-expand / macro-literal ) 2192 macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) 2193 / "%%" / "%_" / "%-" 2194 macro-literal = %x21-24 / %x26-7E 2195 ; visible characters except "%" 2196 macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / 2197 "c" / "r" / "t" / "v" 2198 transformers = *DIGIT [ "r" ] 2199 delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" 2201 name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) 2203 header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] 2204 [ key-value-list ] CRLF 2206 result = "pass" / "fail" / "softfail" / "neutral" / 2207 "none" / "temperror" / "permerror" 2209 key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) 2210 [";"] 2212 key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) 2214 key = "client-ip" / "envelope-from" / "helo" / 2215 "problem" / "receiver" / "identity" / 2216 "mechanism" / name 2218 identity = "mailfrom" ; for the "MAIL FROM" identity 2219 / "helo" ; for the "HELO" identity 2220 / name ; other identities 2222 sender = Mailbox 2223 ip = ip4-network / ip6-network 2224 ALPHA = 2225 DIGIT = <0-9 as per [RFC5234]> 2226 SP = 2227 dot-atom = 2228 quoted-string = 2229 comment = 2230 CFWS = 2231 FWS = 2232 CRLF = 2234 13. Contributors and Acknowledgements 2236 This document is largely based on the work of Meng Weng Wong, Mark 2237 Lentczner, and Wayne Schlitt. Although, as this section 2238 acknowledges, many people have contributed to this document, a very 2239 large portion of the writing and editing are due to Meng, Mark, and 2240 Wayne. 2242 This design owes a debt of parentage to [RMX] by Hadmut Danisch and 2243 to [DMP] by Gordon Fecyk. The idea of using a DNS record to check 2244 the legitimacy of an email address traces its ancestry further back 2245 through messages on the namedroppers mailing list by Paul Vixie 2246 [Vixie] (based on suggestion by Jim Miller) and by David Green 2247 [Green]. 2249 Philip Gladstone contributed the concept of macros to the 2250 specification, multiplying the expressiveness of the language and 2251 making per-user and per-IP lookups possible. 2253 The authors of both this document and [RFC4408] would also like to 2254 thank the literally hundreds of individuals who have participated in 2255 the development of this design. They are far too numerous to name, 2256 but they include the following: 2258 The participants in the SPFbis working group. 2259 The folks on the spf-discuss mailing list. 2260 The folks on the SPAM-L mailing list. 2261 The folks on the IRTF ASRG mailing list. 2262 The folks on the IETF MARID mailing list. 2263 The folks on #perl. 2265 14. IANA Considerations 2267 14.1. The SPF DNS Record Type 2269 Per [RFC4408], the IANA assigned the Resource Record Type and Qtype 2270 from the DNS Parameters Registry for the SPF RR type with code 99. 2271 The format of this type is identical to the TXT RR [RFC1035]. The 2272 character content of the record is encoded as [US-ASCII]. 2274 Studies have shown that RRTYPE 99 has not seen any substantial use, 2275 and in fact its existence and mechanism defined in [RFC4408] has led 2276 to some interoperability issues. Accordingly, its use is now 2277 obsolete, and new implementations are not to use it. 2279 IANA is requested to update the Resource Record (RR) TYPEs registry 2280 to indicate that this document is the reference document for that 2281 RRTYPE. 2283 [NOTE TO RFC EDITOR: (to be changed to " ... has updated ..." upon 2284 publication)] 2286 14.2. The Received-SPF Mail Header Field 2288 Per [RFC3864], the "Received-SPF:" header field is added to the IANA 2289 Permanent Message Header Field Registry. The following is the 2290 registration template: 2292 Header field name: Received-SPF 2293 Applicable protocol: mail ([RFC5322]) 2294 Status: standard 2295 Author/Change controller: IETF 2296 Specification document(s): RFC XXXX 2297 [NOTE TO RFC EDITOR: (this document)] 2299 14.3. SPF Modifier Registry 2301 IANA is requested to change the reference for the exp and redirect 2302 modifiers in the Modifier Names registry, under Sender Policy 2303 Framework Parameters, from [RFC4408] to this document. Their status 2304 is unchanged. 2306 15. References 2308 15.1. Normative References 2310 [RFC1035] Mockapetris, P., "Domain names - implementation and 2311 specification", STD 13, RFC 1035, November 1987. 2313 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 2314 and Support", STD 3, RFC 1123, October 1989. 2316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2317 Requirement Levels", BCP 14, RFC 2119, March 1997. 2319 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 2320 RFC 3463, January 2003. 2322 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 2323 Procedures for Message Header Fields", BCP 90, RFC 3864, 2324 September 2004. 2326 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2327 Resource Identifier (URI): Generic Syntax", STD 66, 2328 RFC 3986, January 2005. 2330 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2331 Architecture", RFC 4291, February 2006. 2333 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2334 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2336 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2337 October 2008. 2339 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2340 October 2008. 2342 [RFC5451] Kucherawy, M., "Message Header Field for Indicating 2343 Message Authentication Status", RFC 5451, April 2009. 2345 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 2346 July 2009. 2348 [RFC5890] Klensin, J., "Internationalized Domain Names for 2349 Applications (IDNA): Definitions and Document Framework", 2350 RFC 5890, August 2010. 2352 [US-ASCII] 2353 American National Standards Institute (formerly United 2354 States of America Standards Institute), "USA Code for 2355 Information Interchange, X3.4", 1968. 2357 ANSI X3.4-1968 has been replaced by newer versions with 2358 slight modifications, but the 1968 version remains 2359 definitive for the Internet. 2361 15.2. Informative References 2363 [DMP] Fecyk, G., "Designated Mailers Protocol". 2365 Work In Progress 2367 [Green] Green, D., "Domain-Authorized SMTP Mail", 2002. 2369 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2370 STD 13, RFC 1034, November 1987. 2372 [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, 2373 August 1996. 2375 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 2376 RFC 2671, August 1999. 2378 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2379 specifying the location of services (DNS SRV)", RFC 2782, 2380 February 2000. 2382 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 2383 for Delivery Status Notifications", RFC 3464, 2384 January 2003. 2386 [RFC3696] Klensin, J., "Application Techniques for Checking and 2387 Transformation of Names", RFC 3696, February 2004. 2389 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 2390 Name System (DNS)", RFC 3833, August 2004. 2392 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 2393 Electronic Mail", RFC 3834, August 2004. 2395 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2396 Rose, "DNS Security Introduction and Requirements", 2397 RFC 4033, March 2005. 2399 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 2400 for Authorizing Use of Domains in E-Mail, Version 1", 2401 RFC 4408, April 2006. 2403 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 2404 (CIDR): The Internet Address Assignment and Aggregation 2405 Plan", BCP 122, RFC 4632, August 2006. 2407 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2408 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 2410 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 2411 for Authentication", RFC 4954, July 2007. 2413 [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design 2414 Choices When Expanding the DNS", RFC 5507, April 2009. 2416 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 2417 Mail Extensions (S/MIME) Version 3.2 Message 2418 Specification", RFC 5751, January 2010. 2420 [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, 2421 February 2010. 2423 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 2424 STD 72, RFC 6409, November 2011. 2426 [RFC6647] Kucherawy, M. and D. Crocker, "Email Greylisting: An 2427 Applicability Statement for SMTP", RFC 6647, June 2012. 2429 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 2430 "Deprecating the "X-" Prefix and Similar Constructs in 2431 Application Protocols", BCP 178, RFC 6648, June 2012. 2433 [RFC6652] Kitterman, S., "Sender Policy Framework (SPF) 2434 Authentication Failure Reporting Using the Abuse Reporting 2435 Format", RFC 6652, June 2012. 2437 [RFC6686] Kucherawy, M., "Resolution of the Sender Policy Framework 2438 (SPF) and Sender ID Experiments", RFC 6686, July 2012. 2440 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 2441 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 2443 [RMX] Danisch, H., "The RMX DNS RR Type for light weight sender 2444 authentication". 2446 Work In Progress 2448 [Vixie] Vixie, P., "Repudiating MAIL FROM", 2002. 2450 Appendix A. Extended Examples 2452 These examples are based on the following DNS setup: 2454 ; A domain with two mail servers, two hosts 2455 ; and two servers at the domain name 2456 $ORIGIN example.com. 2457 @ MX 10 mail-a 2458 MX 20 mail-b 2459 A 192.0.2.10 2460 A 192.0.2.11 2461 amy A 192.0.2.65 2462 bob A 192.0.2.66 2463 mail-a A 192.0.2.129 2464 mail-b A 192.0.2.130 2465 www CNAME example.com. 2467 ; A related domain 2468 $ORIGIN example.org. 2469 @ MX 10 mail-c 2470 mail-c A 192.0.2.140 2472 ; The reverse IP for those addresses 2473 $ORIGIN 2.0.192.in-addr.arpa. 2474 10 PTR example.com. 2475 11 PTR example.com. 2476 65 PTR amy.example.com. 2477 66 PTR bob.example.com. 2478 129 PTR mail-a.example.com. 2479 130 PTR mail-b.example.com. 2480 140 PTR mail-c.example.org. 2482 ; A rogue reverse IP domain that claims to be 2483 ; something it's not 2484 $ORIGIN 0.0.10.in-addr.arpa. 2485 4 PTR bob.example.com. 2487 A.1. Simple Examples 2489 These examples show various possible published records for 2490 example.com and which values if would cause check_host() to 2491 return "pass". Note that is "example.com". 2493 v=spf1 +all 2494 -- any passes 2496 v=spf1 a -all 2497 -- hosts 192.0.2.10 and 192.0.2.11 pass 2499 v=spf1 a:example.org -all 2500 -- no sending hosts pass since example.org has no A records 2502 v=spf1 mx -all 2503 -- sending hosts 192.0.2.129 and 192.0.2.130 pass 2505 v=spf1 mx:example.org -all 2506 -- sending host 192.0.2.140 passes 2508 v=spf1 mx mx:example.org -all 2509 -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass 2511 v=spf1 mx/30 mx:example.org/30 -all 2512 -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes 2514 v=spf1 ptr -all 2515 -- sending host 192.0.2.65 passes (reverse DNS is valid and is in 2516 example.com) 2517 -- sending host 192.0.2.140 fails (reverse DNS is valid, but not 2518 in example.com) 2519 -- sending host 10.0.0.4 fails (reverse IP is not valid) 2521 v=spf1 ip4:192.0.2.128/28 -all 2522 -- sending host 192.0.2.65 fails 2523 -- sending host 192.0.2.129 passes 2525 A.2. Multiple Domain Example 2527 These examples show the effect of related records: 2529 example.org: "v=spf1 include:example.com include:example.net -all" 2531 This record would be used if mail from example.org actually came 2532 through servers at example.com and example.net. Example.org's 2533 designated servers are the union of example.com's and example.net's 2534 designated servers. 2536 la.example.org: "v=spf1 redirect=example.org" 2537 ny.example.org: "v=spf1 redirect=example.org" 2538 sf.example.org: "v=spf1 redirect=example.org" 2540 These records allow a set of domains that all use the same mail 2541 system to make use of that mail system's record. In this way, only 2542 the mail system's record needs to be updated when the mail setup 2543 changes. These domains' records never have to change. 2545 A.3. DNSBL Style Example 2547 Imagine that, in addition to the domain records listed above, there 2548 are these (see [RFC5782]): 2550 $ORIGIN _spf.example.com. 2551 mary.mobile-users A 127.0.0.2 2552 fred.mobile-users A 127.0.0.2 2553 15.15.168.192.joel.remote-users A 127.0.0.2 2554 16.15.168.192.joel.remote-users A 127.0.0.2 2556 The following records describe users at example.com who mail from 2557 arbitrary servers, or who mail from personal servers. 2559 example.com: 2561 v=spf1 mx 2562 include:mobile-users._spf.%{d} 2563 include:remote-users._spf.%{d} 2564 -all 2566 mobile-users._spf.example.com: 2568 v=spf1 exists:%{l1r+}.%{d} 2570 remote-users._spf.example.com: 2572 v=spf1 exists:%{ir}.%{l1r+}.%{d} 2574 A.4. Multiple Requirements Example 2576 Say that your sender policy requires both that the IP address is 2577 within a certain range and that the reverse DNS for the IP matches. 2578 This can be done several ways, including the following: 2580 example.com. SPF ( "v=spf1 " 2581 "-include:ip4._spf.%{d} " 2582 "-include:ptr._spf.%{d} " 2583 "+all" ) 2584 ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all" 2585 ptr._spf.example.com. SPF "v=spf1 -ptr +all" 2587 This example shows how the "-include" mechanism can be useful, how an 2588 SPF record that ends in "+all" can be very restrictive, and the use 2589 of De Morgan's Law. 2591 Appendix B. Changes in implementation requirements from RFC 4408 2593 The modifications to implementation requirements from [RFC4408] are 2594 all either (a) corrections to errors in [RFC4408], or (b) additional 2595 documentation based on consensus of operational experience acquired 2596 since publication of [RFC4408]. 2598 o Use of DNS RR type SPF (99) has been removed from the protocol, 2599 see [RFC6686] for background. 2601 o A new DNS related processing limit based on "void lookups" has 2602 been added (Section 4.6.4). 2604 o Use of the ptr mechanism and the %p macro have been strongly 2605 discouraged Section 5.5 and Section 7.2. They remain part of the 2606 protocol because they were found to be in use, but records ought 2607 to be updated to avoid them. 2609 o Use of the "Authentication-Results" header field [RFC5451] as a 2610 possible alternative to use of the "Received-SPF" header field is 2611 discussed (Section 9.2). 2613 o There have been a number of minor corrections to the ABNF to make 2614 it more clear and correct Section 12. SPF library implementers 2615 should give the revised ABNF a careful review to determine if 2616 implementation changes are needed. 2618 o Use of X- fields in the ABNF has been removed see [RFC6648] for 2619 background. 2621 o Ambiguity about how to deal with invalid domain-spec after macro 2622 expansion has been documented. Depending on one specific behavior 2623 has to be avoided (Section 4.8). 2625 o General operational information has been updated and expanded 2626 based on eight years of post [RFC4408] operations experience. See 2627 Section 10 and Appendices D - H below. 2629 o Security considerations have been reviewed and updated 2630 (Section 11). 2632 Appendix C. Further Testing Advice 2634 Another approach that can be helpful to publish records that include 2635 a "tracking exists:" mechanism. By looking at the name server logs, 2636 a rough list can then be generated. For example: 2638 v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all 2640 This associated macro expansion would cause the sending helo domain, 2641 localpart of the sending email address, domain part of the sending 2642 email address, and the IP address from which the connection was 2643 received to be embdedded in an SPF query and logged in the sender's 2644 DNS logs. 2646 This approach, which has been used since very early in the SPF 2647 project, allows senders to unilaterally collect data to evaluate the 2648 correctness of their SPF records. Unlike newer feedback mechanisms, 2649 it does not require an special cooperation from SPF verifiers. A 2650 similar example, one of the earliest SPF records published, can still 2651 be found as of this writing at altavista.net. 2653 Appendix D. SPF/Mediator Interactions 2655 There are three places that techniques can be used to ameliorate 2656 unintended SPF failures with mediators. 2658 D.1. Originating ADMDs 2660 The beginning, when email is first sent: 2662 o "Neutral" results could be given for IP addresses that might be 2663 forwarders, instead of "fail" results based on a list of known 2664 reliable forwarders. For example: 2666 "v=spf1 mx ?exists:%{ir}.whitelist.example.org -all" 2668 This would cause a lookup on an DNS white list (DNSWL) and cause a 2669 result of "fail" only for email not either coming from the 2670 domain's mx host(s) (SPF pass) or white listed sources (SPF 2671 neutral). This, in effect, outsources an element of sender policy 2672 to the maintainer of the whitelist. 2674 o The "MAIL FROM" identity could have additional information in the 2675 local-part that cryptographically identifies the mail as coming 2676 from an authorized source. In this case, such an SPF record could 2677 be used: 2679 "v=spf1 mx exists:%{l}._spf_verify.%{d} -all" 2681 Then, a specialized DNS server can be set up to serve the 2682 _spf_verify subdomain that validates the local-part. Although 2683 this requires an extra DNS lookup, this happens only when the 2684 email would otherwise be rejected as not coming from a known good 2685 source. 2686 Note that due to the 63-character limit for domain labels, this 2687 approach only works reliably if the local-part signature scheme is 2688 guaranteed either to only produce local-parts with a maximum of 63 2689 characters or to gracefully handle truncated local-parts. 2691 o Similarly, a specialized DNS server could be set up that will 2692 rate-limit the email coming from unexpected IP addresses. 2694 "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all" 2696 o SPF allows the creation of per-user policies for special cases. 2697 For example, the following SPF record and appropriate wildcard DNS 2698 records can be used: 2700 "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}" 2702 D.2. Mediators 2704 The middle, when email is forwarded:. 2706 o Mediators can solve the problem by rewriting the "MAIL FROM" to be 2707 in their own domain. This means mail rejected from the external 2708 mailbox will have to be forwarded back to the original sender by 2709 the forwarding service. Various schemes to do this exist though 2710 they vary widely in complexity and resource requirements on the 2711 part of the mediator. 2713 o Several popular MTAs can be forced from "alias" semantics to 2714 "mailing list" semantics by configuring an additional alias with 2715 "owner-" prepended to the original alias name (e.g., an alias of 2716 "friends: george@example.com, fred@example.org" would need another 2717 alias of the form "owner-friends: localowner"). 2719 o Mediators could reject mail that would "fail" SPF if forwarded 2720 using an SMTP reply code of 551, User not local, (see [RFC5321] 2721 section 3.4) to communicate the correct target address to resend 2722 the mail to. 2724 D.3. Receiving ADMDs 2726 The end, when email is received: 2728 o If the owner of the external mailbox wishes to trust the mediator, 2729 he can direct the external mailbox's MTA to skip SPF tests when 2730 the client host belongs to the mediator. 2732 o Tests against other identities, such as the "HELO" identity, can 2733 be used to override a failed test against the "MAIL FROM" 2734 identity. 2736 o For larger domains, it might not be possible to have a complete or 2737 accurate list of forwarding services used by the owners of the 2738 domain's mailboxes. In such cases, whitelists of generally- 2739 recognized forwarding services could be employed. 2741 Appendix E. Mail Services 2743 MSPs (Mail Service Providers - [RFC5598] Section 2.3) that offer mail 2744 services to third-party domains, such as sending of bulk mail, might 2745 want to adjust their configurations in light of the authorization 2746 check described in this document. If the domain part of the "MAIL 2747 FROM" identity used for such email uses the domain of one of the MSPs 2748 domain, then the provider needs only to ensure that its sending host 2749 is authorized by its own SPF record, if any. 2751 If the "MAIL FROM" identity does not use the MSP's domain, then extra 2752 care has to be taken. The SPF record format has several options for 2753 the third-party domain to authorize the service provider's MTAs to 2754 send mail on its behalf. For MSPs, such as ISPs, that have a wide 2755 variety of customers using the same MTA, steps are required to 2756 mitigate the risk of cross-customer forgery (see Section 11.4). 2758 Appendix F. MTA Relays 2760 Relays are described in [RFC5598] Section 2.2.2. The authorization 2761 check generally precludes the use of arbitrary MTA relays between 2762 sender and receiver of an email message. 2764 Within an organization, MTA relays can be effectively deployed. 2765 However, for purposes of this document, such relays are effectively 2766 transparent. The SPF authorization check is a check between border 2767 MTAs of different ADMDs. 2769 For mail senders, this means that published SPF records have to 2770 authorize any MTAs that actually send across the Internet. Usually, 2771 these are just the border MTAs as internal MTAs simply forward mail 2772 to these MTAs for relaying. 2774 The receiving ADMD will generally want to perform the authorization 2775 check at the boundary MTAs, including all secondary MXs. Internal 2776 MTAs (including MTAs that might serve both as boundary MTAs and 2777 internal relays from secondary MXs when they are processing the 2778 relayed mail stream) then do not perform the authorization test. To 2779 perform the authorization test other than at the boundary, the host 2780 that first transferred the message to the receiving ADMD have to be 2781 determined, which can be difficult to extract from the message header 2782 because (a) header fields can be forged or malformed, and (b) there's 2783 no standard way to encode that information such that it can be 2784 reliably extracted. Testing other than at the boundary is likely to 2785 produce unreliable results. This is described further in Appendix C 2786 of [RFC5451]. 2788 Appendix G. Local Policy Considerations 2790 SPF results can be used in combination with other methods to 2791 determine the final local disposition (either positive or negative of 2792 a message. It can also be considered dispositive on its own. 2794 G.1. Policy For SPF Pass 2796 SPF pass results can be used in combination with "white lists" of 2797 known "good" domains to bypass some or all additional pre-delivery 2798 email checks. Exactly which checks and how to determine appropriate 2799 white list entries has to be based on local conditions and 2800 requirements. 2802 G.2. Policy For SPF Fail 2804 SPF fail results can be used to reject messages during the SMTP 2805 transaction based on either "MAIL FROM" or "HELO" identity results. 2806 This reduces resource requirements for various content filtering 2807 methods and conserves bandwidth since rejection can be done before 2808 the SMTP content is transferred. It also gives immediate feedback to 2809 the sender who might then be able to resolve the issue. Due to some 2810 of the issues described above in this section (Section 10), SPF based 2811 rejection does present some risk of rejecting legitimate email when 2812 rejecting based on "MAIL FROM" results. 2814 SPF fail results can alternately be used as one input into a larger 2815 set of evaluations which might, based on a combination with other 2816 evaluation techniques, result in the email being marked negatively in 2817 some way (this might be via delivery to a special spam folder, 2818 modifying subject lines, or other locally determined means). 2819 Developing the details of such an approach have to be based on local 2820 conditions and requirements. Using SPF results in this way does not 2821 have the advantages of resource conservation and immediate feedback 2822 to the sender associated with SMTP rejection, but could produce fewer 2823 undesirable rejections in a well designed system. Such an approach 2824 might result in email that was not authorized by the sending ADMD 2825 being unknowingly delivered to end users. 2827 Either general approach can be used as they both leave a clear 2828 disposition of emails. They are either delivered in some manner or 2829 the sender is notified of the failure. Other dispositions such as 2830 "dropping" or deleting email after acceptance are inappropriate 2831 because they leave uncertainty and reduce the overall reliability and 2832 utility of email across the Internet. 2834 G.3. Policy For SPF Permerror 2836 The "permerror" result (see Section 2.6.7) indicates the SPF 2837 processing module at the receiver determined that the retrieved SPF 2838 policy record could not be interpreted. This gives no true 2839 indication about the authorized use of the data found in the 2840 envelope. 2842 As with all results, implementers have a choice to make regarding 2843 what to do with a message that yields this result. SMTP allows only 2844 a few basic options. 2846 Rejection of the message is an option, in that it is the one thing a 2847 receiver can do to draw attention to the difficulty encountered while 2848 protecting itself from messages that do not have a definite SPF 2849 result of some kind. However, if the SPF implementation is defective 2850 and returns spurious "permerror" results, only the sender is actively 2851 notified of the defect (in the form of rejected mail), and not the 2852 receiver making use of SPF. 2854 The less intrusive handling choice is to deliver the message, perhaps 2855 with some kind of annotation of the difficulty encountered and/or 2856 logging of a similar nature. However, this will not be desirable to 2857 SPF verifier operators that wish to implement SPF checking as 2858 strictly as possible, nor is this sort of passive problem reporting 2859 typically effective. 2861 There is of course the option placing this choice in the hands of the 2862 SPF verifier operator rather than the implementer since this kind of 2863 choice is often a matter of local policy rather than a condition with 2864 a universal solution, but this adds one more piece of complexity to 2865 an already non-trivial environment. 2867 Both implementers and SPF verfier operators need to be cautious of 2868 all choices and outcomes when handling SPF results. 2870 G.4. Policy For SPF Temperror 2872 The "temperror" result (see Section 2.6.6) indicates the SPF 2873 processing module at the receiver could not retrieve and SPF policy 2874 record due to a (probably) transient condition. This gives no true 2875 indication about the authorized use of the data found in the 2876 envelope. 2878 As with all results, implementers have a choice to make regarding 2879 what to do with a message that yields this result. SMTP allows only 2880 a few basic options. 2882 Deferring the message is an option, in that it is the one thing a 2883 receiver can do to draw attention to the difficulty encountered while 2884 protecting itself from messages that do not have a definite SPF 2885 result of some kind. However, if the SPF implementation is defective 2886 and returns spurious "temperror" results, only the sender is actively 2887 notified of the defect (in the form of mail rejected after it times 2888 out of the sending queue), and not the receiver making use of SPF. 2890 Because of long queue lifetimes, it is possible that mail will be 2891 repeatedly deferred for several days and so any awareness by the 2892 sender of a problem could be quite delayed. If "temperrors" persist 2893 for multiple delivery attempts, it might be preferable to treat the 2894 error as permanent and reduce the amount of time the message is in 2895 transit. 2897 The less intrusive handling choice is to deliver the message, perhaps 2898 with some kind of annotation of the difficulty encountered and/or 2899 logging of a similar nature. However, this will not be desirable to 2900 SPF verifier operators that wish to implement SPF checking as 2901 strictly as possible, nor is this sort of passive problem reporting 2902 typically effective. 2904 There is of course the option placing this choice in the hands of the 2905 SPF verifier operator rather than the implementer since this kind of 2906 choice is often a matter of local policy rather than a condition with 2907 a universal solution, but this adds one more piece of complexity to 2908 an already non-trivial environment. 2910 Both implementers and SPF verifier operators need to be cautious of 2911 all choices and outcomes when handling SPF results. 2913 Appendix H. Protocol Status 2915 NOTE TO RFC EDITOR: To be removed prior to publication. 2917 SPF has been in development since the summer of 2003 and has seen 2918 deployment beyond the developers beginning in December 2003. The 2919 design of SPF slowly evolved until the spring of 2004 and has since 2920 stabilized. There have been quite a number of forms of SPF, some 2921 written up as documents, some submitted as Internet Drafts, and many 2922 discussed and debated in development forums. The protocol was 2923 originally defined in [RFC4408], which this document replaces. 2925 [RFC4408] was designed to clearly document the protocol defined by 2926 earlier draft specifications of SPF as used in existing 2927 implementations. This updated specification is intended to clarify 2928 identified ambiguities in [RFC4408], resolve technical issues 2929 identified in post-RFC 4408 deployment experience, and document 2930 widely deployed extensions to SPF that have been developed since 2931 [RFC4408] was published. 2933 This document updates and replaces RFC 4408 that was part of a group 2934 of simultaneously published Experimental RFCs (RFC 4405, RFC 4406, 2935 RFC 4407, and RFC 4408) in 2006. At that time the IESG requested the 2936 community observe the success or failure of the two approaches 2937 documented in these RFCs during the two years following publication, 2938 in order that a community consensus could be reached in the future. 2940 SPF is widely deployed by large and small email providers alike. 2941 There are multiple, interoperable implementations. 2943 For SPF (as documented in RFC 4408) a careful effort was made to 2944 collect and document lessons learned and errata during the two year 2945 period. The errata list has been stable (no new submissions) and 2946 only minor protocol lessons learned were identified. Resolution of 2947 the IESG's experiment is documented in [RFC6686]. 2949 Appendix I. Change History 2951 NOTE TO RFC EDITOR: Changes since RFC 4408 (to be removed prior to 2952 publication) 2954 Moved to standards track 2956 Authors updated 2958 IESG Note regarding experimental use replaced with discussion of 2959 results 2961 Process errata: 2963 Resolved Section 2.5.7 PermError on invalid domains after macro 2964 expansion errata in favor of documenting that different verifiers 2965 produce different results. 2967 Add %v macro to ABNF grammar 2969 Replace "uric" by "unreserved" 2971 Recommend an SMTP reply code for optional permerror rejections 2973 Correct syntax in Received-SPF examples 2975 Fix unknown-modifier clause is too greedy in ABNF 2977 Correct use of empty domain-spec on exp modifier 2979 Fix minor typo errata 2981 Convert to spfbis working group draft, 2982 draft-ietf-spfbis-4408bis-00 2984 Clarified text about IPv4 mapped addresses to resolve test suite 2985 ambiguity 2987 Clarified ambiguity about result when more than 10 "mx" or "ptr" 2988 records are returned for lookup to specify permerror. This 2989 resolves one of the test suite ambiguities 2991 Made all references to result codes lower case per issue #7 2993 Adjusted section 2.2 Requirement to check mail from per issue #15 2995 Added missing "v" element in macro-letter in the collected ABNF 2996 per issue #16 - section 8.1 was already fixed in the pre-WG draft 2997 Marked ptr and "p" macro SHOULD NOT use per issue #27 2999 Expunged lower case may from the draft per issue #8 3001 Expunged "x-" name as an obsolete concept 3003 Updated obslete references: RFC2821 to RFC5321, RFC2822 to 3004 RFC5322, and RFC4234 to RFC5234 3006 Refer to RFC6647 to describe greylisting instead of trying to 3007 describe it directly. 3009 Updated informative references to the current versions. 3011 Start to rework section 9 with some RFC5598 terms. 3013 Added mention of RFC 6552 feedback reports in section 9. 3015 Added draft-ietf-spfbis-experiment as an informational reference. 3017 Drop Type SPF. 3019 Try and clarify informational nature of RFC3696 3021 Fix ABNF nits and add missing definitions per Bill's ABNF checker. 3023 Make DNS lookup time limit SHOULD instead of MAY. 3025 Reorganize and clarify processing limits. Move hard limits to new 3026 section 4.6.4, Evaluation Limits. Move advice to non-normative 3027 section 10. 3029 Removed paragraph in section 11.1 about limiting total data 3030 volumes as it is unused (and removable per the charter) and serves 3031 no purpose (it isn't something that actually can be implemented in 3032 any reasonable way). 3034 Added text from Alessandro Vesely in section 10.1 to better 3035 explain DNS resource limits. 3037 Multiple editorial fixes from Murray Kucherawy's review. 3039 Also based on Murray's review, reworked SMTP identity definitions 3040 and made RFC 5598 a normative reference instead of informative. 3041 This is a downref that will have to be mentioned in the last call. 3043 Added RFC 3834 as an informative reference about backscatter. 3045 Added IDN requirements and normative reference to RFC 5890 to deal 3046 with the question "like DKIM did it.: 3048 Added informative reference to RFC 4632 for CIDR and use CIDR 3049 prefix length instead of CIDR-length to match its terminology. 3051 Simplified the exists description. 3053 Added text on creating a Authentication-Results header field that 3054 matches the Received-SPF header field information and added a 3055 normative reference to RFC 5451. 3057 Added informative reference to RFC 2782 due to SRV mention. 3059 Added informative reference to RFC 3464 due to DSN mention. 3061 Added informative reference to RFC 5617 for its DNS wildcard use. 3063 Clarified the intended match/no-match method for exists. 3065 Added new sections on Receiver policy for SPF pass, fail, and 3066 permerror. 3068 Added new section 10 discussion on treatment of bounces and the 3069 significance of HELO records. 3071 Added request to IANA to update the SPF modifier registry. 3073 Substantially reorganized the document for improved readability 3074 for new users based on WG consensus. 3076 Added new DNS "void lookup" processing limit to mitigate potential 3077 future risk of SPF being used as a DDoS vector. 3079 Author's Address 3081 Scott Kitterman 3082 Kitterman Technical Services 3083 3611 Scheel Dr 3084 Ellicott City, MD 21042 3085 United States of America 3087 Email: scott@kitterman.com