idnits 2.17.1 draft-schlitt-spf-classic-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2323. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2336. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1185 has weird spacing: '...pe-from the e...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 6, 2005) is 6871 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 1976, but not defined ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' -- Obsolete informational reference (is this intentional?): RFC 2440 (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 2554 (Obsoleted by RFC 4954) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Wong 3 Internet-Draft W. Schlitt 4 Expires: December 8, 2005 June 6, 2005 6 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-MAIL, 7 version 1 8 draft-schlitt-spf-classic-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 8, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 E-mail on the Internet can be forged in a number of ways. In 42 particular, existing protocols place no restriction on what a sending 43 host can use as the reverse-path of a message or the domain given on 44 the SMTP HELO/EHLO commands. This document describes version 1 of 45 the SPF protocol, whereby a domain may explicitly authorize the hosts 46 that are allowed to use its domain name, and a receiving host may 47 check such authorization. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.1. State of this draft . . . . . . . . . . . . . . . . . . . 4 53 1.2. Protocol Status . . . . . . . . . . . . . . . . . . . . . 5 54 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 55 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 2.1. The HELO Identity . . . . . . . . . . . . . . . . . . . . 6 57 2.2. The MAIL FROM Identity . . . . . . . . . . . . . . . . . . 6 58 2.3. Publishing Authorization . . . . . . . . . . . . . . . . . 6 59 2.4. Checking Authorization . . . . . . . . . . . . . . . . . . 7 60 2.5. Interpreting the Result . . . . . . . . . . . . . . . . . 8 61 2.5.1. None . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 2.5.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 9 63 2.5.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 2.5.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 2.5.5. SoftFail . . . . . . . . . . . . . . . . . . . . . . . 9 66 2.5.6. TempError . . . . . . . . . . . . . . . . . . . . . . 10 67 2.5.7. PermError . . . . . . . . . . . . . . . . . . . . . . 10 68 3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 3.1. Publishing . . . . . . . . . . . . . . . . . . . . . . . . 11 70 3.1.1. DNS Resource Record Types . . . . . . . . . . . . . . 11 71 3.1.2. Multiple DNS Records . . . . . . . . . . . . . . . . . 12 72 3.1.3. Multiple Strings in a Single DNS record . . . . . . . 12 73 3.1.4. Record Size . . . . . . . . . . . . . . . . . . . . . 12 74 3.1.5. Wildcard Records . . . . . . . . . . . . . . . . . . . 13 75 4. The check_host() Function . . . . . . . . . . . . . . . . . . 14 76 4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 14 77 4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 14 79 4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 15 80 4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 15 81 4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 15 82 4.6.1. Term Evaluation . . . . . . . . . . . . . . . . . . . 16 83 4.6.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 16 84 4.6.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . 17 85 4.7. Default Result . . . . . . . . . . . . . . . . . . . . . . 17 86 4.8. Domain Specification . . . . . . . . . . . . . . . . . . . 17 87 5. Mechanism Definitions . . . . . . . . . . . . . . . . . . . . 19 88 5.1. "all" . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 5.2. "include" . . . . . . . . . . . . . . . . . . . . . . . . 20 90 5.3. "a" . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 92 5.5. "ptr" . . . . . . . . . . . . . . . . . . . . . . . . . . 22 93 5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 23 94 5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 24 95 6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 25 96 6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 25 97 6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 26 98 7. The Received-SPF header field . . . . . . . . . . . . . . . . 28 99 8. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 100 8.1. Macro definitions . . . . . . . . . . . . . . . . . . . . 30 101 8.2. Expansion Examples . . . . . . . . . . . . . . . . . . . . 33 102 9. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 34 103 9.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 34 104 9.2. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 34 105 9.3. Forwarding Services and Aliases . . . . . . . . . . . . . 34 106 9.4. Mail Services . . . . . . . . . . . . . . . . . . . . . . 36 107 9.5. MTA Relays . . . . . . . . . . . . . . . . . . . . . . . . 37 108 10. Security Considerations . . . . . . . . . . . . . . . . . . . 38 109 10.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 38 110 10.2. SPF-Authorized E-Mail May Be UBE . . . . . . . . . . . . . 39 111 10.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 40 112 10.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 40 113 10.5. Untrusted Information Sources . . . . . . . . . . . . . . 40 114 10.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 41 115 11. Contributors and Acknowledgements . . . . . . . . . . . . . . 42 116 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 117 12.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 43 118 12.2. The Received-SPF mail header . . . . . . . . . . . . . . . 43 119 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 120 13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 121 13.2. Informative References . . . . . . . . . . . . . . . . . . 44 122 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 46 123 Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 48 124 B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 48 125 B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 49 126 B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 50 127 B.4. Multiple Requirements Example . . . . . . . . . . . . . . 50 128 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 51 129 C.1. Changes in Version -02 . . . . . . . . . . . . . . . . . . 51 130 C.2. Changes in Version -01 . . . . . . . . . . . . . . . . . . 52 131 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 55 132 Intellectual Property and Copyright Statements . . . . . . . . . . 56 134 1. Introduction 136 The current e-mail infrastructure has the property that any host 137 injecting mail into the mail system can identify itself as any domain 138 name it wants. Hosts can do this at a variety of levels: in 139 particular, the session, the envelope, and the mail headers. While 140 this feature is desirable in some circumstances, it is a major 141 obstacle to reducing Unsolicited Bulk E-mail (UBE, aka "spam"). 142 Furthermore, many domain name holders are understandably concerned 143 about the ease with which other entities may make use of their domain 144 names, often with malicious intent. 146 This document defines a protocol by which domain owners may authorize 147 hosts to use their domain name in the "MAIL FROM" or "HELO" identity. 148 Compliant domain holders publish SPF records specifying which hosts 149 are permitted to use their names, and compliant mail receivers use 150 the published SPF records to test the authorization of sending MTAs 151 using a given "HELO" or "MAIL FROM" identity during a mail 152 transaction. 154 An additional benefit to mail receivers is that after the use of an 155 identity is verified, local policy decisions about the mail can be 156 made based on the sender's domain, rather than the host's IP address. 157 This is advantageous because reputation of domain names is likely to 158 be more accurate than reputation of host IP addresses. Furthermore, 159 if a claimed identity fails verification, local policy can take 160 stronger action against such e-mail, such as rejecting it. 162 1.1. State of this draft 164 This draft version attempts to resolve all known issues and address 165 all comments received from the IESG review of 2005/02/17, as well 166 reviews from the namedroppers, ietf-smtp, ietf-822 and spf-discuss 167 mailing lists both in January and in May. 169 Please check the Change log in Appendix C before proposing changes, 170 as it is possible that your idea has already been discussed. Please 171 post comments on the spf-discuss@v2.listbox.com mailing list or 172 e-mail them directly to the author. 174 I am sorry for the length of this I-D; I have not had time to make it 175 shorter. 177 RFC Editor Note: Please remove this section for the final publication 178 of the document. It has been inspired by 179 draft-ietf-tools-draft-submission-09.txt. 181 1.2. Protocol Status 183 SPF has been in development since the Summer of 2003, and has seen 184 deployment beyond the developers beginning in December, 2003. The 185 design of SPF slowly evolved until the spring of 2004 and has since 186 stabilized. There have been quite a number of forms of SPF, some 187 written up as documents, some submitted as Internet Drafts, and many 188 discussed and debated in development forums. 190 The goal of this document is to clearly document the protocol defined 191 by earlier draft specifications of SPF as used in existing 192 implementations. This conception of SPF is sometimes called "SPF 193 Classic". It is understood that particular implementations and 194 deployments may differ from, and build upon, this work. It is hoped 195 that we have nonetheless captured the common understanding of SPF 196 version 1. 198 1.3. Terminology 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 202 document are to be interpreted as described in [RFC2119]. 204 This document is concerned with the portion of a mail message 205 commonly called "envelope sender", "return path", "reverse path", 206 "bounce address", "2821 FROM", or "MAIL FROM". Since these terms are 207 either not well defined, or often used casually, this document 208 defines the "MAIL FROM" identity in Section 2.2. Note that other 209 terms that may superficially look like the common terms, such as 210 "reverse-path", are used only with the defined meanings from 211 normative documents. 213 2. Operation 215 2.1. The HELO Identity 217 The "HELO" identity derives from either the SMTP HELO or EHLO command 218 (see [RFC2821]). These commands supply the SMTP client (sending 219 host) for the SMTP session. Note that requirements for the domain 220 presented in the EHLO or HELO command are not always clear to the 221 sending party, and SPF clients must be prepared for the "HELO" 222 identity to be malformed or an IP address literal. At the time of 223 this writing, many legitimate e-mails are delivered with invalid HELO 224 domains. 226 It is RECOMMENDED that SPF clients check not only the "MAIL FROM" 227 identity, but also separately check the "HELO" identity by applying 228 the check_host() function (Section 4) to the "HELO" identity as the 229 . 231 2.2. The MAIL FROM Identity 233 The "MAIL FROM" identity derives from the SMTP MAIL command (see 234 [RFC2821]). This command supplies the "reverse-path" for a message, 235 which generally consists of the sender mailbox, and is the mailbox to 236 which notification messages are to be sent if there are problems 237 delivering the message. 239 [RFC2821] allows the reverse-path to be null (see Section 4.5.5). In 240 this case, there is no explicit sender mailbox, and such a message 241 can be assumed to be a notification message from the mail system 242 itself. When the reverse-path is null, this document defines the 243 "MAIL FROM" identity to be the mailbox composed of the localpart 244 "postmaster" and the "HELO" identity (which may or may not have been 245 checked separately before). 247 SPF clients MUST check the "MAIL FROM" identity. SPF clients check 248 the "MAIL FROM" identity by applying the check_host() function to the 249 "MAIL FROM" identity as the . 251 2.3. Publishing Authorization 253 An SPF-compliant domain MUST publish a valid SPF record as described 254 in Section 3. This record authorizes the use of the domain name in 255 the "HELO" and "MAIL FROM" identities by the MTAs it specifies. 257 If domain owners choose to publish SPF records, it is RECOMMENDED 258 that they end in "-all", or redirect to other records that do, so 259 that a definitive determination of authorization can be made. 261 Domain holders may publish SPF records that explicitly authorize no 262 hosts if mail should never originate using that domain. 264 When changing SPF records, care must be taken to ensure that there is 265 a transition period so that the old policy remains valid until all 266 legitimate e-mail has been checked. 268 2.4. Checking Authorization 270 A mail receiver can perform a set of SPF checks for each mail message 271 it receives. An SPF check tests the authorization of a client host 272 to emit mail with a given identity. Typically, such checks are done 273 by a receiving MTA, but can be performed elsewhere in the mail 274 processing chain so long as the required information is available and 275 reliable. At least the "MAIL FROM" identity MUST be checked, but it 276 is RECOMMENDED that the "HELO" identity also be checked beforehand. 278 Without explicit approval of the domain owner, checking other 279 identities against SPF version 1 records is NOT RECOMMENDED because 280 there are cases that are known to give incorrect results. For 281 example, almost all mailing lists rewrite the "MAIL FROM" identity 282 (see Section 9.2), but some do not change any other identities in the 283 message. The scenario described in Section 9.3.1.2 is another 284 example. Documents that define other identities should define the 285 method for explicit approval. 287 It is possible that mail receivers will use the SPF check as part of 288 a larger set of tests on incoming mail. The results of other tests 289 may influence whether or not a particular SPF check is performed. 290 For example, finding the sending host's IP address on a local white 291 list may cause all other tests to be skipped and all mail from that 292 host to be accepted. 294 When a mail receiver decides to perform an SPF check, it MUST use a 295 correctly-implemented check_host() function (Section 4) evaluated 296 with the correct parameters. While the test as a whole is optional, 297 once it has been decided to perform a test it must be performed as 298 specified so that the correct semantics are preserved between 299 publisher and receiver. 301 To make the test, the mail receiver MUST evaluate the check_host() 302 function with the arguments set as follows: 304 - the IP address of the SMTP client that is emitting the 305 mail, either IPv4 or IPv6. 307 - the domain portion of the "MAIL FROM" or "HELO" identity. 309 - the "MAIL FROM" or "HELO" identity. 311 Note that the argument may not be a well-formed domain name. 312 For example, if the reverse-path was null, then the EHLO/HELO domain 313 is used, with its associated problems (see Section 2.1). In these 314 cases, check_host() is defined in Section 4.3 to return a "None" 315 result. 317 While invalid, malformed, or non-existent domains cause SPF checks to 318 return "None" because no SPF record can be found, it has long been 319 the policy of many MTAs to reject e-mail from such domains, 320 especially in the case of invalid "MAIL FROM". In order to prevent 321 the circumvention of SPF records, rejecting e-mail from invalid 322 domains should be considered. 324 Implementations must take care to correctly extract the from 325 the data given with the SMTP MAIL FROM command as many MTAs will 326 still accept such things as source routes (see [RFC2821] appendix C), 327 the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). These 328 archaic features have been maliciously used to bypass security 329 systems. 331 2.5. Interpreting the Result 333 This section describes how software that performs the authorization 334 should interpret the results of the check_host() function. The 335 authorization check SHOULD be performed during the processing of the 336 SMTP transaction that sends the mail. This allows errors to be 337 returned directly to the sending server by way of SMTP replies. 339 Performing the authorization after the SMTP transaction has finished 340 may cause problems, such as: 1) It may be difficult to accurately 341 extract the required information from potentially deceptive headers. 342 2) Legitimate e-mail may fail because the sender's policy may have 343 since changed. 345 Generating non-delivery notifications to forged identities that have 346 failed the authorization check is generally abusive and against the 347 explicit wishes of the identity owner. 349 2.5.1. None 351 A result of "None" means that no records were published by the 352 domain, or that no checkable sender domain could be determined from 353 the given identity. The checking software cannot ascertain whether 354 the client host is authorized or not. 356 2.5.2. Neutral 358 The domain owner has explicitly stated that they cannot or do not 359 want to assert whether the IP address is authorized or not. A 360 "Neutral" result MUST be treated exactly like the "None" result; the 361 distinction exists only for informational purposes. Treating 362 "Neutral" more harshly than "None" will discourage domain owners from 363 testing the use of SPF records (see Section 9.1). 365 2.5.3. Pass 367 A "Pass" result means that the client is authorized to inject mail 368 with the given identity. The domain can now, in the sense of 369 reputation, be considered responsible for sending the message. 370 Further policy checks can now proceed with confidence in the 371 legitimate use of the identity. 373 2.5.4. Fail 375 A "Fail" result is an explicit statement that the client is not 376 authorized to use the domain in the given identity. The checking 377 software can choose to mark the mail based on this, or to reject the 378 mail outright. 380 If the checking software chooses to reject the mail during the SMTP 381 transaction, then it SHOULD use an SMTP reply code of 550 (see 382 [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification 383 (DSN) code (see [RFC3464]), in addition to an appropriate reply text. 384 The check_host() function may return either a default explanation 385 string, or one from the domain that published the SPF records (see 386 Section 6.2). If the information doesn't originate with the checking 387 software, it should be made clear that the text is provided by the 388 sender's domain. For example: 390 550-5.7.1 SPF MAIL FROM check failed: 391 550-5.7.1 The domain example.com explains: 392 550 5.7.1 Please see http://www.example.com/mailpolicy.html 394 2.5.5. SoftFail 396 A "SoftFail" result should be treated as somewhere between a "Fail" 397 and a "Neutral". The domain believes the host isn't authorized but 398 isn't willing to make that strong of a statement. Receiving software 399 SHOULD NOT reject the message based solely on this result, but MAY 400 subject the message to closer scrutiny than normal. 402 The domain owner wants to discourage the use of this host and so they 403 desire limited feedback when a "SoftFail" result occurs. For 404 example, the recipient's MUA could highlight the "SoftFail" status, 405 or the receiving MTA could give the sender a message using a 406 technique called "greylisting" whereby the MTA can issue an SMTP 407 reply code of 451 (4.3.0 DSN code) with a note the first time the 408 message is received, but accept it the second time. 410 2.5.6. TempError 412 A "TempError" result means that the SPF client encountered a 413 transient error while performing the check. Checking software can 414 choose to accept or temporarily reject the message. If the message 415 is rejected during the SMTP transaction for this reason, the software 416 SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN 417 code. 419 2.5.7. PermError 421 A "PermError" result means that the domain's published records 422 couldn't be correctly interpreted. This signals an error condition 423 that requires manual intervention to be resolved, as opposed to the 424 TempError result. Be aware that if the domain owner uses macros 425 (Section 8), it is possible that this result is due to the checked 426 identities having an unexpected format. 428 3. SPF Records 430 An SPF record is a DNS Resource Record (RR) that declares which hosts 431 are, and are not, authorized to use a domain name for the "HELO" and 432 "MAIL FROM" identities. Loosely, the record partitions all hosts 433 into permitted and not-permitted sets. (Though some hosts might fall 434 into neither category.) 436 The SPF record is a single string of text. An example record is: 438 v=spf1 +mx a:colo.example.com/28 -all 440 This record has a version of "spf1" and three directives: "+mx", 441 "a:colo.example.com/28" (the + is implied), and "-all". 443 3.1. Publishing 445 Domain owners wishing to be SPF compliant must publish SPF records 446 for the hosts that are used in the "MAIL FROM" and "HELO" identities. 447 The SPF records are placed in the DNS tree at the host name it 448 pertains to, not a subdomain under it, such as is done with SRV 449 records. This is the same whether the TXT or SPF RR type is used. 451 The example above in Section 3 might be published via this lines in a 452 domain zone file: 454 example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" 455 smtp-out.example.com. TXT "v=spf1 a -all" 457 When publishing via TXT records, beware of other TXT records 458 published there for other purposes. They may cause problems with 459 size limits (see Section 3.1.4). 461 3.1.1. DNS Resource Record Types 463 This document defines a new DNS RR of type SPF, type code to be 464 determined. The format of this type is identical to the TXT RR 465 [RFC1035]. For either type, the character content of the record is 466 encoded as [US-ASCII]. 468 RFC Editor Note: Please add the DNS RR type code once it has been 469 allocated by the IANA. 471 It is recognized that the current practice (using a TXT record) is 472 not optimal, but it is necessary because there are a number of DNS 473 server and resolver implementations in common use that cannot handle 474 the new RR type. The two-record-type scheme provides a forward path 475 to the better solution of using an RR type reserved for this purpose. 477 An SPF-compliant domain name SHOULD have SPF records of both RR 478 types. A compliant domain name MUST have a record of at least one 479 type. If a domain has records of both types, they MUST have 480 identical content. For example, instead of just publishing one 481 record as in Section 3.1 above, it is better to publish: 483 example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all" 484 example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all" 486 Example RRs in this document are shown with the TXT record type, 487 however they could be published with the SPF type or with both types. 489 3.1.2. Multiple DNS Records 491 A domain name MUST NOT have multiple records that would cause an 492 authorization check to select more than one record. See Section 4.5 493 for the selection rules. 495 3.1.3. Multiple Strings in a Single DNS record 497 As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS 498 record (either TXT and SPF RR types) can be composed of more than one 499 string. If a published record contains multiple strings, then the 500 record MUST be treated as if those strings are concatenated together 501 without adding spaces. For example: 503 IN TXT "v=spf1 .... first" "second string..." 505 MUST be treated as equivalent to 507 IN TXT "v=spf1 .... firstsecond string..." 509 SPF or TXT records containing multiple strings are useful in order to 510 construct records which would exceed the 255 byte maximum length of a 511 string within a single TXT or SPF RR record. 513 3.1.4. Record Size 515 The published SPF record for a given domain name SHOULD remain small 516 enough that the results of a query for it will fit within 512 octets. 517 This will keep even older DNS implementations from falling over to 518 TCP. Since the answer size is dependent on many things outside the 519 scope of this document, it is only possible to give this guideline: 520 If the combined length of the DNS name and the text of all the 521 records of a given type (TXT or SPF) is under 450 characters, then 522 DNS answers should fit in UDP packets. Note that when computing the 523 sizes for queries of the TXT format, one must take into account any 524 other TXT records published at the domain name. Records that are too 525 long to fit in a single UDP packet MAY be silently ignored by SPF 526 clients. 528 3.1.5. Wildcard Records 530 Use of wildcard records for publishing is not recommended. Care must 531 be taken if wildcard records are used. If a domain publishes 532 wildcard MX records, it may want to publish wildcard declarations, 533 subject to the same requirements and problems. In particular, the 534 declaration must be repeated for any host that has any RR records at 535 all, and for subdomains thereof. For example, the example given in 536 [RFC1034], Section 4.3.3, could be extended with: 538 X.COM. MX 10 A.X.COM 539 X.COM. TXT "v=spf1 a:A.X.COM -all" 541 *.X.COM. MX 10 A.X.COM 542 *.X.COM. TXT "v=spf1 a:A.X.COM -all" 544 A.X.COM. A 1.2.3.4 545 A.X.COM. MX 10 A.X.COM 546 A.X.COM. TXT "v=spf1 a:A.X.COM -all" 548 *.A.X.COM. MX 10 A.X.COM 549 *.A.X.COM. TXT "v=spf1 a:A.X.COM -all" 551 Notice that SPF records must be repeated twice for every name within 552 the domain: once for the name, and once with a wildcard to cover the 553 tree under the name. 555 Use of wildcards is discouraged in general as they cause every name 556 under the domain to exist and queries against arbitrary names will 557 never return RCODE 3 (Name Error). 559 4. The check_host() Function 561 The check_host() function fetches SPF records, parses them, and 562 interprets them to determine whether a particular host is or is not 563 permitted to send mail with a given identity. Mail receivers that 564 perform this check MUST correctly evaluate the check_host() function 565 as described here. 567 Implementations MAY use a different algorithm than the canonical 568 algorithm defined here, so long as the results are the same in all 569 cases. 571 4.1. Arguments 573 The function check_host() takes these arguments: 575 - the IP address of the SMTP client that is emitting the 576 mail, either IPv4 or IPv6. 578 - the domain that provides the sought-after authorization 579 information; initially the domain portion of the "MAIL FROM" 580 or "HELO" identity. 582 - the "MAIL FROM" or "HELO" identity. 584 The domain portion of will usually be the same as the 585 argument when check_host() is initially evaluated. However, 586 this will generally not be true for recursive evaluations (see 587 Section 5.2 below). 589 Actual implementations of the check_host() function may need 590 additional arguments. 592 4.2. Results 594 The function check_host() can return one of several results described 595 in Section 2.5. Based on the result, the action to be taken is 596 determined by the local policies of the receiver. 598 4.3. Initial Processing 600 If the is malformed (label longer than 63 characters, zero 601 length label not at the end, etc.), is not a fully qualified domain 602 name, or if the DNS lookup returns "domain does not exist" (RCODE 3), 603 check_host() immediately returns the result "None". 605 If the has no localpart, substitute the string "postmaster" 606 for the localpart. 608 4.4. Record Lookup 610 In accordance with how the records are published, see Section 3.1 611 above, a DNS query needs to be made for the name, querying 612 for either RR type TXT, SPF, or both. If both SPF and TXT RRs are 613 looked up, the queries MAY be done in parallel. 615 If the DNS lookup returns a server failure (RCODE 2), or other error 616 (RCODE other than 0 or 3), or the query times out, check_host() exits 617 immediately with the result "TempError". 619 4.5. Selecting Records 621 Records begin with a version section: 623 record = version terms *SP 624 version = "v=spf1" 626 Starting with the set of records that were returned by the lookup, 627 record selection proceeds in three steps: 629 1. Records that do not begin with a version section of exactly 630 "v=spf1" are discarded. Note that the version section is 631 terminated either by a SP character or the end of the record. A 632 record with a version section of "v=spf10" does not match and 633 must be discarded. 635 2. If there are both SPF and TXT records in the set and if they are 636 not all identical, return a "PermError". 638 3. If any records of type SPF are in the set, then all records of 639 type TXT are discarded. 641 After the above steps, there should be exactly one record remaining 642 and evaluation can proceed. If there are two or more records 643 remaining, then check_host() exits immediately with the result of 644 "PermError". 646 If no matching records are returned, an SPF client MUST assume that 647 the domain makes no SPF declarations. SPF processing MUST stop and 648 return "None". 650 4.6. Record Evaluation 652 After one SPF record has been selected, the check_host() function 653 parses and interprets it to find a result for the current test. If 654 there are any syntax errors, check_host() returns immediately with 655 the result "PermError". 657 Implementations MAY choose to parse the entire record first and 658 return "PermError" if the record is not syntactically well formed. 659 However, in all cases, any syntax errors anywhere in the record MUST 660 be detected. 662 4.6.1. Term Evaluation 664 There are two types of terms: mechanisms and modifiers. A record 665 contains an ordered list of these as specified in the following ABNF. 667 terms = *( 1*SP ( directive / modifier ) ) 669 directive = [ qualifier ] mechanism 670 qualifier = "+" / "-" / "?" / "~" 671 mechanism = ( all / include 672 / A / MX / PTR / IP4 / IP6 / exists ) 673 modifier = redirect / explanation / unknown-modifier 674 unknown-modifier = name "=" macro-string 676 name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) 678 Most mechanisms allow a ":" or "/" character after the name. 680 Modifiers always contain an equals ('=') character immediately after 681 the name, and before any ":" or "/" characters that may be part of 682 the macro-string. 684 Terms that do not contain any of "=", ":" or "/" are mechanisms, as 685 defined in Section 5. 687 As per the definition of the ABNF notation in [I-D.crocker-abnf- 688 rfc2234bis], mechanism and modifier names are case-insensitive. 690 4.6.2. Mechanisms 692 Each mechanism is considered in turn from left to right. If there 693 are no more mechanisms, the result is specified in Section 4.7. 695 When a mechanism is evaluated, one of three things can happen: it can 696 match, it can not match, or it can throw an exception. 698 If it matches, processing ends and the qualifier value is returned as 699 the result of that record. If it does not match, processing 700 continues with the next mechanism. If it throws an exception, 701 mechanism processing ends and the exception value is returned. 703 The possible qualifiers, and the results they return are: 705 "+" Pass 706 "-" Fail 707 "~" SoftFail 708 "?" Neutral 710 The qualifier is optional and defaults to "+". 712 When a mechanism matches and the qualifier is "-", then a "Fail" 713 result is returned and the explanation string is computed as 714 described in Section 6.2. 716 The specific mechanisms are described in Section 5. 718 4.6.3. Modifiers 720 Modifiers are not mechanisms: they do not return match or not-match. 721 Instead they provide additional information. While modifiers do not 722 directly affect the evaluation of the record, the "redirect" modifier 723 has an effect after all the mechanisms have been evaluated. 725 4.7. Default Result 727 If none of the mechanisms match and there is no "redirect" modifier, 728 then the check_host() returns a result of "Neutral", just as if 729 "?all" were specified as the last directive. If there is a 730 "redirect" modifier, check_host() proceeds as defined in Section 6.1. 732 Note that records SHOULD always either use a "redirect" modifier or 733 an "all" mechanism to explicitly terminate processing. 735 For example: 737 v=spf1 +mx -all 738 or 739 v=spf1 +mx redirect=_spf.example.com 741 4.8. Domain Specification 743 Several of these mechanisms and modifiers have a 744 section. The string is macro expanded (see Section 8). 745 The resulting string is the common presentation form of a fully- 746 qualified DNS name: a series of labels separated by periods. This 747 domain is called the in the rest of this document. 749 Note: The result of the macro expansion is not subject to any further 750 escaping. Hence, this facility cannot produce all characters that 751 are legal in a DNS label (e.g. the control characters). However, 752 this facility is powerful enough to express legal host names, and 753 common utility labels (such as "_spf") that are used in DNS. 755 For several mechanisms, the is optional. If it is not 756 provided, the is used as the . 758 5. Mechanism Definitions 760 This section defines two types of mechanisms. 762 Basic mechanisms contribute to the language framework. They do not 763 specify a particular type of authorization scheme. 765 all 766 include 768 Designated sender mechanisms are used to designate a set of 769 addresses as being permitted or not permitted to use the for 770 sending mail. 772 a 773 mx 774 ptr 775 ip4 776 ip6 777 exists 779 The following conventions apply to all mechanisms that perform a 780 comparison between and an IP address at any point: 782 If no CIDR-length is given in the directive, then and the IP 783 address are compared for equality. 785 If a CIDR-length is specified, then only the specified number of 786 high-order bits of and the IP address are compared for equality. 788 When any mechanism fetches host addresses to compare with , when 789 is an IPv4 address, A records are fetched, when is an IPv6 790 address, AAAA records are fetched. Even if the SMTP connection is 791 via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513] section 792 2.5.5) MUST still be considered an IPv4 address. 794 Several mechanisms rely on information fetched from DNS. For these 795 DNS queries, except where noted, if the DNS server returns an error 796 (RCODE other than 0 or 3) or the query times out, the mechanism 797 throws the exception "TempError". If the server returns "domain does 798 not exist" (RCODE 3), then evaluation of the mechanism continues as 799 if the server returned no error (RCODE 0) and zero answer records. 801 5.1. "all" 803 all = "all" 805 The "all" mechanism is a test that always matches. It is used as the 806 rightmost mechanism in a record to provide an explicit default. 808 For example: 810 v=spf1 a mx -all 812 Mechanisms after "all" will never be tested. Any "redirect" modifier 813 (Section 6.1) has no effect when there is an "all" mechanism. 815 5.2. "include" 817 include = "include" ":" domain-spec 819 The "include" mechanism triggers a recursive evaluation of 820 check_host(). The domain-spec is expanded as per Section 8. Then 821 check_host() is evaluated with the resulting string as the . 822 The and arguments remain the same as in the current 823 evaluation of check_host(). 825 In hindsight, the name "include" was poorly chosen. Only the 826 evaluated result of the referenced SPF record is used, rather than 827 acting as if the referenced SPF record was literally included in the 828 first. For example, evaluating a "-all" directive in the referenced 829 record does not terminate the overall processing and does not 830 necessarily result in an overall "Fail". (Better names for this 831 mechanism would have been "if-pass", "on-pass", etc.) 833 The "include" mechanism makes it possible for one domain to designate 834 multiple administratively-independent domains. For example, a vanity 835 domain "example.net" might send mail using the servers of 836 administratively-independent domains example.com and example.org. 838 Example.net could say 840 IN TXT "v=spf1 include:example.com include:example.org -all" 842 This would direct check_host() to, in effect, check the records of 843 example.com and example.org for a "Pass" result. Only if the host 844 were not permitted for either of those domains would the result be 845 "Fail". 847 Whether this mechanism matches, does not match, or throws an error, 848 depends on the result of the recursive evaluation of check_host(): 850 +---------------------------------+---------------------------------+ 851 | A recursive check_host() result | Causes the "include" mechanism | 852 | of: | to: | 853 +---------------------------------+---------------------------------+ 854 | Pass | match | 855 | | | 856 | Fail | not match | 857 | | | 858 | SoftFail | not match | 859 | | | 860 | Neutral | not match | 861 | | | 862 | TempError | throw TempError | 863 | | | 864 | PermError | throw PermError | 865 | | | 866 | None | throw PermError | 867 +---------------------------------+---------------------------------+ 869 The "include" mechanism is intended for crossing administrative 870 boundaries. While it is possible to use includes to consolidate 871 multiple domains that share the same set of designated hosts, domains 872 are encouraged to use redirects where possible, and to minimize the 873 number of includes within a single administrative domain. For 874 example, if example.com and example.org were managed by the same 875 entity, and if the permitted set of hosts for both domains were 876 "mx:example.com", it would be possible for example.org to specify 877 "include:example.com", but it would be preferable to specify 878 "redirect=example.com" or even "mx:example.com". 880 5.3. "a" 882 This mechanism matches if is one of the 's IP 883 addresses. 885 A = "a" [ ":" domain-spec ] [ dual-cidr-length ] 887 An address lookup is done on the . The is compared 888 to the returned address(es). If any address matches, the mechanism 889 matches. 891 5.4. "mx" 893 This mechanism matches if is one of the MX hosts for a domain 894 name. 896 MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] 897 check_host() first performs an MX lookup on the . Then 898 it performs an address lookup on each MX name returned. The is 899 compared to each returned IP address. To prevent DoS attacks, more 900 than 10 MX names MUST NOT be looked up during the evaluation of an 901 "mx" mechanism (see Section 10). If any address matches, the 902 mechanism matches. 904 Note regarding implicit MXes: If the has no MX records, 905 check_host() MUST NOT pretend the target is its single MX, and MUST 906 NOT default to an A lookup on the directly. This 907 behavior breaks with the legacy "implicit MX" rule. See [RFC2821] 908 Section 5. If such behavior is desired, the publisher should specify 909 an "a" directive. 911 5.5. "ptr" 913 This mechanism tests whether the DNS reverse mapping for exists 914 and correctly points to a domain name within a particular domain. 916 PTR = "ptr" [ ":" domain-spec ] 918 First the 's name is looked up using this procedure: perform a 919 DNS reverse-mapping for , looking up the corresponding PTR record 920 in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa." 921 if it is an IPv6 address. For each record returned, validate the 922 domain name by looking up its IP address. To prevent DoS attacks, 923 more than 10 PTR names MUST NOT be looked up during the evaluation of 924 a "ptr" mechanism (see Section 10). If is among the returned IP 925 addresses, then that domain name is validated. In pseudocode: 927 sending-domain_names := ptr_lookup(sending-host_IP); 928 if more than 10 sending-domain_names are found, use at most 10. 929 for each name in (sending-domain_names) { 930 IP_addresses := a_lookup(name); 931 if the sending-domain_IP is one of the IP_addresses { 932 validated-sending-domain_names += name; 933 } 934 } 936 Check all validated domain names to see if they end in the 937 domain. If any do, this mechanism matches. If no 938 validated domain name can be found, or if none of the validated 939 domain names end in the , this mechanism fails to match. 940 If a DNS error occurs while doing the PTR RR lookup, then this 941 mechanism fails to match. If a DNS error occurs while doing an A RR 942 lookup, then that domain name is skipped and the search continues. 944 Pseudocode: 946 for each name in (validated-sending-domain_names) { 947 if name ends in , return match. 948 if name is , return match. 949 } 950 return no-match. 952 This mechanism matches if the is either an ancestor of 953 a validated domain name, or if the and a validated 954 domain name are the same. For example: "mail.example.com" is within 955 the domain "example.com", but "mail.bad-example.com" is not. 957 Note: Use of this mechanism is discouraged because it is slow, is not 958 as reliable as other mechanisms in cases of DNS errors and it places 959 a large burden on the arpa name servers. If used, proper PTR records 960 must be in place for the domain's hosts and the "ptr" mechanism 961 should be one of the last mechanisms checked. 963 5.6. "ip4" and "ip6" 965 These mechanisms test whether is contained within a given IP 966 network. 968 IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] 969 IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] 971 ip4-cidr-length = "/" 1*DIGIT 972 ip6-cidr-length = "/" 1*DIGIT 973 dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] 975 ip4-network = qnum "." qnum "." qnum "." qnum 976 qnum = DIGIT ; 0-9 977 / %x31-39 DIGIT ; 10-99 978 / "1" 2DIGIT ; 100-199 979 / "2" %x30-34 DIGIT ; 200-249 980 / "25" %x30-35 ; 250-255 981 ; as per conventional dotted quad notation. e.g. 192.0.2.0 982 ip6-network = 983 ; e.g. 2001:DB8::CD30 985 The is compared to the given network. If CIDR-length high-order 986 bits match, the mechanism matches. 988 If ip4-cidr-length is omitted it is taken to be "/32". If 989 ip6-cidr-length is omitted it is taken to be "/128". It is not 990 permitted to omit parts of the IP address instead of using CIDR 991 notations. That is, use 192.0.2.0/24 instead of 192.0.2. 993 5.7. "exists" 995 This mechanism is used to construct an arbitrary domain name that is 996 used for a DNS A record query. It allows for complicated schemes 997 involving arbitrary parts of the mail envelope to determine what is 998 permitted. 1000 exists = "exists" ":" domain-spec 1002 The domain-spec is expanded as per Section 8. The resulting domain 1003 name is used for a DNS A RR lookup. If any A record is returned, 1004 this mechanism matches. The lookup type is 'A' even when the 1005 connection type is IPv6. 1007 Domains can use this mechanism to specify arbitrarily complex 1008 queries. For example, suppose example.com publishes the record: 1010 v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all 1012 The might expand to 1013 "1.2.0.192.someuser._spf.example.com". This makes fine-grained 1014 decisions possible at the level of the user and client IP address. 1016 This mechanism enables queries that mimic the style of tests that 1017 existing anti-spam DNS blacklists (DNSBL) use. 1019 6. Modifier Definitions 1021 Modifiers are name/value pairs that provide additional information. 1022 Modifiers always have an "=" separating the name and the value. 1024 The modifiers defined in this document ("redirect" and "exp") MAY 1025 appear anywhere in the record, but SHOULD appear at the end, after 1026 all mechanisms. Ordering of these two modifiers does not matter. 1027 These two modifiers MUST NOT appear in a record more than once each. 1028 If they do, then check_host() exits with a result of "PermError". 1030 Unrecognized modifiers MUST be ignored no matter where in a record, 1031 or how often. This allows implementations of this document to 1032 gracefully handle records with modifiers that are defined in other 1033 specifications. 1035 6.1. redirect: Redirected Query 1037 If all mechanisms fail to match, and a "redirect" modifier is 1038 present, then processing proceeds as follows: 1040 redirect = "redirect" "=" domain-spec 1042 The domain-spec portion of the redirect section is expanded as per 1043 the macro rules in Section 8. Then check_host() is evaluated with 1044 the resulting string as the . The and 1045 arguments remain the same as current evaluation of check_host(). 1047 The result of this new evaluation of check_host() is then considered 1048 the result of the current evaluation with the exception that if no 1049 SPF record is found, or if the target-name is malformed, the result 1050 is a "PermError" rather than "None". 1052 Note that the newly-queried domain may itself specify redirect 1053 processing. 1055 This facility is intended for use by organizations that wish to apply 1056 the same record to multiple domains. For example: 1058 la.example.com. TXT "v=spf1 redirect=_spf.example.com" 1059 ny.example.com. TXT "v=spf1 redirect=_spf.example.com" 1060 sf.example.com. TXT "v=spf1 redirect=_spf.example.com" 1061 _spf.example.com. TXT "v=spf1 mx:example.com -all" 1063 In this example, mail from any of the three domains is described by 1064 the same record. This can be an administrative advantage. 1066 Note: In general, the domain "A" cannot reliably use a redirect to 1067 another domain "B" not under the same administrative control. Since 1068 the stays the same, there is no guarantee that the record at 1069 domain "B" will correctly work for mailboxes in domain "A", 1070 especially if domain "B" uses mechanisms involving localparts. An 1071 "include" directive may be more appropriate. 1073 For clarity it is RECOMMENDED that any "redirect" modifier appear as 1074 the very last term in a record. 1076 6.2. exp: Explanation 1078 explanation = "exp" "=" domain-spec 1080 If check_host() results in a "Fail" due to a mechanism match (such as 1081 "-all"), and the "exp" modifier is present, then the explanation 1082 string returned is computed as described below. If no "exp" modifier 1083 is present, then either a default explanation string or an empty 1084 explanation string may be returned. 1086 The is macro expanded (see Section 8) and becomes the 1087 . The DNS TXT record for the is fetched. 1089 If is empty, or there are any DNS processing errors 1090 (any RCODE other than 0), or if no records are returned, or if more 1091 than one record is returned, or if there are syntax errors in the 1092 explanation string, then proceed as if no exp modifier was given. 1094 The fetched TXT record's strings are concatenated with no spaces, and 1095 then treated as an which is macro-expanded. This 1096 final result is the explanation string. Implementations MAY limit 1097 the length of the resulting explanation string to allow for other 1098 protocol constraints and/or reasonable processing limits. Since the 1099 explanation string is intended for an SMTP response and [RFC2821] 1100 section 2.4 says that responses are in [US-ASCII], the explanation 1101 string is also limited to US-ASCII. 1103 Software evaluating check_host() can use this string to communicate 1104 information from the publishing domain in the form of a short message 1105 or URL. Software SHOULD make it clear that the explanation string 1106 comes from a third party. For example, it can prepend the macro 1107 string "%{o} explains: " to the explanation, such as shown in 1108 Section 2.5.4. 1110 Suppose example.com has this record: 1112 v=spf1 mx -all exp=explain._spf.%{d} 1114 Here are some examples of possible explanation TXT records at 1115 explain._spf.example.com: 1116 "Mail from example.com should only be sent by its own servers." 1117 -- a simple, constant message 1119 "%{i} is not one of %{d}'s designated mail servers." 1120 -- a message with a little more info, including the IP address 1121 that failed the check 1123 "See http://%{d}/why.html?s=%{S}&i=%{I}" 1124 -- a complicated example that constructs a URL with the 1125 arguments to check_host() so that a web page can be 1126 generated with detailed, custom instructions 1128 Note: During recursion into an "include" mechanism, an exp= modifier 1129 from the MUST NOT be used. In contrast, when executing 1130 a "redirect" modifier, an exp= modifier from the original domain MUST 1131 NOT be used. 1133 7. The Received-SPF header field 1135 It is RECOMMENDED that SMTP receivers record the result of SPF 1136 processing in the message headers. If an SMTP receiver chooses to do 1137 so, it SHOULD use the "Received-SPF" header defined here for each 1138 identity that was checked. This information is intended for the 1139 recipient. (Information intended for the sender is described in 1140 Section 6.2, Explanation.) 1142 The Received-SPF header is a trace field (see [RFC2822] section 1143 3.6.7) and SHOULD be prepended to existing headers, above the 1144 Received: header that is generated by the SMTP receiver. It MUST 1145 appear above any other Received-SPF headers in the message. The 1146 header has the format: 1148 header = "Received-SPF:" [CFWS] result FWS [comment FWS] 1149 [ key-value-list ] CRLF 1151 result = "Pass" / "Fail" / "SoftFail" / "Neutral" / 1152 "None" / "TempError" / "PermError" 1154 key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) 1155 [";"] 1157 key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) 1159 key = "client-ip" / "envelope-from" / "helo" / 1160 "problem" / "receiver" / "identity" / 1161 mechanism / "x-" name / name 1163 identity = "mailfrom" ; for the "MAIL FROM" identity 1164 / "helo" ; for the "HELO" identity 1165 / name ; other identities 1167 dot-atom = 1168 quoted-string = 1169 comment = 1170 CFWS = 1171 FWS = 1172 CRLF = 1174 The header SHOULD include a "(...)" style after the result, 1175 conveying supporting information for the result, such as , 1176 and . 1178 The following key-value pairs are designed for later machine parsing. 1179 SPF clients SHOULD give enough information so that the SPF results 1180 can be verified. That is, at least the "client-ip", "helo", and, if 1181 the "MAIL FROM" identity was checked, the "envelope-from". 1183 client-ip the IP address of the SMTP client 1185 envelope-from the envelope sender mailbox 1187 helo the host name given in the HELO or EHLO command 1189 mechanism the mechanism that matched (if no mechanisms matched, 1190 substitute the word "default".) 1192 problem if an error was returned, details about the error 1194 receiver the host name of the SPF client 1196 identity the identity that was checked, see the ABNF 1197 rule. 1199 Other keys may be defined by SPF clients. Until a new key name 1200 becomes widely accepted, new key names should start with "x-". 1202 SPF clients MUST make sure that the Received-SPF header does not 1203 contain invalid characters, is not excessively long, and does not 1204 contain malicious data that has been provided by the sender. 1206 Examples of various header styles that could be generated: 1208 Received-SPF: Pass (mybox.example.org: domain of 1209 myname@example.com designates 192.0.2.1 as permitted sender) 1210 receiver=mybox.example.org; client-ip=192.0.2.1; 1211 envelope-from=; helo=foo.example.com; 1213 Received-SPF: Fail (mybox.example.org: domain of 1214 myname@example.com does not designate 1215 192.0.2.1 as permitted sender) 1216 identity=mailfrom; client-ip=192.0.2.1; 1217 envelope-from=; 1219 8. Macros 1221 8.1. Macro definitions 1223 Many mechanisms and modifiers perform macro expansion on part of the 1224 term. 1226 domain-spec = macro-string domain-end 1227 domain-end = ( "." toplabel ) / macro-expand 1229 toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum 1230 ; LDH rule (See [RFC3696]) 1231 alphanum = ALPHA / DIGIT 1233 explain-string = *( macro-string / SP ) 1235 macro-string = *( macro-expand / macro-literal ) 1236 macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) 1237 / "%%" / "%_" / "%-" 1238 macro-literal = %x21-24 / %x26-7E 1239 ; visible characters except "%" 1240 macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / 1241 "c" / "r" / "t" 1242 transformers = *DIGIT [ "r" ] 1243 delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" 1245 A literal "%" is expressed by "%%". 1247 "%_" expands to a single " " space. 1248 "%-" expands to a URL-encoded space, viz. "%20". 1250 The following macro letters are expanded in term arguments: 1252 s = 1253 l = local-part of 1254 o = domain of 1255 d = 1256 i = 1257 p = the validated domain name of 1258 v = the string "in-addr" if is ipv4, or "ip6" if is ipv6 1259 h = HELO/EHLO domain 1261 The following macro letters are only allowed in "exp" text: 1263 c = SMTP client IP (easily readable format) 1264 r = domain name of host performing the check 1265 t = current timestamp 1267 A '%' character not followed by a '{', '%', '-', or '_' character is 1268 a syntax error. So, 1270 -exists:%(ir).sbl.spamhaus.example.org 1272 is incorrect and will cause check_host() to return a "PermError". 1273 Instead, say 1275 -exists:%{ir}.sbl.spamhaus.example.org 1277 Optional transformers are: 1279 *DIGIT = zero or more digits 1280 'r' = reverse value, splitting on dots by default 1282 If transformers or delimiters are provided, the replacement value for 1283 a macro letter is split into parts. After performing any reversal 1284 operation and/or removal of left-hand parts, the parts are rejoined 1285 using "." and not the original splitting characters. 1287 By default, strings are split on "." (dots). Note that no special 1288 treatment is given to leading, trailing or consecutive delimiters, 1289 and so the list of parts may contain empty strings. Macros may 1290 specify delimiter characters which are used instead of ".". 1292 The 'r' transformer indicates a reversal operation: if the client IP 1293 address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1" 1294 and the macro %{ir} would expand to "1.2.0.192". 1296 The DIGIT transformer indicates the number of right-hand parts to 1297 use, after optional reversal. If a DIGIT is specified, the value 1298 MUST be nonzero. If no DIGITs are specified, or if the value 1299 specifies more parts than are available, all the available parts are 1300 used. If the DIGIT was 5, and only 3 parts were available, the macro 1301 interpreter would pretend the DIGIT was 3. Implementations MUST 1302 support at least a value of 128, as that is the maximum number of 1303 labels in a domain name. 1305 The "s" macro expands to the argument. It is an e-mail 1306 address with a localpart, an "@" character, and a domain. The "l" 1307 macro expands to just the localpart. The "o" macro expands to just 1308 the domain part. Note that these values remain the same during 1309 recursive and chained evaluations due to "include" and/or "redirect". 1310 Note also that if the original had no localpart, the 1311 localpart was set to "postmaster" in initial processing (see 1312 Section 4.3). 1314 For IPv4 addresses, both the "i" and "c" macros expand to the 1315 standard dotted-quad format. 1317 For IPv6 addresses, the "i" macro expands to a dot-format address; it 1318 is intended for use in %{ir}. The "c" macro may expand to any of the 1319 hexadecimal colon-format addresses specified in [RFC3513] section 1320 2.2. It is intended for humans to read. 1322 The "p" macro expands to the validated domain name of . The 1323 procedure for finding the validated domain name is defined in 1324 Section 5.5. If the is present in the list of validated 1325 domains, it SHOULD be used. Otherwise, if a subdomain of the 1326 is present, it SHOULD be used. Otherwise, any name from the 1327 list may be used. If there are no validated domain names or if a DNS 1328 error occurs, the string "unknown" is used. 1330 The "r" macro expands to the name of the receiving MTA. This SHOULD 1331 be a fully qualified domain name, but if one does not exist (as when 1332 the checking is done by a MUA) or if policy restrictions dictate 1333 otherwise, the word "unknown" SHOULD be substituted. The domain name 1334 may be different than the name found in the MX record that the client 1335 MTA used to locate the receiving MTA. 1337 The "t" macro expands to the decimal representation of the 1338 approximate number of seconds since the Epoch (Midnight, January 1st, 1339 1970, UTC). This is the same value as is returned by the POSIX 1340 time() function in most standards-compliant libraries. 1342 When the result of macro expansion is used in a domain name query, if 1343 the expanded domain name exceeds 253 characters (the maximum length 1344 of a domain name), the left side is truncated to fit, by removing 1345 successive domain labels until the total length does not exceed 253 1346 characters. 1348 Uppercased macros expand exactly as their lower case equivalents, and 1349 are then URL escaped. URL escaping must be performed for characters 1350 not in the "uric" set, which is defined in [RFC3986]. 1352 Note: Care must be taken so that macro expansion for legitimate 1353 e-mail does not exceed the 63 character limit on DNS labels. The 1354 localpart of e-mail addresses, in particular, can have more than 63 1355 characters between dots. 1357 Note: Domains should avoid using the "s", "l", "o", or "h" macros in 1358 conjunction with any mechanism directive. While these macros are 1359 powerful and allow per-user records to be published, they severely 1360 limit the ability of implementations to cache results of check_host() 1361 and they reduce the effectiveness of DNS caches. 1363 Implementations should be aware that if no directive processed during 1364 the evaluation of check_host() contains an "s", "l", "o" or "h" 1365 macro, then the results of the evaluation can be cached on the basis 1366 of and alone for as long as the shortest TTL of all the 1367 DNS records involved. 1369 8.2. Expansion Examples 1371 The is strong-bad@email.example.com. 1372 The IPv4 SMTP client IP is 192.0.2.3. 1373 The IPv6 SMTP client IP is 2001:DB8::CB01. 1374 The PTR domain name of the client IP is mx.example.org. 1376 macro expansion 1377 ------- ---------------------------- 1378 %{s} strong-bad@email.example.com 1379 %{o} email.example.com 1380 %{d} email.example.com 1381 %{d4} email.example.com 1382 %{d3} email.example.com 1383 %{d2} example.com 1384 %{d1} com 1385 %{dr} com.example.email 1386 %{d2r} example.email 1387 %{l} strong-bad 1388 %{l-} strong.bad 1389 %{lr} strong-bad 1390 %{lr-} bad.strong 1391 %{l1r-} strong 1393 macro-string expansion 1394 -------------------------------------------------------------------- 1395 %{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com 1396 %{lr-}.lp._spf.%{d2} bad.strong.lp._spf.example.com 1398 %{lr-}.lp.%{ir}.%{v}._spf.%{d2} 1399 bad.strong.lp.3.2.0.192.in-addr._spf.example.com 1401 %{ir}.%{v}.%{l1r-}.lp._spf.%{d2} 1402 3.2.0.192.in-addr.strong.lp._spf.example.com 1404 %{d2}.trusted-domains.example.net 1405 example.com.trusted-domains.example.net 1407 IPv6: 1408 %{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0. 1409 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 1411 9. Implications 1413 This section outlines the major implications that adoption of this 1414 document will have on various entities involved in Internet e-mail. 1415 It is intended to make clear to the reader where this document 1416 knowingly affects the operation of such entities. This section is 1417 not a "how-to" manual, nor a "best practices" document, and is not a 1418 comprehensive list of what such entities should do in light of this 1419 document. 1421 This section is non-normative. 1423 9.1. Sending Domains 1425 Domains that wish to be compliant with this specification will need 1426 to determine the list of hosts that they allow to use their domain 1427 name in the "HELO" and "MAIL FROM" identities. It is recognized that 1428 forming such a list is not just a simple technical exercise, but 1429 involves policy decisions with both technical and administrative 1430 considerations. 1432 It can be helpful to publish records that include a "tracking 1433 exists:" mechanism. By looking at the name server logs, a rough list 1434 may then be generated. For example: 1436 v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all 1438 9.2. Mailing Lists 1440 Mailing lists must be aware of how they re-inject mail that is sent 1441 to the list. Mailing lists MUST comply with the requirements in 1442 [RFC2821] Section 3.10 and [RFC1123] Section 5.3.6 that say that the 1443 reverse-path MUST be changed to be the mailbox of a person or other 1444 entity who administers the list. While the reasons for changing the 1445 reverse-path are many and long standing, SPF adds enforcement to this 1446 requirement. 1448 In practice, almost all mailing list software in use already complies 1449 with this requirement. Mailing lists that do not comply may or may 1450 not encounter problems depending on how access to the list is 1451 restricted. Such lists that are entirely internal to a domain (only 1452 people in the domain can send to or receive from the list) are not 1453 affected. 1455 9.3. Forwarding Services and Aliases 1457 Forwarding services take mail that is received at a mailbox and 1458 direct it to some external mailbox. At the time of this writing, the 1459 near-universal practice of such services is to use the original "MAIL 1460 FROM" of a message when re-injecting it for delivery to the external 1461 mailbox. [RFC1123] and [RFC2821] describe this action as an "alias" 1462 rather than a "mail list". This means the external mailbox's MTA 1463 sees all such mail in a connection from a host of the forwarding 1464 service, and so the "MAIL FROM" identity will not, in general, pass 1465 authorization. 1467 There are three places that techniques can be used to ameliorate this 1468 problem. 1470 1. The beginning, when e-mail is first sent. 1472 1. "Neutral" results could be given for IP addresses that may be 1473 forwarders, instead of "Fail" results. For example: 1475 "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all" 1477 This would cause a lookup on an anti-spam DNS blocklist 1478 (DNSBL) and cause a result of "Fail" only for e-mail coming 1479 from listed sources. All other e-mail, including e-mail sent 1480 through forwarders, would receive a "Neutral" result. By 1481 checking the DNSBL after the known good sources, problems 1482 with incorrect listing on the DNSBL are greatly reduced. 1484 2. The "MAIL FROM" identity could have additional information in 1485 the localpart that cryptographically identifies the mail as 1486 coming from an authorized source. In this case, such an SPF 1487 record could be used: 1489 "v=spf1 mx exists:%{l}._spf_verify.%{d} -all" 1491 Then, a specialized DNS server can be set up to serve the 1492 _spf_verify subdomain which validates the localpart. While 1493 this requires an extra DNS lookup, this only happens when the 1494 e-mail would otherwise be rejected as not coming from a known 1495 good source. 1497 Note that due to the 63 character limit for domain labels, 1498 this approach only works reliably if the localpart signature 1499 scheme is guaranteed either to only produce localparts with a 1500 maximum of 63 characters or to gracefully handle truncated 1501 localparts. 1503 3. Similarly, a specialized DNS server could be set up that will 1504 rate-limit the e-mail coming from unexpected IP addresses. 1506 "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all" 1508 4. SPF allows the creation of per-user policies for special 1509 cases. For example, the following SPF record and appropriate 1510 wildcard DNS records can be used: 1512 "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}" 1514 2. The middle, when e-mail is forwarded. 1516 1. Forwarding services can solve the problem by rewriting the 1517 "MAIL FROM" to be in their own domain. This means that mail 1518 bounced from the external mailbox will have to be re-bounced 1519 by the forwarding service. Various schemes to do this exist 1520 though they vary widely in complexity and resource 1521 requirements on the part of the forwarding service. 1523 2. Several popular MTAs can be forced from "alias" semantics to 1524 "mailing list" semantics by configuring an additional alias 1525 with "owner-" prepended to the original alias name (e.g. an 1526 alias of "friends: george@example.com, fred@example.org" 1527 would need another alias of the form "owner-friends: 1528 localowner"). 1530 3. The end, when e-mail is received. 1532 1. If the owner of the external mailbox wishes to trust the 1533 forwarding service, they can direct the external mailbox's 1534 MTA to skip SPF tests when the client host belongs to the 1535 forwarding service. 1537 2. Tests against other identities, such as the "HELO" identity, 1538 may be used to override a failed test against the "MAIL FROM" 1539 identity. 1541 3. For larger domains, it may not be possible to have a complete 1542 or accurate list of forwarding services used by the owners of 1543 the domain's mailboxes. In such cases, whitelists of 1544 generally-recognized forwarding services could be employed. 1546 9.4. Mail Services 1548 Service providers that offer mail services to third-party domains, 1549 such as sending of bulk mail, may have to adjust their setup in light 1550 of the authorization check described in this document. If the "MAIL 1551 FROM" identity used for such e-mail uses the domain of the service 1552 provider, then the provider needs only to ensure that their sending 1553 host is authorized by their own SPF record, if any. 1555 If the "MAIL FROM" identity does not use the mail service provider's 1556 domain, then extra care must be taken. The SPF record format has 1557 several options for the third party domain to authorize the service 1558 provider's MTAs to send mail on its behalf. For mail service 1559 providers, such as ISPs, that have a wide variety of customers using 1560 the same MTA, steps should be taken to prevent cross-customer forgery 1561 (see Section 10.4). 1563 9.5. MTA Relays 1565 The authorization check generally precludes the use of arbitrary MTA 1566 relays between sender and receiver of an e-mail message. 1568 Within an organization, MTA relays can be effectively deployed. 1569 However, for purposes of this document, such relays are effectively 1570 transparent. The SPF authorization check is a check between border 1571 MTAs of different domains. 1573 For mail senders, this means that published SPF records must 1574 authorize any MTAs that actually send across the Internet. Usually, 1575 these are just the border MTAs as internal MTAs simply forward mail 1576 to these MTAs for delivery. 1578 Mail receivers will generally want to perform the authorization check 1579 at the border MTAs, specifically including all secondary MXes. This 1580 allows mail that fails to be rejected during the SMTP session rather 1581 than bounced. Internal MTAs then do not perform the authorization 1582 test. To perform the authorization test other than at the border, 1583 the host that first transferred the message to the organization must 1584 be determined, which can be difficult to extract from headers. 1585 Testing other than at the border is not recommended. 1587 10. Security Considerations 1589 10.1. Processing Limits 1591 As with most aspects of e-mail, there are a number of ways that 1592 malicious parties could use the protocol as an avenue for a Denial- 1593 of-Service (DoS) attack. The processing limits outlined here are 1594 designed to prevent attacks such as: 1596 o A malicious party could create an SPF record with many references 1597 to a victim's domain and send many e-mails to different SPF 1598 clients; those SPF clients would then create a DoS attack. In 1599 effect, the SPF clients are being used to amplify the attacker's 1600 bandwidth by using fewer bytes in the SMTP session than are used 1601 by the DNS queries. Using SPF clients also allows the attacker to 1602 hide the true source of the attack. 1604 o While implementations of check_host() are supposed to limit the 1605 number of DNS lookups, malicious domains could publish records 1606 that exceed these limits in an attempt to waste computation effort 1607 at their targets when they send them mail. Malicious domains 1608 could also design SPF records that cause particular 1609 implementations to use excessive memory or CPU usage, or to 1610 trigger bugs. 1612 o Malicious parties could send a large volume of mail purporting to 1613 come from the intended target to a wide variety of legitimate mail 1614 hosts. These legitimate machines would then present a DNS load on 1615 the target as they fetched the relevant records. 1617 Of these, the case of a third party referenced in the SPF record is 1618 the easiest for a DoS attack to effectively exploit. As a result, 1619 limits that may seem reasonable for an individual mail server can 1620 still allow an unreasonable amount of bandwidth amplification. 1621 Therefore the processing limits need to be quite low. 1623 SPF implementations MUST limit the number of mechanisms and modifiers 1624 that do DNS lookups to at most 10 per SPF check, including any 1625 lookups caused by the use of the "include" mechanism or the 1626 "redirect" modifier. If this number is exceeded during a check, a 1627 PermError MUST be returned. The "include", "a", "mx", "ptr", and 1628 "exists" mechanisms as well as the "redirect" modifier do count 1629 against this limit. The "all", "ip4" and "ip6" mechanisms do not 1630 require DNS lookups and therefore do not count against this limit. 1631 The "exp" modifier does not count against this limit because the DNS 1632 lookup to fetch the explanation string occurs after the SPF record 1633 has been evaluated. 1635 When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, 1636 there MUST be a limit of no more than 10 MX or PTR RRs looked up and 1637 checked. 1639 SPF implementations SHOULD limit the total amount of data obtained 1640 from the DNS queries. For example, when DNS over TCP or EDNS0 are 1641 available, there may need to be an explicit limit to how much data 1642 will be accepted to prevent excessive bandwidth usage or memory 1643 usage, and DoS attacks. 1645 MTAs or other processors MAY also impose a limit on the maximum 1646 amount of elapsed time to evaluate check_host(). Such a limit SHOULD 1647 allow at least 20 seconds. If such a limit is exceeded, the result 1648 of authorization SHOULD be "TempError". 1650 Domains publishing records SHOULD try to keep the number of "include" 1651 mechanisms and chained "redirect" modifiers to a minimum. Domains 1652 SHOULD also try to minimize the amount of other DNS information 1653 needed to evaluate a record. This can be done by choosing directives 1654 that require less DNS information and placing lower-cost mechanisms 1655 earlier in the SPF record. 1657 For example, consider a domain set up as: 1659 example.com. IN MX 10 mx.example.com. 1660 mx.example.com. IN A 192.0.2.1 1661 a.example.com. IN TXT "v=spf1 mx:example.com -all" 1662 b.example.com. IN TXT "v=spf1 a:mx.example.com -all" 1663 c.example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all" 1665 Evaluating check_host() for the domain "a.example.com" requires the 1666 MX records for "example.com", and then the A records for the listed 1667 hosts. Evaluating for "b.example.com" only requires the A records. 1668 Evaluating for "c.example.com" requires none. 1670 However, there may be administrative considerations: using "a" over 1671 "ip4" allows hosts to be renumbered easily. Using "mx" over "a" 1672 allows the set of mail hosts to be changed easily. 1674 10.2. SPF-Authorized E-Mail May Be UBE 1676 The "MAIL FROM" and "HELO" identity authorizations must not be 1677 construed to provide more assurance than they do. It is entirely 1678 possible for a malicious sender to inject a message using their own 1679 domain in the identities used by SPF, to have that domain's SPF 1680 record authorize the sending host, and yet the message content can 1681 easily claim other identities in the headers. Unless the user or the 1682 MUA takes care to note that the authorized identity does not match 1683 the other more commonly-presented identities (such as the From: 1684 header), the user may be lulled into a false sense of security. 1686 10.3. Spoofed DNS and IP Data 1688 There are two aspects of this protocol that malicious parties could 1689 exploit to undermine the validity of the check_host() function: 1691 o The evaluation of check_host() relies heavily on DNS. A malicious 1692 attacker could attack the DNS infrastructure and cause 1693 check_host() to see spoofed DNS data, and then return incorrect 1694 results. This could include returning "Pass" for an value 1695 where the actual domain's record would evaluate to "Fail". See 1696 [RFC3833] for a description of the DNS weaknesses. 1698 o The client IP address, , is assumed to be correct. A 1699 malicious attacker could spoof TCP sequence numbers to make mail 1700 appear to come from a permitted host for a domain that the 1701 attacker is impersonating. 1703 10.4. Cross-User Forgery 1705 By definition, SPF policies just map domain names to sets of 1706 authorized MTAs, not whole e-mail addresses to sets of authorized 1707 users. Although the "l" macro (Section 8) provides a limited way to 1708 define individual sets of authorized MTAs for specific e-mail 1709 addresses, it is generally impossible to verify, through SPF, the use 1710 of specific e-mail addresses by individual users of the same MTA. 1712 It is up to mail services and their MTAs to directly prevent cross- 1713 user forgery: based on SMTP AUTH ([RFC2554]), users should be 1714 restricted to using only those e-mail addresses that are actually 1715 under their control (see [I-D.gellens-submit-bis] section 6.1). 1716 Another means to verify the identity of individual users is message 1717 cryptography such as PGP ([RFC2440]) or S/MIME ([RFC3851]). 1719 10.5. Untrusted Information Sources 1721 SPF uses information supplied by third parties, such as the "HELO" 1722 domain name, the "MAIL FROM" address, and SPF records. This 1723 information is then passed to the receiver in the Received-SPF: mail 1724 headers and possibly returned to the client MTA in the form of an 1725 SMTP rejection message. This information must be checked for invalid 1726 characters and excessively long lines. 1728 When the authorization check fails, an explanation string may be 1729 included in the reject response. Both the sender and the rejecting 1730 receiver need to be aware that the explanation was determined by the 1731 publisher of the SPF record checked and, in general, not the 1732 receiver. The explanation may contain malicious URLs, or it may be 1733 offensive or misleading. 1735 This is probably less of a concern than it may initially seem since 1736 such messages are returned to the sender, and the explanation strings 1737 come from the sender policy published by the domain in the identity 1738 claimed by that very sender. As long as the DSN is not redirected to 1739 someone other than the actual sender, the only people who see 1740 malicious explanation strings are people whose messages claim to be 1741 from domains that publish such strings in their SPF records. In 1742 practice DSNs can be misdirected, such as when an MTA accepts an 1743 e-mail and then later generates a DSN to a forged address, or when an 1744 e-mail forwarder does not direct the DSN back to the original sender. 1746 10.6. Privacy Exposure 1748 Checking SPF records causes DNS queries to be sent to the domain 1749 owner. These DNS queries, especially if they are caused by the 1750 "exists" mechanism, can contain information about who is sending 1751 e-mail and likely to which MTA the e-mail is being sent to. This can 1752 introduce some privacy concerns, which may be more or less of an 1753 issue depending on local laws and the relationship between the domain 1754 owner and the person sending the e-mail. 1756 11. Contributors and Acknowledgements 1758 This document is largely based on the work of Meng Weng Wong and Mark 1759 Lentczner. While, as this section acknowledges, many people have 1760 contributed to this document, a very large portion of the writing and 1761 editing are due to Meng and Mark. 1763 This design owes a debt of parentage to [RMX] by Hadmut Danisch and 1764 to [DMP] by Gordon Fecyk. The idea of using a DNS record to check 1765 the legitimacy of an e-mail address traces its ancestry farther back 1766 through messages on the namedroppers mailing list by Paul Vixie 1767 [Vixie] (based on suggestion by Jim Miller) and by David Green 1768 [Green]. 1770 Philip Gladstone contributed the concept of macros to the 1771 specification, multiplying the expressiveness of the language and 1772 making per-user and per-IP lookups possible. 1774 The authors would also like to thank the literally hundreds of 1775 individuals who have participated in the development of this design. 1776 They are far too numerous to name, but they include: 1778 The folks on the spf-discuss mailing list. 1779 The folks on the SPAM-L mailing list. 1780 The folks on the IRTF ASRG mailing list. 1781 The folks on the IETF MARID mailing list. 1782 The folks on #perl. 1784 12. IANA Considerations 1786 12.1. The SPF DNS Record Type 1788 The IANA needs to assign a new Resource Record Type and Qtype from 1789 the DNS Parameters Registry for the SPF RR type. 1791 12.2. The Received-SPF mail header 1793 Per [RFC3864], the "Received-SPF:" header field is added to the IANA 1794 Permanent Message Header Field Registry. The following is the 1795 registration template: 1797 Header field name: Received-SPF 1798 Applicable protocol: mail ([RFC2822]) 1799 Status: standard 1800 (Note to RFC Editor: Replace the status with the final 1801 determination by the IESG) 1802 Author/Change controller: IETF 1803 Specification document(s): this Internet Draft 1804 (Note to RFC Editor: Replace this with RFC YYYY (RFC number of 1805 this spec)) 1806 Related information: 1807 Requesting SPF Council review of any proposed changes and 1808 additions to this field is recommended. For information about SPF 1809 Council see http://spf.mehnle.net/ 1811 13. References 1813 13.1 Normative References 1815 [RFC1035] Mockapetris, P., "Domain names - implementation and 1816 specification", STD 13, RFC 1035, November 1987. 1818 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1819 and Support", STD 3, RFC 1123, October 1989. 1821 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1822 Requirement Levels", BCP 14, RFC 2119, March 1997. 1824 [I-D.crocker-abnf-rfc2234bis] 1825 Crocker, D. and P. Overell, "Augmented BNF for Syntax 1826 Specifications: ABNF", draft-crocker-abnf-rfc2234bis-00 1827 (work in progress), March 2005. 1829 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1830 April 2001. 1832 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1833 April 2001. 1835 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 1836 for Delivery Status Notifications", RFC 3464, 1837 January 2003. 1839 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 1840 (IPv6) Addressing Architecture", RFC 3513, April 2003. 1842 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1843 Procedures for Message Header Fields", BCP 90, RFC 3864, 1844 September 2004. 1846 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1847 Resource Identifier (URI): Generic Syntax", STD 66, 1848 RFC 3986, January 2005. 1850 [US-ASCII] 1851 American National Standards Institute (formerly United 1852 States of America Standards Institute), "USA Code for 1853 Information Interchange, X3.4", 1968. 1855 ANSI X3.4-1968 has been replaced by newer versions with 1856 slight modifications, but the 1968 version remains 1857 definitive for the Internet. 1859 13.2 Informative References 1861 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1862 STD 13, RFC 1034, November 1987. 1864 [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, 1865 August 1996. 1867 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 1868 "OpenPGP Message Format", RFC 2440, November 1998. 1870 [I-D.gellens-submit-bis] 1871 Gellens, R. and J. Klensin, "Message Submission for Mail", 1872 draft-gellens-submit-bis-02 (work in progress), 1873 April 2005. 1875 [RFC2554] Myers, J., "SMTP Service Extension for Authentication", 1876 RFC 2554, March 1999. 1878 [RFC3696] Klensin, J., "Application Techniques for Checking and 1879 Transformation of Names", RFC 3696, February 2004. 1881 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 1882 Name System (DNS)", RFC 3833, August 2004. 1884 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1885 Extensions (S/MIME) Version 3.1 Message Specification", 1886 RFC 3851, July 2004. 1888 [RMX] Danish, H., "The RMX DNS RR Type for light weight sender 1889 authentication", October 2003. 1891 Work In Progress 1893 [DMP] Fecyk, G., "Designated Mailers Protocol", December 2003. 1895 Work In Progress 1897 [Vixie] Vixie, P., "Repudiating MAIL FROM", 2002. 1899 [Green] Green, D., "Domain-Authorized SMTP Mail", 2002. 1901 Appendix A. Collected ABNF 1903 This section is normative and any discrepancies with the ABNF 1904 fragments in the preceding text are to be resolved in favor of this 1905 grammar. 1907 See [I-D.crocker-abnf-rfc2234bis] for ABNF notation. Please note 1908 that as per this ABNF definition, literal text strings (those in 1909 quotes) are case-insensitive. Hence, "mx" matches "mx", "MX", "mX" 1910 and "Mx". 1912 record = version terms *SP 1913 version = "v=spf1" 1915 terms = *( 1*SP ( directive / modifier ) ) 1917 directive = [ qualifier ] mechanism 1918 qualifier = "+" / "-" / "?" / "~" 1919 mechanism = ( all / include 1920 / A / MX / PTR / IP4 / IP6 / exists ) 1922 all = "all" 1923 include = "include" ":" domain-spec 1924 A = "a" [ ":" domain-spec ] [ dual-cidr-length ] 1925 MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] 1926 PTR = "ptr" [ ":" domain-spec ] 1927 IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] 1928 IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] 1929 exists = "exists" ":" domain-spec 1931 modifier = redirect / explanation / unknown-modifier 1932 redirect = "redirect" "=" domain-spec 1933 explanation = "exp" "=" domain-spec 1934 unknown-modifier = name "=" macro-string 1936 ip4-cidr-length = "/" 1*DIGIT 1937 ip6-cidr-length = "/" 1*DIGIT 1938 dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] 1940 ip4-network = qnum "." qnum "." qnum "." qnum 1941 qnum = DIGIT ; 0-9 1942 / %x31-39 DIGIT ; 10-99 1943 / "1" 2DIGIT ; 100-199 1944 / "2" %x30-34 DIGIT ; 200-249 1945 / "25" %x30-35 ; 250-255 1946 ; conventional dotted quad notation. e.g. 192.0.2.0 1947 ip6-network = 1948 ; e.g. 2001:DB8::CD30 1950 domain-spec = macro-string domain-end 1951 domain-end = ( "." toplabel ) / macro-expand 1952 toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum 1953 ; LDH rule (See [RFC3696]) 1954 alphanum = ALPHA / DIGIT 1956 explain-string = *( macro-string / SP ) 1958 macro-string = *( macro-expand / macro-literal ) 1959 macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) 1960 / "%%" / "%_" / "%-" 1961 macro-literal = %x21-24 / %x26-7E 1962 ; visible characters except "%" 1963 macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / 1964 "c" / "r" / "t" 1965 transformers = *DIGIT [ "r" ] 1966 delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" 1968 name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) 1970 header = "Received-SPF:" [CFWS] result FWS [comment FWS] 1971 [ key-value-list ] CRLF 1973 result = "Pass" / "Fail" / "SoftFail" / "Neutral" / 1974 "None" / "TempError" / "PermError" 1976 key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) 1977 [";"] 1979 key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) 1981 key = "client-ip" / "envelope-from" / "helo" / 1982 "problem" / "receiver" / "identity" / 1983 mechanism / "x-" name / name 1985 identity = "mailfrom" ; for the "MAIL FROM" identity 1986 / "helo" ; for the "HELO" identity 1987 / name ; other identities 1989 dot-atom = 1990 quoted-string = 1991 comment = 1992 CFWS = 1993 FWS = 1994 CRLF = 1996 Appendix B. Extended Examples 1998 These examples are based on the following DNS setup: 2000 ; A domain with two mail servers, two hosts 2001 ; and two servers at the domain name 2002 $ORIGIN example.com. 2003 @ MX 10 mail-a 2004 MX 20 mail-b 2005 A 192.0.2.10 2006 A 192.0.2.11 2007 amy A 192.0.2.65 2008 bob A 192.0.2.66 2009 mail-a A 192.0.2.129 2010 mail-b A 192.0.2.130 2011 www CNAME example.com. 2013 ; A related domain 2014 $ORIGIN example.org. 2015 @ MX 10 mail-c 2016 mail-c A 192.0.2.140 2018 ; The reverse IP for those addresses 2019 $ORIGIN 2.0.192.in-addr.arpa. 2020 10 PTR example.com. 2021 11 PTR example.com. 2022 65 PTR amy.example.com. 2023 66 PTR bob.example.com. 2024 129 PTR mail-a.example.com. 2025 130 PTR mail-b.example.com. 2026 140 PTR mail-c.example.org. 2028 ; A rogue reverse IP domain that claims to be 2029 ; something it's not 2030 $ORIGIN 0.0.10.in-addr.arpa. 2031 4 PTR bob.example.com. 2033 B.1. Simple Examples 2035 These examples show various possible published records for 2036 example.com and which values if would cause check_host() to 2037 return "Pass". Note that is "example.com". 2039 v=spf1 +all 2040 -- any passes 2042 v=spf1 a -all 2043 -- hosts 192.0.2.10 and 192.0.2.11 pass 2045 v=spf1 a:example.org -all 2046 -- no sending hosts pass since example.org has no A records 2048 v=spf1 mx -all 2049 -- sending hosts 192.0.2.129 and 192.0.2.130 pass 2051 v=spf1 mx:example.org -all 2052 -- sending host 192.0.2.140 passes 2054 v=spf1 mx mx:example.org -all 2055 -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass 2057 v=spf1 mx/30 mx:example.org/30 -all 2058 -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes 2060 v=spf1 ptr -all 2061 -- sending host 192.0.2.65 passes (reverse DNS is valid and is in 2062 example.com) 2063 -- sending host 192.0.2.140 fails (reverse DNS is valid, but not 2064 in example.com) 2065 -- sending host 10.0.0.4 fails (reverse IP is not valid) 2067 v=spf1 ip4:192.0.2.128/28 -all 2068 -- sending host 192.0.2.65 fails 2069 -- sending host 192.0.2.129 passes 2071 B.2. Multiple Domain Example 2073 These examples show the effect of related records: 2075 example.org: "v=spf1 include:example.com include:example.net -all" 2077 This record would be used if mail from example.org actually came 2078 through servers at example.com and example.net. Example.org's 2079 designated servers are the union of example.com's and example.net's 2080 designated servers. 2082 la.example.org: "v=spf1 redirect=example.org" 2083 ny.example.org: "v=spf1 redirect=example.org" 2084 sf.example.org: "v=spf1 redirect=example.org" 2086 These records allow a set of domains that all use the same mail 2087 system to make use of that mail system's record. In this way, only 2088 the mail system's record needs to be updated when the mail setup 2089 changes. These domains' records never have to change. 2091 B.3. DNSBL Style Example 2093 Imagine that, in addition to the domain records listed above, there 2094 are these: 2096 $ORIGIN _spf.example.com. 2097 mary.mobile-users A 127.0.0.2 2098 fred.mobile-users A 127.0.0.2 2099 15.15.168.192.joel.remote-users A 127.0.0.2 2100 16.15.168.192.joel.remote-users A 127.0.0.2 2102 The following records describe users at example.com who mail from 2103 arbitrary servers, or who mail from personal servers. 2105 example.com: 2107 v=spf1 mx 2108 include:mobile-users._spf.%{d} 2109 include:remote-users._spf.%{d} 2110 -all 2112 mobile-users._spf.example.com: 2114 v=spf1 exists:%{l1r+}.%{d} 2116 remote-users._spf.example.com: 2118 v=spf1 exists:%{ir}.%{l1r+}.%{d} 2120 B.4. Multiple Requirements Example 2122 Say that your sender policy requires that both the IP address is 2123 within a certain range and that the reverse DNS for the IP matches. 2124 This can be done several ways, including: 2126 example.com. SPF ( "v=spf1 " 2127 "-include:ip4._spf.%{d} " 2128 "-include:ptr._spf.%{d} " 2129 "+all" ) 2130 ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all" 2131 ptr._spf.example.com. SPF "v=spf1 -ptr +all" 2133 This example shows how the "-include" mechanism can be useful, how an 2134 SPF record that ends in "+all" can be very restrictive and the use of 2135 De Morgan's Law. 2137 Appendix C. Change Log 2139 RFC Editor Note: This section is to be removed during the final 2140 publication of the document. 2142 C.1. Changes in Version -02 2144 o The abstract notes that SPF-classic covers both the HELO and MAIL 2145 FROM identities. (ietf-822 review) 2147 o In section 2.3 "Publishing Authorization", it now makes it clear 2148 that publishing is optional. (ietf-smtp review) 2150 o The definition of the "SoftFail" result have been recast from 2151 Receiver Policy to Sender Policy. 2153 o The definitions of Neutral, Pass and PermError have been updated/ 2154 clarified to more correctly reflect the semantics of 2155 draft-mengwong-spf-01. 2157 o A note to the RFC editor was made indicating that the SPF DNS RR 2158 type number should be added to the draft once the IANA has made an 2159 allocation. 2161 o The ip4-network ABNF has been fixed to give the ABNF of the 2162 dotted-quad format, rather than just using words to explain it. 2164 o The ABNF for the Received-SPF header now shows that it ends with a 2165 CRLF. (ietf-822 review) 2167 o The new, optional, "scope" keyword-value pair has been renamed to 2168 "identity". 2170 o The "exp=" modifier no longer counts toward the DoS DNS lookup 2171 limits. 2173 o In section 10.5 "Untrusted Information Sources", the explanation 2174 about explanation strings going to only the sender has been fixed 2175 to note that, in some cases, it can go to other people. (ietf-822 2176 review) 2178 o Sections 3.1.2 and 3.1.3 were updated to make the distinction 2179 between "multiple TXT RRs" and "multiple strings within a TXT" 2180 clearer. (ietf-822 review) 2182 o A normative reference to US-ASCII has been added. 2184 o Text describing how to lookup and process the SPF records has been 2185 removed from section 3.1.1 "DNS Resource Record Types" and merged 2186 into similar text in sections 4.4 "Record Lookup" and 4.5 2187 "Selecting Records" 2189 o Section 4.5 "Selecting Records" has been updated to give an 2190 algorithm that says to return a PermError when it discovers that 2191 SPF and TXT records don't match. 2193 o In section 6.1 "redirect: Redirected Query", the semantics have 2194 been changed to specify a result of PermError instead of None in 2195 cases where the target domain does not have any SPF records. It 2196 makes no sense to return None, that is "no SPF records found", 2197 when SPF records were found. 2199 o In section 6.2 "exp: Explanation", it is explained that the record 2200 must be in US-ASCII due to requirements of RFC2821. 2202 o In section 6.2 "exp: Explanation", the duplicate warning about 2203 source being from a third party was deleted. 2205 o A note has been added to section 9.3.1.2 warning about domain 2206 labels being over 63 characters. 2208 o The "prefix" ABNF rule was renamed to "qualifier" to reflect the 2209 semantics of the rule, rather than the syntax. 2211 C.2. Changes in Version -01 2213 o IETF boilerplate was updated to BCP 79. 2215 o A version number was added to the title. (IESG review) 2217 o Many grammatical, typographical and spelling errors were 2218 corrected, along with rephrasing sentences to make the intent and 2219 meaning clearer. 2221 o Sections have been re-ordered in so that they conform to the 2222 instructions2authors.txt document. All required sections and 2223 arrangements are included, and only the "Security Considerations" 2224 section is not in the suggested order. Since the Security 2225 Considerations is such an important part of the spec, it has been 2226 moved before the Acknowledgement section. 2228 o The HELO identity checking has been changed from "MAY" to 2229 "RECOMMENDED". 2231 o The e-mail receiver policy definition on how to handle HELO 2232 checking was removed. It was copied incorrectly from 2233 draft-mengwong-spf-01, changing its meaning. 2235 o A note was added that when changing SPF records, there needs to be 2236 a transitional period to prevent incorrect results. 2238 o The RECOMMENDATION not to use other identities with version 1 SPF 2239 records has been clarified. Example cases where checking other 2240 identities will cause incorrect results have been cited. (IESG 2241 review) 2243 o The "zone cut" method of determining if there is an SPF record at 2244 the top of the zone has been removed. It wasn't implemented very 2245 often and could not always be easily done. (IESG/namedroppers' 2246 review) 2248 o A note was added that receivers should consider rejecting e-mail 2249 for non-existent domains in order to prevent circumvention of SPF 2250 policies. This is due to the remove of "zone cuts". 2251 (namedroppers' review) 2253 o The RECOMMENDATION to perform SPF checks during the SMTP session 2254 has been clarified and strengthened. 2256 o Note added about the consequences of treating "Neutral" results 2257 worse than "None". 2259 o The suggested e-mail receiver policy when a "PermError" is 2260 encountered has been changed to be, effectively, the same 2261 semantics as were in draft-mengwong-spf-01. (MAAWG review) 2263 o ABNF cleaned up to pass Bill Fenner's checker and not just the one 2264 at http://www.apps.ietf.org/abnf.html 2266 o A few host names/IP addresses were fixed to use appropriate ones 2267 for I-Ds. 2269 o A definition of what to should be done if there are syntax errors 2270 in the explanation string was added. (E.g. use the default.) 2272 o Section 10 "Security Considerations" has been broken up into 2273 subsections and reorganized. 2275 o Section 7.1 "Process Limits" has been merged into the similar 2276 language in the "Security Considerations" section. 2278 o The ABNF for the Received-SPF e-mail header has been made to be 2279 more compatible with draft-mengwong-spf-01. It was fixed to 2280 require whitespace when needed and to show where the suggested 2281 comment should be added to the header. 2283 o The IANA Considerations section now has the required information 2284 to document the Received-SPF header. 2286 o A new, optional, "scope" keyword has added to the Received-SPF 2287 header. 2289 o The non-normative Section 9.3 "Forwarding Services and Aliases" 2290 has been expanded to more thoroughly cover the subject. 2292 o New Security Considerations sections on "Privacy Exposure" and 2293 "Cross-User Forgery" have been added. 2295 o A new example of an SPF policy with a non-obvious implementation 2296 has been added. 2298 Authors' Addresses 2300 Meng Weng Wong 2301 Singapore 2303 Email: mengwong+spf@pobox.com 2304 URI: http://spf.pobox.com/ 2306 Wayne Schlitt 2307 4615 Meredeth #9 2308 Lincoln Nebraska, NE 68506 2309 United States of America 2311 Email: wayne@schlitt.net 2312 URI: http://www.schlitt.net/spf/ 2314 Intellectual Property Statement 2316 The IETF takes no position regarding the validity or scope of any 2317 Intellectual Property Rights or other rights that might be claimed to 2318 pertain to the implementation or use of the technology described in 2319 this document or the extent to which any license under such rights 2320 might or might not be available; nor does it represent that it has 2321 made any independent effort to identify any such rights. Information 2322 on the procedures with respect to rights in RFC documents can be 2323 found in BCP 78 and BCP 79. 2325 Copies of IPR disclosures made to the IETF Secretariat and any 2326 assurances of licenses to be made available, or the result of an 2327 attempt made to obtain a general license or permission for the use of 2328 such proprietary rights by implementers or users of this 2329 specification can be obtained from the IETF on-line IPR repository at 2330 http://www.ietf.org/ipr. 2332 The IETF invites any interested party to bring to its attention any 2333 copyrights, patents or patent applications, or other proprietary 2334 rights that may cover technology that may be required to implement 2335 this standard. Please address the information to the IETF at 2336 ietf-ipr@ietf.org. 2338 Disclaimer of Validity 2340 This document and the information contained herein are provided on an 2341 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2342 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2343 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2344 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2345 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2346 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2348 Copyright Statement 2350 Copyright (C) The Internet Society (2005). This document is subject 2351 to the rights, licenses and restrictions contained in BCP 78, and 2352 except as set forth therein, the authors retain all their rights. 2354 Acknowledgment 2356 Funding for the RFC Editor function is currently provided by the 2357 Internet Society.