diff options
Diffstat (limited to 'doc/rfc/rfc4408.txt')
| -rw-r--r-- | doc/rfc/rfc4408.txt | 2691 |
1 files changed, 2691 insertions, 0 deletions
diff --git a/doc/rfc/rfc4408.txt b/doc/rfc/rfc4408.txt new file mode 100644 index 0000000..bc1b3f5 --- /dev/null +++ b/doc/rfc/rfc4408.txt @@ -0,0 +1,2691 @@ + + + + + + +Network Working Group M. Wong +Request for Comments: 4408 W. Schlitt +Category: Experimental April 2006 + + + Sender Policy Framework (SPF) for + Authorizing Use of Domains in E-Mail, Version 1 + +Status of This Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +IESG Note + + The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) + are published simultaneously as Experimental RFCs, although there is + no general technical consensus and efforts to reconcile the two + approaches have failed. As such, these documents have not received + full IETF review and are published "AS-IS" to document the different + approaches as they were considered in the MARID working group. + + The IESG takes no position about which approach is to be preferred + and cautions the reader that there are serious open issues for each + approach and concerns about using them in tandem. The IESG believes + that documenting the different approaches does less harm than not + documenting them. + + Note that the Sender ID experiment may use DNS records that may have + been created for the current SPF experiment or earlier versions in + this set of experiments. Depending on the content of the record, + this may mean that Sender-ID heuristics would be applied incorrectly + to a message. Depending on the actions associated by the recipient + with those heuristics, the message may not be delivered or may be + discarded on receipt. + + Participants relying on Sender ID experiment DNS records are warned + that they may lose valid messages in this set of circumstances. + aParticipants publishing SPF experiment DNS records should consider + the advice given in section 3.4 of RFC 4406 and may wish to publish + both v=spf1 and spf2.0 records to avoid the conflict. + + + + +Wong & Schlitt Experimental [Page 1] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + Participants in the Sender-ID experiment need to be aware that the + way Resent-* header fields are used will result in failure to receive + legitimate email when interacting with standards-compliant systems + (specifically automatic forwarders which comply with the standards by + not adding Resent-* headers, and systems which comply with RFC 822 + but have not yet implemented RFC 2822 Resent-* semantics). It would + be inappropriate to advance Sender-ID on the standards track without + resolving this interoperability problem. + + The community is invited to observe the success or failure of the two + approaches during the two years following publication, in order that + a community consensus can be reached in the future. + +Abstract + + E-mail on the Internet can be forged in a number of ways. In + particular, existing protocols place no restriction on what a sending + host can use as the reverse-path of a message or the domain given on + the SMTP HELO/EHLO commands. This document describes version 1 of + the Sender Policy Framework (SPF) protocol, whereby a domain may + explicitly authorize the hosts that are allowed to use its domain + name, and a receiving host may check such authorization. + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Protocol Status ............................................4 + 1.2. Terminology ................................................5 + 2. Operation .......................................................5 + 2.1. The HELO Identity ..........................................5 + 2.2. The MAIL FROM Identity .....................................5 + 2.3. Publishing Authorization ...................................6 + 2.4. Checking Authorization .....................................6 + 2.5. Interpreting the Result ....................................7 + 2.5.1. None ................................................8 + 2.5.2. Neutral .............................................8 + 2.5.3. Pass ................................................8 + 2.5.4. Fail ................................................8 + 2.5.5. SoftFail ............................................9 + 2.5.6. TempError ...........................................9 + 2.5.7. PermError ...........................................9 + 3. SPF Records .....................................................9 + 3.1. Publishing ................................................10 + 3.1.1. DNS Resource Record Types ..........................10 + 3.1.2. Multiple DNS Records ...............................11 + 3.1.3. Multiple Strings in a Single DNS record ............11 + 3.1.4. Record Size ........................................11 + 3.1.5. Wildcard Records ...................................11 + + + +Wong & Schlitt Experimental [Page 2] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + 4. The check_host() Function ......................................12 + 4.1. Arguments .................................................12 + 4.2. Results ...................................................13 + 4.3. Initial Processing ........................................13 + 4.4. Record Lookup .............................................13 + 4.5. Selecting Records .........................................13 + 4.6. Record Evaluation .........................................14 + 4.6.1. Term Evaluation ....................................14 + 4.6.2. Mechanisms .........................................15 + 4.6.3. Modifiers ..........................................15 + 4.7. Default Result ............................................16 + 4.8. Domain Specification ......................................16 + 5. Mechanism Definitions ..........................................16 + 5.1. "all" .....................................................17 + 5.2. "include" .................................................18 + 5.3. "a" .......................................................19 + 5.4. "mx" ......................................................20 + 5.5. "ptr" .....................................................20 + 5.6. "ip4" and "ip6" ...........................................21 + 5.7. "exists" ..................................................22 + 6. Modifier Definitions ...........................................22 + 6.1. redirect: Redirected Query ................................23 + 6.2. exp: Explanation ..........................................23 + 7. The Received-SPF Header Field ..................................25 + 8. Macros .........................................................27 + 8.1. Macro Definitions .........................................27 + 8.2. Expansion Examples ........................................30 + 9. Implications ...................................................31 + 9.1. Sending Domains ...........................................31 + 9.2. Mailing Lists .............................................32 + 9.3. Forwarding Services and Aliases ...........................32 + 9.4. Mail Services .............................................34 + 9.5. MTA Relays ................................................34 + 10. Security Considerations .......................................35 + 10.1. Processing Limits ........................................35 + 10.2. SPF-Authorized E-Mail May Contain Other False + Identities ...............................................37 + 10.3. Spoofed DNS and IP Data ..................................37 + 10.4. Cross-User Forgery .......................................37 + 10.5. Untrusted Information Sources ............................38 + 10.6. Privacy Exposure .........................................38 + 11. Contributors and Acknowledgements .............................38 + 12. IANA Considerations ...........................................39 + 12.1. The SPF DNS Record Type ..................................39 + 12.2. The Received-SPF Mail Header Field .......................39 + 13. References ....................................................39 + 13.1. Normative References .....................................39 + 13.2. Informative References ...................................40 + + + +Wong & Schlitt Experimental [Page 3] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + Appendix A. Collected ABNF .......................................42 + Appendix B. Extended Examples ....................................44 + B.1. Simple Examples ..........................................44 + B.2. Multiple Domain Example ..................................45 + B.3. DNSBL Style Example ......................................46 + B.4. Multiple Requirements Example ............................46 + +1. Introduction + + The current E-Mail infrastructure has the property that any host + injecting mail into the mail system can identify itself as any domain + name it wants. Hosts can do this at a variety of levels: in + particular, the session, the envelope, and the mail headers. + Although this feature is desirable in some circumstances, it is a + major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam). + Furthermore, many domain name holders are understandably concerned + about the ease with which other entities may make use of their domain + names, often with malicious intent. + + This document defines a protocol by which domain owners may authorize + hosts to use their domain name in the "MAIL FROM" or "HELO" identity. + Compliant domain holders publish Sender Policy Framework (SPF) + records specifying which hosts are permitted to use their names, and + compliant mail receivers use the published SPF records to test the + authorization of sending Mail Transfer Agents (MTAs) using a given + "HELO" or "MAIL FROM" identity during a mail transaction. + + An additional benefit to mail receivers is that after the use of an + identity is verified, local policy decisions about the mail can be + made based on the sender's domain, rather than the host's IP address. + This is advantageous because reputation of domain names is likely to + be more accurate than reputation of host IP addresses. Furthermore, + if a claimed identity fails verification, local policy can take + stronger action against such E-Mail, such as rejecting it. + +1.1. Protocol Status + + SPF has been in development since the summer of 2003 and has seen + deployment beyond the developers beginning in December 2003. The + design of SPF slowly evolved until the spring of 2004 and has since + stabilized. There have been quite a number of forms of SPF, some + written up as documents, some submitted as Internet Drafts, and many + discussed and debated in development forums. + + The goal of this document is to clearly document the protocol defined + by earlier draft specifications of SPF as used in existing + implementations. This conception of SPF is sometimes called "SPF + Classic". It is understood that particular implementations and + + + +Wong & Schlitt Experimental [Page 4] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + deployments may differ from, and build upon, this work. It is hoped + that we have nonetheless captured the common understanding of SPF + version 1. + +1.2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + This document is concerned with the portion of a mail message + commonly called "envelope sender", "return path", "reverse path", + "bounce address", "2821 FROM", or "MAIL FROM". Since these terms are + either not well defined or often used casually, this document defines + the "MAIL FROM" identity in Section 2.2. Note that other terms that + may superficially look like the common terms, such as "reverse-path", + are used only with the defined meanings from normative documents. + +2. Operation + +2.1. The HELO Identity + + The "HELO" identity derives from either the SMTP HELO or EHLO command + (see [RFC2821]). These commands supply the SMTP client (sending + host) for the SMTP session. Note that requirements for the domain + presented in the EHLO or HELO command are not always clear to the + sending party, and SPF clients must be prepared for the "HELO" + identity to be malformed or an IP address literal. At the time of + this writing, many legitimate E-Mails are delivered with invalid HELO + domains. + + It is RECOMMENDED that SPF clients not only check the "MAIL FROM" + identity, but also separately check the "HELO" identity by applying + the check_host() function (Section 4) to the "HELO" identity as the + <sender>. + +2.2. The MAIL FROM Identity + + The "MAIL FROM" identity derives from the SMTP MAIL command (see + [RFC2821]). This command supplies the "reverse-path" for a message, + which generally consists of the sender mailbox, and is the mailbox to + which notification messages are to be sent if there are problems + delivering the message. + + [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in + RFC 2821). In this case, there is no explicit sender mailbox, and + such a message can be assumed to be a notification message from the + mail system itself. When the reverse-path is null, this document + + + +Wong & Schlitt Experimental [Page 5] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + defines the "MAIL FROM" identity to be the mailbox composed of the + localpart "postmaster" and the "HELO" identity (which may or may not + have been checked separately before). + + SPF clients MUST check the "MAIL FROM" identity. SPF clients check + the "MAIL FROM" identity by applying the check_host() function to the + "MAIL FROM" identity as the <sender>. + +2.3. Publishing Authorization + + An SPF-compliant domain MUST publish a valid SPF record as described + in Section 3. This record authorizes the use of the domain name in + the "HELO" and "MAIL FROM" identities by the MTAs it specifies. + + If domain owners choose to publish SPF records, it is RECOMMENDED + that they end in "-all", or redirect to other records that do, so + that a definitive determination of authorization can be made. + + Domain holders may publish SPF records that explicitly authorize no + hosts if mail should never originate using that domain. + + When changing SPF records, care must be taken to ensure that there is + a transition period so that the old policy remains valid until all + legitimate E-Mail has been checked. + +2.4. Checking Authorization + + A mail receiver can perform a set of SPF checks for each mail message + it receives. An SPF check tests the authorization of a client host + to emit mail with a given identity. Typically, such checks are done + by a receiving MTA, but can be performed elsewhere in the mail + processing chain so long as the required information is available and + reliable. At least the "MAIL FROM" identity MUST be checked, but it + is RECOMMENDED that the "HELO" identity also be checked beforehand. + + Without explicit approval of the domain owner, checking other + identities against SPF version 1 records is NOT RECOMMENDED because + there are cases that are known to give incorrect results. For + example, almost all mailing lists rewrite the "MAIL FROM" identity + (see Section 9.2), but some do not change any other identities in the + message. The scenario described in Section 9.3, sub-section 1.2, is + another example. Documents that define other identities should + define the method for explicit approval. + + It is possible that mail receivers will use the SPF check as part of + a larger set of tests on incoming mail. The results of other tests + may influence whether or not a particular SPF check is performed. + For example, finding the sending host's IP address on a local white + + + +Wong & Schlitt Experimental [Page 6] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + list may cause all other tests to be skipped and all mail from that + host to be accepted. + + When a mail receiver decides to perform an SPF check, it MUST use a + correctly-implemented check_host() function (Section 4) evaluated + with the correct parameters. Although the test as a whole is + optional, once it has been decided to perform a test it must be + performed as specified so that the correct semantics are preserved + between publisher and receiver. + + To make the test, the mail receiver MUST evaluate the check_host() + function with the arguments set as follows: + + <ip> - the IP address of the SMTP client that is emitting the + mail, either IPv4 or IPv6. + + <domain> - the domain portion of the "MAIL FROM" or "HELO" identity. + + <sender> - the "MAIL FROM" or "HELO" identity. + + Note that the <domain> argument may not be a well-formed domain name. + For example, if the reverse-path was null, then the EHLO/HELO domain + is used, with its associated problems (see Section 2.1). In these + cases, check_host() is defined in Section 4.3 to return a "None" + result. + + Although invalid, malformed, or non-existent domains cause SPF checks + to return "None" because no SPF record can be found, it has long been + the policy of many MTAs to reject E-Mail from such domains, + especially in the case of invalid "MAIL FROM". In order to prevent + the circumvention of SPF records, rejecting E-Mail from invalid + domains should be considered. + + Implementations must take care to correctly extract the <domain> from + the data given with the SMTP MAIL FROM command as many MTAs will + still accept such things as source routes (see [RFC2821], Appendix + C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). + These archaic features have been maliciously used to bypass security + systems. + +2.5. Interpreting the Result + + This section describes how software that performs the authorization + should interpret the results of the check_host() function. The + authorization check SHOULD be performed during the processing of the + SMTP transaction that sends the mail. This allows errors to be + returned directly to the sending MTA by way of SMTP replies. + + + + +Wong & Schlitt Experimental [Page 7] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + Performing the authorization after the SMTP transaction has finished + may cause problems, such as the following: (1) It may be difficult to + accurately extract the required information from potentially + deceptive headers; (2) legitimate E-Mail may fail because the + sender's policy may have since changed. + + Generating non-delivery notifications to forged identities that have + failed the authorization check is generally abusive and against the + explicit wishes of the identity owner. + +2.5.1. None + + A result of "None" means that no records were published by the domain + or that no checkable sender domain could be determined from the given + identity. The checking software cannot ascertain whether or not the + client host is authorized. + +2.5.2. Neutral + + The domain owner has explicitly stated that he cannot or does not + want to assert whether or not the IP address is authorized. A + "Neutral" result MUST be treated exactly like the "None" result; the + distinction exists only for informational purposes. Treating + "Neutral" more harshly than "None" would discourage domain owners + from testing the use of SPF records (see Section 9.1). + +2.5.3. Pass + + A "Pass" result means that the client is authorized to inject mail + with the given identity. The domain can now, in the sense of + reputation, be considered responsible for sending the message. + Further policy checks can now proceed with confidence in the + legitimate use of the identity. + +2.5.4. Fail + + A "Fail" result is an explicit statement that the client is not + authorized to use the domain in the given identity. The checking + software can choose to mark the mail based on this or to reject the + mail outright. + + If the checking software chooses to reject the mail during the SMTP + transaction, then it SHOULD use an SMTP reply code of 550 (see + [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification + (DSN) code (see [RFC3464]), in addition to an appropriate reply text. + The check_host() function may return either a default explanation + string or one from the domain that published the SPF records (see + Section 6.2). If the information does not originate with the + + + +Wong & Schlitt Experimental [Page 8] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + checking software, it should be made clear that the text is provided + by the sender's domain. For example: + + 550-5.7.1 SPF MAIL FROM check failed: + 550-5.7.1 The domain example.com explains: + 550 5.7.1 Please see http://www.example.com/mailpolicy.html + +2.5.5. SoftFail + + A "SoftFail" result should be treated as somewhere between a "Fail" + and a "Neutral". The domain believes the host is not authorized but + is not willing to make that strong of a statement. Receiving + software SHOULD NOT reject the message based solely on this result, + but MAY subject the message to closer scrutiny than normal. + + The domain owner wants to discourage the use of this host and thus + desires limited feedback when a "SoftFail" result occurs. For + example, the recipient's Mail User Agent (MUA) could highlight the + "SoftFail" status, or the receiving MTA could give the sender a + message using a technique called "greylisting" whereby the MTA can + issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the + first time the message is received, but accept it the second time. + +2.5.6. TempError + + A "TempError" result means that the SPF client encountered a + transient error while performing the check. Checking software can + choose to accept or temporarily reject the message. If the message + is rejected during the SMTP transaction for this reason, the software + SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN + code. + +2.5.7. PermError + + A "PermError" result means that the domain's published records could + not be correctly interpreted. This signals an error condition that + requires manual intervention to be resolved, as opposed to the + TempError result. Be aware that if the domain owner uses macros + (Section 8), it is possible that this result is due to the checked + identities having an unexpected format. + +3. SPF Records + + An SPF record is a DNS Resource Record (RR) that declares which hosts + are, and are not, authorized to use a domain name for the "HELO" and + "MAIL FROM" identities. Loosely, the record partitions all hosts + into permitted and not-permitted sets (though some hosts might fall + into neither category). + + + +Wong & Schlitt Experimental [Page 9] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + The SPF record is a single string of text. An example record is the + following: + + v=spf1 +mx a:colo.example.com/28 -all + + This record has a version of "spf1" and three directives: "+mx", + "a:colo.example.com/28" (the + is implied), and "-all". + +3.1. Publishing + + Domain owners wishing to be SPF compliant must publish SPF records + for the hosts that are used in the "MAIL FROM" and "HELO" identities. + The SPF records are placed in the DNS tree at the host name it + pertains to, not a subdomain under it, such as is done with SRV + records. This is the same whether the TXT or SPF RR type (see + Section 3.1.1) is used. + + The example above in Section 3 might be published via these lines in + a domain zone file: + + example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" + smtp-out.example.com. TXT "v=spf1 a -all" + + When publishing via TXT records, beware of other TXT records + published there for other purposes. They may cause problems with + size limits (see Section 3.1.4). + +3.1.1. DNS Resource Record Types + + This document defines a new DNS RR of type SPF, code 99. The format + of this type is identical to the TXT RR [RFC1035]. For either type, + the character content of the record is encoded as [US-ASCII]. + + It is recognized that the current practice (using a TXT record) is + not optimal, but it is necessary because there are a number of DNS + server and resolver implementations in common use that cannot handle + the new RR type. The two-record-type scheme provides a forward path + to the better solution of using an RR type reserved for this purpose. + + An SPF-compliant domain name SHOULD have SPF records of both RR + types. A compliant domain name MUST have a record of at least one + type. If a domain has records of both types, they MUST have + identical content. For example, instead of publishing just one + record as in Section 3.1 above, it is better to publish: + + example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all" + example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all" + + + + +Wong & Schlitt Experimental [Page 10] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + Example RRs in this document are shown with the TXT record type; + however, they could be published with the SPF type or with both + types. + +3.1.2. Multiple DNS Records + + A domain name MUST NOT have multiple records that would cause an + authorization check to select more than one record. See Section 4.5 + for the selection rules. + +3.1.3. Multiple Strings in a Single DNS record + + As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS + record (either TXT or SPF RR types) can be composed of more than one + string. If a published record contains multiple strings, then the + record MUST be treated as if those strings are concatenated together + without adding spaces. For example: + + IN TXT "v=spf1 .... first" "second string..." + + MUST be treated as equivalent to + + IN TXT "v=spf1 .... firstsecond string..." + + SPF or TXT records containing multiple strings are useful in + constructing records that would exceed the 255-byte maximum length of + a string within a single TXT or SPF RR record. + +3.1.4. Record Size + + The published SPF record for a given domain name SHOULD remain small + enough that the results of a query for it will fit within 512 octets. + This will keep even older DNS implementations from falling over to + TCP. Since the answer size is dependent on many things outside the + scope of this document, it is only possible to give this guideline: + If the combined length of the DNS name and the text of all the + records of a given type (TXT or SPF) is under 450 characters, then + DNS answers should fit in UDP packets. Note that when computing the + sizes for queries of the TXT format, one must take into account any + other TXT records published at the domain name. Records that are too + long to fit in a single UDP packet MAY be silently ignored by SPF + clients. + +3.1.5. Wildcard Records + + Use of wildcard records for publishing is not recommended. Care must + be taken if wildcard records are used. If a domain publishes + wildcard MX records, it may want to publish wildcard declarations, + + + +Wong & Schlitt Experimental [Page 11] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + subject to the same requirements and problems. In particular, the + declaration must be repeated for any host that has any RR records at + all, and for subdomains thereof. For example, the example given in + [RFC1034], Section 4.3.3, could be extended with the following: + + X.COM. MX 10 A.X.COM + X.COM. TXT "v=spf1 a:A.X.COM -all" + + *.X.COM. MX 10 A.X.COM + *.X.COM. TXT "v=spf1 a:A.X.COM -all" + + A.X.COM. A 1.2.3.4 + A.X.COM. MX 10 A.X.COM + A.X.COM. TXT "v=spf1 a:A.X.COM -all" + + *.A.X.COM. MX 10 A.X.COM + *.A.X.COM. TXT "v=spf1 a:A.X.COM -all" + + Notice that SPF records must be repeated twice for every name within + the domain: once for the name, and once with a wildcard to cover the + tree under the name. + + Use of wildcards is discouraged in general as they cause every name + under the domain to exist and queries against arbitrary names will + never return RCODE 3 (Name Error). + +4. The check_host() Function + + The check_host() function fetches SPF records, parses them, and + interprets them to determine whether a particular host is or is not + permitted to send mail with a given identity. Mail receivers that + perform this check MUST correctly evaluate the check_host() function + as described here. + + Implementations MAY use a different algorithm than the canonical + algorithm defined here, so long as the results are the same in all + cases. + +4.1. Arguments + + The check_host() function takes these arguments: + + <ip> - the IP address of the SMTP client that is emitting the + mail, either IPv4 or IPv6. + + <domain> - the domain that provides the sought-after authorization + information; initially, the domain portion of the "MAIL + FROM" or "HELO" identity. + + + +Wong & Schlitt Experimental [Page 12] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + <sender> - the "MAIL FROM" or "HELO" identity. + + The domain portion of <sender> will usually be the same as the + <domain> argument when check_host() is initially evaluated. However, + this will generally not be true for recursive evaluations (see + Section 5.2 below). + + Actual implementations of the check_host() function may need + additional arguments. + +4.2. Results + + The function check_host() can return one of several results described + in Section 2.5. Based on the result, the action to be taken is + determined by the local policies of the receiver. + +4.3. Initial Processing + + If the <domain> is malformed (label longer than 63 characters, zero- + length label not at the end, etc.) or is not a fully qualified domain + name, or if the DNS lookup returns "domain does not exist" (RCODE 3), + check_host() immediately returns the result "None". + + If the <sender> has no localpart, substitute the string "postmaster" + for the localpart. + +4.4. Record Lookup + + In accordance with how the records are published (see Section 3.1 + above), a DNS query needs to be made for the <domain> name, querying + for either RR type TXT, SPF, or both. If both SPF and TXT RRs are + looked up, the queries MAY be done in parallel. + + If all DNS lookups that are made return a server failure (RCODE 2), + or other error (RCODE other than 0 or 3), or time out, then + check_host() exits immediately with the result "TempError". + +4.5. Selecting Records + + Records begin with a version section: + + record = version terms *SP + version = "v=spf1" + + Starting with the set of records that were returned by the lookup, + record selection proceeds in two steps: + + + + + +Wong & Schlitt Experimental [Page 13] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + 1. Records that do not begin with a version section of exactly + "v=spf1" are discarded. Note that the version section is + terminated either by an SP character or the end of the record. A + record with a version section of "v=spf10" does not match and must + be discarded. + + 2. If any records of type SPF are in the set, then all records of + type TXT are discarded. + + After the above steps, there should be exactly one record remaining + and evaluation can proceed. If there are two or more records + remaining, then check_host() exits immediately with the result of + "PermError". + + If no matching records are returned, an SPF client MUST assume that + the domain makes no SPF declarations. SPF processing MUST stop and + return "None". + +4.6. Record Evaluation + + After one SPF record has been selected, the check_host() function + parses and interprets it to find a result for the current test. If + there are any syntax errors, check_host() returns immediately with + the result "PermError". + + Implementations MAY choose to parse the entire record first and + return "PermError" if the record is not syntactically well formed. + However, in all cases, any syntax errors anywhere in the record MUST + be detected. + +4.6.1. Term Evaluation + + There are two types of terms: mechanisms and modifiers. A record + contains an ordered list of these as specified in the following + Augmented Backus-Naur Form (ABNF). + + terms = *( 1*SP ( directive / modifier ) ) + + directive = [ qualifier ] mechanism + qualifier = "+" / "-" / "?" / "~" + mechanism = ( all / include + / A / MX / PTR / IP4 / IP6 / exists ) + modifier = redirect / explanation / unknown-modifier + unknown-modifier = name "=" macro-string + + name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) + + Most mechanisms allow a ":" or "/" character after the name. + + + +Wong & Schlitt Experimental [Page 14] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + Modifiers always contain an equals ('=') character immediately after + the name, and before any ":" or "/" characters that may be part of + the macro-string. + + Terms that do not contain any of "=", ":", or "/" are mechanisms, as + defined in Section 5. + + As per the definition of the ABNF notation in [RFC4234], mechanism + and modifier names are case-insensitive. + +4.6.2. Mechanisms + + Each mechanism is considered in turn from left to right. If there + are no more mechanisms, the result is specified in Section 4.7. + + When a mechanism is evaluated, one of three things can happen: it can + match, not match, or throw an exception. + + If it matches, processing ends and the qualifier value is returned as + the result of that record. If it does not match, processing + continues with the next mechanism. If it throws an exception, + mechanism processing ends and the exception value is returned. + + The possible qualifiers, and the results they return are as follows: + + "+" Pass + "-" Fail + "~" SoftFail + "?" Neutral + + The qualifier is optional and defaults to "+". + + When a mechanism matches and the qualifier is "-", then a "Fail" + result is returned and the explanation string is computed as + described in Section 6.2. + + The specific mechanisms are described in Section 5. + +4.6.3. Modifiers + + Modifiers are not mechanisms: they do not return match or not-match. + Instead they provide additional information. Although modifiers do + not directly affect the evaluation of the record, the "redirect" + modifier has an effect after all the mechanisms have been evaluated. + + + + + + + +Wong & Schlitt Experimental [Page 15] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +4.7. Default Result + + If none of the mechanisms match and there is no "redirect" modifier, + then the check_host() returns a result of "Neutral", just as if + "?all" were specified as the last directive. If there is a + "redirect" modifier, check_host() proceeds as defined in Section 6.1. + + Note that records SHOULD always use either a "redirect" modifier or + an "all" mechanism to explicitly terminate processing. + + For example: + + v=spf1 +mx -all + or + v=spf1 +mx redirect=_spf.example.com + +4.8. Domain Specification + + Several of these mechanisms and modifiers have a <domain-spec> + section. The <domain-spec> string is macro expanded (see Section 8). + The resulting string is the common presentation form of a fully- + qualified DNS name: a series of labels separated by periods. This + domain is called the <target-name> in the rest of this document. + + Note: The result of the macro expansion is not subject to any further + escaping. Hence, this facility cannot produce all characters that + are legal in a DNS label (e.g., the control characters). However, + this facility is powerful enough to express legal host names and + common utility labels (such as "_spf") that are used in DNS. + + For several mechanisms, the <domain-spec> is optional. If it is not + provided, the <domain> is used as the <target-name>. + +5. Mechanism Definitions + + This section defines two types of mechanisms. + + Basic mechanisms contribute to the language framework. They do not + specify a particular type of authorization scheme. + + all + include + + Designated sender mechanisms are used to designate a set of <ip> + addresses as being permitted or not permitted to use the <domain> for + sending mail. + + + + + +Wong & Schlitt Experimental [Page 16] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + a + mx + ptr + ip4 + ip6 + exists + + The following conventions apply to all mechanisms that perform a + comparison between <ip> and an IP address at any point: + + If no CIDR-length is given in the directive, then <ip> and the IP + address are compared for equality. (Here, CIDR is Classless Inter- + Domain Routing.) + + If a CIDR-length is specified, then only the specified number of + high-order bits of <ip> and the IP address are compared for equality. + + When any mechanism fetches host addresses to compare with <ip>, when + <ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6 + address, AAAA records are fetched. Even if the SMTP connection is + via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section + 2.5.5) MUST still be considered an IPv4 address. + + Several mechanisms rely on information fetched from DNS. For these + DNS queries, except where noted, if the DNS server returns an error + (RCODE other than 0 or 3) or the query times out, the mechanism + throws the exception "TempError". If the server returns "domain does + not exist" (RCODE 3), then evaluation of the mechanism continues as + if the server returned no error (RCODE 0) and zero answer records. + +5.1. "all" + + all = "all" + + The "all" mechanism is a test that always matches. It is used as the + rightmost mechanism in a record to provide an explicit default. + + For example: + + v=spf1 a mx -all + + Mechanisms after "all" will never be tested. Any "redirect" modifier + (Section 6.1) has no effect when there is an "all" mechanism. + + + + + + + + +Wong & Schlitt Experimental [Page 17] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +5.2. "include" + + include = "include" ":" domain-spec + + The "include" mechanism triggers a recursive evaluation of + check_host(). The domain-spec is expanded as per Section 8. Then + check_host() is evaluated with the resulting string as the <domain>. + The <ip> and <sender> arguments remain the same as in the current + evaluation of check_host(). + + In hindsight, the name "include" was poorly chosen. Only the + evaluated result of the referenced SPF record is used, rather than + acting as if the referenced SPF record was literally included in the + first. For example, evaluating a "-all" directive in the referenced + record does not terminate the overall processing and does not + necessarily result in an overall "Fail". (Better names for this + mechanism would have been "if-pass", "on-pass", etc.) + + The "include" mechanism makes it possible for one domain to designate + multiple administratively-independent domains. For example, a vanity + domain "example.net" might send mail using the servers of + administratively-independent domains example.com and example.org. + + Example.net could say + + IN TXT "v=spf1 include:example.com include:example.org -all" + + This would direct check_host() to, in effect, check the records of + example.com and example.org for a "Pass" result. Only if the host + were not permitted for either of those domains would the result be + "Fail". + + + + + + + + + + + + + + + + + + + + +Wong & Schlitt Experimental [Page 18] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + Whether this mechanism matches, does not match, or throws an + exception depends on the result of the recursive evaluation of + check_host(): + + +---------------------------------+---------------------------------+ + | A recursive check_host() result | Causes the "include" mechanism | + | of: | to: | + +---------------------------------+---------------------------------+ + | Pass | match | + | | | + | Fail | not match | + | | | + | SoftFail | not match | + | | | + | Neutral | not match | + | | | + | TempError | throw TempError | + | | | + | PermError | throw PermError | + | | | + | None | throw PermError | + +---------------------------------+---------------------------------+ + + The "include" mechanism is intended for crossing administrative + boundaries. Although it is possible to use includes to consolidate + multiple domains that share the same set of designated hosts, domains + are encouraged to use redirects where possible, and to minimize the + number of includes within a single administrative domain. For + example, if example.com and example.org were managed by the same + entity, and if the permitted set of hosts for both domains was + "mx:example.com", it would be possible for example.org to specify + "include:example.com", but it would be preferable to specify + "redirect=example.com" or even "mx:example.com". + +5.3. "a" + + This mechanism matches if <ip> is one of the <target-name>'s IP + addresses. + + A = "a" [ ":" domain-spec ] [ dual-cidr-length ] + + An address lookup is done on the <target-name>. The <ip> is compared + to the returned address(es). If any address matches, the mechanism + matches. + + + + + + + +Wong & Schlitt Experimental [Page 19] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +5.4. "mx" + + This mechanism matches if <ip> is one of the MX hosts for a domain + name. + + MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] + + check_host() first performs an MX lookup on the <target-name>. Then + it performs an address lookup on each MX name returned. The <ip> is + compared to each returned IP address. To prevent Denial of Service + (DoS) attacks, more than 10 MX names MUST NOT be looked up during the + evaluation of an "mx" mechanism (see Section 10). If any address + matches, the mechanism matches. + + Note regarding implicit MXs: If the <target-name> has no MX records, + check_host() MUST NOT pretend the target is its single MX, and MUST + NOT default to an A lookup on the <target-name> directly. This + behavior breaks with the legacy "implicit MX" rule. See [RFC2821], + Section 5. If such behavior is desired, the publisher should specify + an "a" directive. + +5.5. "ptr" + + This mechanism tests whether the DNS reverse-mapping for <ip> exists + and correctly points to a domain name within a particular domain. + + PTR = "ptr" [ ":" domain-spec ] + + First, the <ip>'s name is looked up using this procedure: perform a + DNS reverse-mapping for <ip>, looking up the corresponding PTR record + in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa." + if it is an IPv6 address. For each record returned, validate the + domain name by looking up its IP address. To prevent DoS attacks, + more than 10 PTR names MUST NOT be looked up during the evaluation of + a "ptr" mechanism (see Section 10). If <ip> is among the returned IP + addresses, then that domain name is validated. In pseudocode: + + sending-domain_names := ptr_lookup(sending-host_IP); if more than 10 + sending-domain_names are found, use at most 10. for each name in + (sending-domain_names) { + IP_addresses := a_lookup(name); + if the sending-domain_IP is one of the IP_addresses { + validated-sending-domain_names += name; + } } + + Check all validated domain names to see if they end in the + <target-name> domain. If any do, this mechanism matches. If no + validated domain name can be found, or if none of the validated + + + +Wong & Schlitt Experimental [Page 20] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + domain names end in the <target-name>, this mechanism fails to match. + If a DNS error occurs while doing the PTR RR lookup, then this + mechanism fails to match. If a DNS error occurs while doing an A RR + lookup, then that domain name is skipped and the search continues. + + Pseudocode: + + for each name in (validated-sending-domain_names) { + if name ends in <domain-spec>, return match. + if name is <domain-spec>, return match. + } + return no-match. + + This mechanism matches if the <target-name> is either an ancestor of + a validated domain name or if the <target-name> and a validated + domain name are the same. For example: "mail.example.com" is within + the domain "example.com", but "mail.bad-example.com" is not. + + Note: Use of this mechanism is discouraged because it is slow, it is + not as reliable as other mechanisms in cases of DNS errors, and it + places a large burden on the arpa name servers. If used, proper PTR + records must be in place for the domain's hosts and the "ptr" + mechanism should be one of the last mechanisms checked. + +5.6. "ip4" and "ip6" + + These mechanisms test whether <ip> is contained within a given IP + network. + + IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] + IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] + + ip4-cidr-length = "/" 1*DIGIT + ip6-cidr-length = "/" 1*DIGIT + dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] + + ip4-network = qnum "." qnum "." qnum "." qnum + qnum = DIGIT ; 0-9 + / %x31-39 DIGIT ; 10-99 + / "1" 2DIGIT ; 100-199 + / "2" %x30-34 DIGIT ; 200-249 + / "25" %x30-35 ; 250-255 + ; as per conventional dotted quad notation. e.g., 192.0.2.0 + ip6-network = <as per [RFC 3513], section 2.2> + ; e.g., 2001:DB8::CD30 + + The <ip> is compared to the given network. If CIDR-length high-order + bits match, the mechanism matches. + + + +Wong & Schlitt Experimental [Page 21] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + If ip4-cidr-length is omitted, it is taken to be "/32". If + ip6-cidr-length is omitted, it is taken to be "/128". It is not + permitted to omit parts of the IP address instead of using CIDR + notations. That is, use 192.0.2.0/24 instead of 192.0.2. + +5.7. "exists" + + This mechanism is used to construct an arbitrary domain name that is + used for a DNS A record query. It allows for complicated schemes + involving arbitrary parts of the mail envelope to determine what is + permitted. + + exists = "exists" ":" domain-spec + + The domain-spec is expanded as per Section 8. The resulting domain + name is used for a DNS A RR lookup. If any A record is returned, + this mechanism matches. The lookup type is A even when the + connection type is IPv6. + + Domains can use this mechanism to specify arbitrarily complex + queries. For example, suppose example.com publishes the record: + + v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all + + The <target-name> might expand to + "1.2.0.192.someuser._spf.example.com". This makes fine-grained + decisions possible at the level of the user and client IP address. + + This mechanism enables queries that mimic the style of tests that + existing anti-spam DNS blacklists (DNSBL) use. + +6. Modifier Definitions + + Modifiers are name/value pairs that provide additional information. + Modifiers always have an "=" separating the name and the value. + + The modifiers defined in this document ("redirect" and "exp") MAY + appear anywhere in the record, but SHOULD appear at the end, after + all mechanisms. Ordering of these two modifiers does not matter. + These two modifiers MUST NOT appear in a record more than once each. + If they do, then check_host() exits with a result of "PermError". + + Unrecognized modifiers MUST be ignored no matter where in a record, + or how often. This allows implementations of this document to + gracefully handle records with modifiers that are defined in other + specifications. + + + + + +Wong & Schlitt Experimental [Page 22] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +6.1. redirect: Redirected Query + + If all mechanisms fail to match, and a "redirect" modifier is + present, then processing proceeds as follows: + + redirect = "redirect" "=" domain-spec + + The domain-spec portion of the redirect section is expanded as per + the macro rules in Section 8. Then check_host() is evaluated with + the resulting string as the <domain>. The <ip> and <sender> + arguments remain the same as current evaluation of check_host(). + + The result of this new evaluation of check_host() is then considered + the result of the current evaluation with the exception that if no + SPF record is found, or if the target-name is malformed, the result + is a "PermError" rather than "None". + + Note that the newly-queried domain may itself specify redirect + processing. + + This facility is intended for use by organizations that wish to apply + the same record to multiple domains. For example: + + la.example.com. TXT "v=spf1 redirect=_spf.example.com" + ny.example.com. TXT "v=spf1 redirect=_spf.example.com" + sf.example.com. TXT "v=spf1 redirect=_spf.example.com" + _spf.example.com. TXT "v=spf1 mx:example.com -all" + + In this example, mail from any of the three domains is described by + the same record. This can be an administrative advantage. + + Note: In general, the domain "A" cannot reliably use a redirect to + another domain "B" not under the same administrative control. Since + the <sender> stays the same, there is no guarantee that the record at + domain "B" will correctly work for mailboxes in domain "A", + especially if domain "B" uses mechanisms involving localparts. An + "include" directive may be more appropriate. + + For clarity, it is RECOMMENDED that any "redirect" modifier appear as + the very last term in a record. + +6.2. exp: Explanation + + explanation = "exp" "=" domain-spec + + If check_host() results in a "Fail" due to a mechanism match (such as + "-all"), and the "exp" modifier is present, then the explanation + string returned is computed as described below. If no "exp" modifier + + + +Wong & Schlitt Experimental [Page 23] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + is present, then either a default explanation string or an empty + explanation string may be returned. + + The <domain-spec> is macro expanded (see Section 8) and becomes the + <target-name>. The DNS TXT record for the <target-name> is fetched. + + If <domain-spec> is empty, or there are any DNS processing errors + (any RCODE other than 0), or if no records are returned, or if more + than one record is returned, or if there are syntax errors in the + explanation string, then proceed as if no exp modifier was given. + + The fetched TXT record's strings are concatenated with no spaces, and + then treated as an <explain-string>, which is macro-expanded. This + final result is the explanation string. Implementations MAY limit + the length of the resulting explanation string to allow for other + protocol constraints and/or reasonable processing limits. Since the + explanation string is intended for an SMTP response and [RFC2821] + Section 2.4 says that responses are in [US-ASCII], the explanation + string is also limited to US-ASCII. + + Software evaluating check_host() can use this string to communicate + information from the publishing domain in the form of a short message + or URL. Software SHOULD make it clear that the explanation string + comes from a third party. For example, it can prepend the macro + string "%{o} explains: " to the explanation, such as shown in Section + 2.5.4. + + Suppose example.com has this record: + + v=spf1 mx -all exp=explain._spf.%{d} + + Here are some examples of possible explanation TXT records at + explain._spf.example.com: + + "Mail from example.com should only be sent by its own servers." + -- a simple, constant message + + "%{i} is not one of %{d}'s designated mail servers." + -- a message with a little more information, including the IP + address that failed the check + + "See http://%{d}/why.html?s=%{S}&i=%{I}" + -- a complicated example that constructs a URL with the + arguments to check_host() so that a web page can be + generated with detailed, custom instructions + + Note: During recursion into an "include" mechanism, an exp= modifier + from the <target-name> MUST NOT be used. In contrast, when executing + + + +Wong & Schlitt Experimental [Page 24] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + a "redirect" modifier, an exp= modifier from the original domain MUST + NOT be used. + +7. The Received-SPF Header Field + + It is RECOMMENDED that SMTP receivers record the result of SPF + processing in the message header. If an SMTP receiver chooses to do + so, it SHOULD use the "Received-SPF" header field defined here for + each identity that was checked. This information is intended for the + recipient. (Information intended for the sender is described in + Section 6.2, Explanation.) + + The Received-SPF header field is a trace field (see [RFC2822] Section + 3.6.7) and SHOULD be prepended to the existing header, above the + Received: field that is generated by the SMTP receiver. It MUST + appear above all other Received-SPF fields in the message. The + header field has the following format: + + header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] + [ key-value-list ] CRLF + + result = "Pass" / "Fail" / "SoftFail" / "Neutral" / + "None" / "TempError" / "PermError" + + key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) + [";"] + + key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) + + key = "client-ip" / "envelope-from" / "helo" / + "problem" / "receiver" / "identity" / + mechanism / "x-" name / name + + identity = "mailfrom" ; for the "MAIL FROM" identity + / "helo" ; for the "HELO" identity + / name ; other identities + + dot-atom = <unquoted word as per [RFC2822]> + quoted-string = <quoted string as per [RFC2822]> + comment = <comment string as per [RFC2822]> + CFWS = <comment or folding white space as per [RFC2822]> + FWS = <folding white space as per [RFC2822]> + CRLF = <standard end-of-line token as per [RFC2822]> + + The header field SHOULD include a "(...)" style <comment> after the + result, conveying supporting information for the result, such as + <ip>, <sender>, and <domain>. + + + + +Wong & Schlitt Experimental [Page 25] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + The following key-value pairs are designed for later machine parsing. + SPF clients SHOULD give enough information so that the SPF results + can be verified. That is, at least "client-ip", "helo", and, if the + "MAIL FROM" identity was checked, "envelope-from". + + client-ip the IP address of the SMTP client + + envelope-from the envelope sender mailbox + + helo the host name given in the HELO or EHLO command + + mechanism the mechanism that matched (if no mechanisms matched, + substitute the word "default") + + problem if an error was returned, details about the error + + receiver the host name of the SPF client + + identity the identity that was checked; see the <identity> ABNF + rule + + Other keys may be defined by SPF clients. Until a new key name + becomes widely accepted, new key names should start with "x-". + + SPF clients MUST make sure that the Received-SPF header field does + not contain invalid characters, is not excessively long, and does not + contain malicious data that has been provided by the sender. + + Examples of various header styles that could be generated are the + following: + + Received-SPF: Pass (mybox.example.org: domain of + myname@example.com designates 192.0.2.1 as permitted sender) + receiver=mybox.example.org; client-ip=192.0.2.1; + envelope-from=<myname@example.com>; helo=foo.example.com; + + Received-SPF: Fail (mybox.example.org: domain of + myname@example.com does not designate + 192.0.2.1 as permitted sender) + identity=mailfrom; client-ip=192.0.2.1; + envelope-from=<myname@example.com>; + + + + + + + + + + +Wong & Schlitt Experimental [Page 26] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +8. Macros + +8.1. Macro Definitions + + Many mechanisms and modifiers perform macro expansion on part of the + term. + + domain-spec = macro-string domain-end + domain-end = ( "." toplabel [ "." ] ) / macro-expand + + toplabel = ( *alphanum ALPHA *alphanum ) / + ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) + ; LDH rule plus additional TLD restrictions + ; (see [RFC3696], Section 2) + alphanum = ALPHA / DIGIT + + explain-string = *( macro-string / SP ) + + macro-string = *( macro-expand / macro-literal ) + macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) + / "%%" / "%_" / "%-" + macro-literal = %x21-24 / %x26-7E + ; visible characters except "%" + macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / + "c" / "r" / "t" + transformers = *DIGIT [ "r" ] + delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" + + A literal "%" is expressed by "%%". + + "%_" expands to a single " " space. + "%-" expands to a URL-encoded space, viz., "%20". + + The following macro letters are expanded in term arguments: + + s = <sender> + l = local-part of <sender> + o = domain of <sender> + d = <domain> + i = <ip> + p = the validated domain name of <ip> + v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6 + h = HELO/EHLO domain + + + + + + + + +Wong & Schlitt Experimental [Page 27] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + The following macro letters are allowed only in "exp" text: + + c = SMTP client IP (easily readable format) + r = domain name of host performing the check + t = current timestamp + + A '%' character not followed by a '{', '%', '-', or '_' character is + a syntax error. So + + -exists:%(ir).sbl.spamhaus.example.org + + is incorrect and will cause check_host() to return a "PermError". + Instead, say + + -exists:%{ir}.sbl.spamhaus.example.org + + Optional transformers are the following: + + *DIGIT = zero or more digits + 'r' = reverse value, splitting on dots by default + + If transformers or delimiters are provided, the replacement value for + a macro letter is split into parts. After performing any reversal + operation and/or removal of left-hand parts, the parts are rejoined + using "." and not the original splitting characters. + + By default, strings are split on "." (dots). Note that no special + treatment is given to leading, trailing, or consecutive delimiters, + and so the list of parts may contain empty strings. Older + implementations of SPF prohibit trailing dots in domain names, so + trailing dots should not be published by domain owners, although they + must be accepted by implementations conforming to this document. + Macros may specify delimiter characters that are used instead of ".". + + The 'r' transformer indicates a reversal operation: if the client IP + address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1" + and the macro %{ir} would expand to "1.2.0.192". + + The DIGIT transformer indicates the number of right-hand parts to + use, after optional reversal. If a DIGIT is specified, the value + MUST be nonzero. If no DIGITs are specified, or if the value + specifies more parts than are available, all the available parts are + used. If the DIGIT was 5, and only 3 parts were available, the macro + interpreter would pretend the DIGIT was 3. Implementations MUST + support at least a value of 128, as that is the maximum number of + labels in a domain name. + + + + + +Wong & Schlitt Experimental [Page 28] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + The "s" macro expands to the <sender> argument. It is an E-Mail + address with a localpart, an "@" character, and a domain. The "l" + macro expands to just the localpart. The "o" macro expands to just + the domain part. Note that these values remain the same during + recursive and chained evaluations due to "include" and/or "redirect". + Note also that if the original <sender> had no localpart, the + localpart was set to "postmaster" in initial processing (see Section + 4.3). + + For IPv4 addresses, both the "i" and "c" macros expand to the + standard dotted-quad format. + + For IPv6 addresses, the "i" macro expands to a dot-format address; it + is intended for use in %{ir}. The "c" macro may expand to any of the + hexadecimal colon-format addresses specified in [RFC3513], Section + 2.2. It is intended for humans to read. + + The "p" macro expands to the validated domain name of <ip>. The + procedure for finding the validated domain name is defined in Section + 5.5. If the <domain> is present in the list of validated domains, it + SHOULD be used. Otherwise, if a subdomain of the <domain> is + present, it SHOULD be used. Otherwise, any name from the list may be + used. If there are no validated domain names or if a DNS error + occurs, the string "unknown" is used. + + The "r" macro expands to the name of the receiving MTA. This SHOULD + be a fully qualified domain name, but if one does not exist (as when + the checking is done by a MUA) or if policy restrictions dictate + otherwise, the word "unknown" SHOULD be substituted. The domain name + may be different from the name found in the MX record that the client + MTA used to locate the receiving MTA. + + The "t" macro expands to the decimal representation of the + approximate number of seconds since the Epoch (Midnight, January 1, + 1970, UTC). This is the same value as is returned by the POSIX + time() function in most standards-compliant libraries. + + When the result of macro expansion is used in a domain name query, if + the expanded domain name exceeds 253 characters (the maximum length + of a domain name), the left side is truncated to fit, by removing + successive domain labels until the total length does not exceed 253 + characters. + + Uppercased macros expand exactly as their lowercased equivalents, and + are then URL escaped. URL escaping must be performed for characters + not in the "uric" set, which is defined in [RFC3986]. + + + + + +Wong & Schlitt Experimental [Page 29] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + Note: Care must be taken so that macro expansion for legitimate + E-Mail does not exceed the 63-character limit on DNS labels. The + localpart of E-Mail addresses, in particular, can have more than 63 + characters between dots. + + Note: Domains should avoid using the "s", "l", "o", or "h" macros in + conjunction with any mechanism directive. Although these macros are + powerful and allow per-user records to be published, they severely + limit the ability of implementations to cache results of check_host() + and they reduce the effectiveness of DNS caches. + + Implementations should be aware that if no directive processed during + the evaluation of check_host() contains an "s", "l", "o", or "h" + macro, then the results of the evaluation can be cached on the basis + of <domain> and <ip> alone for as long as the shortest Time To Live + (TTL) of all the DNS records involved. + +8.2. Expansion Examples + + The <sender> is strong-bad@email.example.com. + The IPv4 SMTP client IP is 192.0.2.3. + The IPv6 SMTP client IP is 2001:DB8::CB01. + The PTR domain name of the client IP is mx.example.org. + + macro expansion + ------- ---------------------------- + %{s} strong-bad@email.example.com + %{o} email.example.com + %{d} email.example.com + %{d4} email.example.com + %{d3} email.example.com + %{d2} example.com + %{d1} com + %{dr} com.example.email + %{d2r} example.email + %{l} strong-bad + %{l-} strong.bad + %{lr} strong-bad + %{lr-} bad.strong + %{l1r-} strong + + + + + + + + + + + +Wong & Schlitt Experimental [Page 30] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + macro-string expansion + -------------------------------------------------------------------- + %{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com + %{lr-}.lp._spf.%{d2} bad.strong.lp._spf.example.com + + %{lr-}.lp.%{ir}.%{v}._spf.%{d2} + bad.strong.lp.3.2.0.192.in-addr._spf.example.com + + %{ir}.%{v}.%{l1r-}.lp._spf.%{d2} + 3.2.0.192.in-addr.strong.lp._spf.example.com + + %{d2}.trusted-domains.example.net + example.com.trusted-domains.example.net + + IPv6: + %{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0. + 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 + +9. Implications + + This section outlines the major implications that adoption of this + document will have on various entities involved in Internet E-Mail. + It is intended to make clear to the reader where this document + knowingly affects the operation of such entities. This section is + not a "how-to" manual, or a "best practices" document, and it is not + a comprehensive list of what such entities should do in light of this + document. + + This section is non-normative. + +9.1. Sending Domains + + Domains that wish to be compliant with this specification will need + to determine the list of hosts that they allow to use their domain + name in the "HELO" and "MAIL FROM" identities. It is recognized that + forming such a list is not just a simple technical exercise, but + involves policy decisions with both technical and administrative + considerations. + + It can be helpful to publish records that include a "tracking + exists:" mechanism. By looking at the name server logs, a rough list + may then be generated. For example: + + v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all + + + + + + + +Wong & Schlitt Experimental [Page 31] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +9.2. Mailing Lists + + Mailing lists must be aware of how they re-inject mail that is sent + to the list. Mailing lists MUST comply with the requirements in + [RFC2821], Section 3.10, and [RFC1123], Section 5.3.6, that say that + the reverse-path MUST be changed to be the mailbox of a person or + other entity who administers the list. Whereas the reasons for + changing the reverse-path are many and long-standing, SPF adds + enforcement to this requirement. + + In practice, almost all mailing list software in use already complies + with this requirement. Mailing lists that do not comply may or may + not encounter problems depending on how access to the list is + restricted. Such lists that are entirely internal to a domain (only + people in the domain can send to or receive from the list) are not + affected. + +9.3. Forwarding Services and Aliases + + Forwarding services take mail that is received at a mailbox and + direct it to some external mailbox. At the time of this writing, the + near-universal practice of such services is to use the original "MAIL + FROM" of a message when re-injecting it for delivery to the external + mailbox. [RFC1123] and [RFC2821] describe this action as an "alias" + rather than a "mail list". This means that the external mailbox's + MTA sees all such mail in a connection from a host of the forwarding + service, and so the "MAIL FROM" identity will not, in general, pass + authorization. + + There are three places that techniques can be used to ameliorate this + problem. + + 1. The beginning, when E-Mail is first sent. + + 1. "Neutral" results could be given for IP addresses that may be + forwarders, instead of "Fail" results. For example: + + "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all" + + This would cause a lookup on an anti-spam DNS blacklist + (DNSBL) and cause a result of "Fail" only for E-Mail coming + from listed sources. All other E-Mail, including E-Mail sent + through forwarders, would receive a "Neutral" result. By + checking the DNSBL after the known good sources, problems with + incorrect listing on the DNSBL are greatly reduced. + + + + + + +Wong & Schlitt Experimental [Page 32] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + 2. The "MAIL FROM" identity could have additional information in + the localpart that cryptographically identifies the mail as + coming from an authorized source. In this case, such an SPF + record could be used: + + "v=spf1 mx exists:%{l}._spf_verify.%{d} -all" + + Then, a specialized DNS server can be set up to serve the + _spf_verify subdomain that validates the localpart. Although + this requires an extra DNS lookup, this happens only when the + E-Mail would otherwise be rejected as not coming from a known + good source. + + Note that due to the 63-character limit for domain labels, + this approach only works reliably if the localpart signature + scheme is guaranteed either to only produce localparts with a + maximum of 63 characters or to gracefully handle truncated + localparts. + + 3. Similarly, a specialized DNS server could be set up that will + rate-limit the E-Mail coming from unexpected IP addresses. + + "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all" + + 4. SPF allows the creation of per-user policies for special + cases. For example, the following SPF record and appropriate + wildcard DNS records can be used: + + "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}" + + 2. The middle, when E-Mail is forwarded. + + 1. Forwarding services can solve the problem by rewriting the + "MAIL FROM" to be in their own domain. This means that mail + bounced from the external mailbox will have to be re-bounced + by the forwarding service. Various schemes to do this exist + though they vary widely in complexity and resource + requirements on the part of the forwarding service. + + 2. Several popular MTAs can be forced from "alias" semantics to + "mailing list" semantics by configuring an additional alias + with "owner-" prepended to the original alias name (e.g., an + alias of "friends: george@example.com, fred@example.org" would + need another alias of the form "owner-friends: localowner"). + + + + + + + +Wong & Schlitt Experimental [Page 33] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + 3. The end, when E-Mail is received. + + 1. If the owner of the external mailbox wishes to trust the + forwarding service, he can direct the external mailbox's MTA + to skip SPF tests when the client host belongs to the + forwarding service. + + 2. Tests against other identities, such as the "HELO" identity, + may be used to override a failed test against the "MAIL FROM" + identity. + + 3. For larger domains, it may not be possible to have a complete + or accurate list of forwarding services used by the owners of + the domain's mailboxes. In such cases, whitelists of + generally-recognized forwarding services could be employed. + +9.4. Mail Services + + Service providers that offer mail services to third-party domains, + such as sending of bulk mail, may want to adjust their setup in light + of the authorization check described in this document. If the "MAIL + FROM" identity used for such E-Mail uses the domain of the service + provider, then the provider needs only to ensure that its sending + host is authorized by its own SPF record, if any. + + If the "MAIL FROM" identity does not use the mail service provider's + domain, then extra care must be taken. The SPF record format has + several options for the third-party domain to authorize the service + provider's MTAs to send mail on its behalf. For mail service + providers, such as ISPs, that have a wide variety of customers using + the same MTA, steps should be taken to prevent cross-customer forgery + (see Section 10.4). + +9.5. MTA Relays + + The authorization check generally precludes the use of arbitrary MTA + relays between sender and receiver of an E-Mail message. + + Within an organization, MTA relays can be effectively deployed. + However, for purposes of this document, such relays are effectively + transparent. The SPF authorization check is a check between border + MTAs of different domains. + + For mail senders, this means that published SPF records must + authorize any MTAs that actually send across the Internet. Usually, + these are just the border MTAs as internal MTAs simply forward mail + to these MTAs for delivery. + + + + +Wong & Schlitt Experimental [Page 34] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + Mail receivers will generally want to perform the authorization check + at the border MTAs, specifically including all secondary MXs. This + allows mail that fails to be rejected during the SMTP session rather + than bounced. Internal MTAs then do not perform the authorization + test. To perform the authorization test other than at the border, + the host that first transferred the message to the organization must + be determined, which can be difficult to extract from the message + header. Testing other than at the border is not recommended. + +10. Security Considerations + +10.1. Processing Limits + + As with most aspects of E-Mail, there are a number of ways that + malicious parties could use the protocol as an avenue for a + Denial-of-Service (DoS) attack. The processing limits outlined here + are designed to prevent attacks such as the following: + + o A malicious party could create an SPF record with many references + to a victim's domain and send many E-Mails to different SPF + clients; those SPF clients would then create a DoS attack. In + effect, the SPF clients are being used to amplify the attacker's + bandwidth by using fewer bytes in the SMTP session than are used + by the DNS queries. Using SPF clients also allows the attacker to + hide the true source of the attack. + + o Whereas implementations of check_host() are supposed to limit the + number of DNS lookups, malicious domains could publish records + that exceed these limits in an attempt to waste computation effort + at their targets when they send them mail. Malicious domains + could also design SPF records that cause particular + implementations to use excessive memory or CPU usage, or to + trigger bugs. + + o Malicious parties could send a large volume of mail purporting to + come from the intended target to a wide variety of legitimate mail + hosts. These legitimate machines would then present a DNS load on + the target as they fetched the relevant records. + + Of these, the case of a third party referenced in the SPF record is + the easiest for a DoS attack to effectively exploit. As a result, + limits that may seem reasonable for an individual mail server can + still allow an unreasonable amount of bandwidth amplification. + Therefore, the processing limits need to be quite low. + + SPF implementations MUST limit the number of mechanisms and modifiers + that do DNS lookups to at most 10 per SPF check, including any + lookups caused by the use of the "include" mechanism or the + + + +Wong & Schlitt Experimental [Page 35] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + "redirect" modifier. If this number is exceeded during a check, a + PermError MUST be returned. The "include", "a", "mx", "ptr", and + "exists" mechanisms as well as the "redirect" modifier do count + against this limit. The "all", "ip4", and "ip6" mechanisms do not + require DNS lookups and therefore do not count against this limit. + The "exp" modifier does not count against this limit because the DNS + lookup to fetch the explanation string occurs after the SPF record + has been evaluated. + + When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, + there MUST be a limit of no more than 10 MX or PTR RRs looked up and + checked. + + SPF implementations SHOULD limit the total amount of data obtained + from the DNS queries. For example, when DNS over TCP or EDNS0 are + available, there may need to be an explicit limit to how much data + will be accepted to prevent excessive bandwidth usage or memory usage + and DoS attacks. + + MTAs or other processors MAY also impose a limit on the maximum + amount of elapsed time to evaluate check_host(). Such a limit SHOULD + allow at least 20 seconds. If such a limit is exceeded, the result + of authorization SHOULD be "TempError". + + Domains publishing records SHOULD try to keep the number of "include" + mechanisms and chained "redirect" modifiers to a minimum. Domains + SHOULD also try to minimize the amount of other DNS information + needed to evaluate a record. This can be done by choosing directives + that require less DNS information and placing lower-cost mechanisms + earlier in the SPF record. + + For example, consider a domain set up as follows: + + example.com. IN MX 10 mx.example.com. + mx.example.com. IN A 192.0.2.1 + a.example.com. IN TXT "v=spf1 mx:example.com -all" + b.example.com. IN TXT "v=spf1 a:mx.example.com -all" + c.example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all" + + Evaluating check_host() for the domain "a.example.com" requires the + MX records for "example.com", and then the A records for the listed + hosts. Evaluating for "b.example.com" requires only the A records. + Evaluating for "c.example.com" requires none. + + However, there may be administrative considerations: using "a" over + "ip4" allows hosts to be renumbered easily. Using "mx" over "a" + allows the set of mail hosts to be changed easily. + + + + +Wong & Schlitt Experimental [Page 36] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +10.2. SPF-Authorized E-Mail May Contain Other False Identities + + The "MAIL FROM" and "HELO" identity authorizations must not be + construed to provide more assurance than they do. It is entirely + possible for a malicious sender to inject a message using his own + domain in the identities used by SPF, to have that domain's SPF + record authorize the sending host, and yet the message can easily + list other identities in its header. Unless the user or the MUA + takes care to note that the authorized identity does not match the + other more commonly-presented identities (such as the From: header + field), the user may be lulled into a false sense of security. + +10.3. Spoofed DNS and IP Data + + There are two aspects of this protocol that malicious parties could + exploit to undermine the validity of the check_host() function: + + o The evaluation of check_host() relies heavily on DNS. A malicious + attacker could attack the DNS infrastructure and cause + check_host() to see spoofed DNS data, and then return incorrect + results. This could include returning "Pass" for an <ip> value + where the actual domain's record would evaluate to "Fail". See + [RFC3833] for a description of DNS weaknesses. + + o The client IP address, <ip>, is assumed to be correct. A + malicious attacker could spoof TCP sequence numbers to make mail + appear to come from a permitted host for a domain that the + attacker is impersonating. + +10.4. Cross-User Forgery + + By definition, SPF policies just map domain names to sets of + authorized MTAs, not whole E-Mail addresses to sets of authorized + users. Although the "l" macro (Section 8) provides a limited way to + define individual sets of authorized MTAs for specific E-Mail + addresses, it is generally impossible to verify, through SPF, the use + of specific E-Mail addresses by individual users of the same MTA. + + It is up to mail services and their MTAs to directly prevent + cross-user forgery: based on SMTP AUTH ([RFC2554]), users should be + restricted to using only those E-Mail addresses that are actually + under their control (see [RFC4409], Section 6.1). Another means to + verify the identity of individual users is message cryptography such + as PGP ([RFC2440]) or S/MIME ([RFC3851]). + + + + + + + +Wong & Schlitt Experimental [Page 37] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +10.5. Untrusted Information Sources + + SPF uses information supplied by third parties, such as the "HELO" + domain name, the "MAIL FROM" address, and SPF records. This + information is then passed to the receiver in the Received-SPF: trace + fields and possibly returned to the client MTA in the form of an SMTP + rejection message. This information must be checked for invalid + characters and excessively long lines. + + When the authorization check fails, an explanation string may be + included in the reject response. Both the sender and the rejecting + receiver need to be aware that the explanation was determined by the + publisher of the SPF record checked and, in general, not the + receiver. The explanation may contain malicious URLs, or it may be + offensive or misleading. + + This is probably less of a concern than it may initially seem since + such messages are returned to the sender, and the explanation strings + come from the sender policy published by the domain in the identity + claimed by that very sender. As long as the DSN is not redirected to + someone other than the actual sender, the only people who see + malicious explanation strings are people whose messages claim to be + from domains that publish such strings in their SPF records. In + practice, DSNs can be misdirected, such as when an MTA accepts an + E-Mail and then later generates a DSN to a forged address, or when an + E-Mail forwarder does not direct the DSN back to the original sender. + +10.6. Privacy Exposure + + Checking SPF records causes DNS queries to be sent to the domain + owner. These DNS queries, especially if they are caused by the + "exists" mechanism, can contain information about who is sending + E-Mail and likely to which MTA the E-Mail is being sent. This can + introduce some privacy concerns, which may be more or less of an + issue depending on local laws and the relationship between the domain + owner and the person sending the E-Mail. + +11. Contributors and Acknowledgements + + This document is largely based on the work of Meng Weng Wong and Mark + Lentczner. Although, as this section acknowledges, many people have + contributed to this document, a very large portion of the writing and + editing are due to Meng and Mark. + + This design owes a debt of parentage to [RMX] by Hadmut Danisch and + to [DMP] by Gordon Fecyk. The idea of using a DNS record to check + the legitimacy of an E-Mail address traces its ancestry further back + through messages on the namedroppers mailing list by Paul Vixie + + + +Wong & Schlitt Experimental [Page 38] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + [Vixie] (based on suggestion by Jim Miller) and by David Green + [Green]. + + Philip Gladstone contributed the concept of macros to the + specification, multiplying the expressiveness of the language and + making per-user and per-IP lookups possible. + + The authors would also like to thank the literally hundreds of + individuals who have participated in the development of this design. + They are far too numerous to name, but they include the following: + + The folks on the spf-discuss mailing list. + The folks on the SPAM-L mailing list. + The folks on the IRTF ASRG mailing list. + The folks on the IETF MARID mailing list. + The folks on #perl. + +12. IANA Considerations + +12.1. The SPF DNS Record Type + + The IANA has assigned a new Resource Record Type and Qtype from the + DNS Parameters Registry for the SPF RR type with code 99. + +12.2. The Received-SPF Mail Header Field + + Per [RFC3864], the "Received-SPF:" header field is added to the IANA + Permanent Message Header Field Registry. The following is the + registration template: + + Header field name: Received-SPF + Applicable protocol: mail ([RFC2822]) + Status: Experimental + Author/Change controller: IETF + Specification document(s): RFC 4408 + Related information: + Requesting SPF Council review of any proposed changes and + additions to this field are recommended. For information about + the SPF Council see http://www.openspf.org/Council + +13. References + +13.1. Normative References + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + + + + +Wong & Schlitt Experimental [Page 39] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + [RFC1123] Braden, R., "Requirements for Internet Hosts - Application + and Support", STD 3, RFC 1123, October 1989. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April + 2001. + + [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format + for Delivery Status Notifications", RFC 3464, January + 2003. + + [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 + (IPv6) Addressing Architecture", RFC 3513, April 2003. + + [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + September 2004. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, RFC + 3986, January 2005. + + [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [US-ASCII] American National Standards Institute (formerly United + States of America Standards Institute), "USA Code for + Information Interchange, X3.4", 1968. + + ANSI X3.4-1968 has been replaced by newer versions with slight + modifications, but the 1968 version remains definitive for + the Internet. + +13.2 Informative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, August + 1996. + + [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, + "OpenPGP Message Format", RFC 2440, November 1998. + + + +Wong & Schlitt Experimental [Page 40] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + [RFC2554] Myers, J., "SMTP Service Extension for Authentication", + RFC 2554, March 1999. + + [RFC3696] Klensin, J., "Application Techniques for Checking and + Transformation of Names", RFC 3696, February 2004. + + [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain + Name System (DNS)", RFC 3833, August 2004. + + [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail + Extensions (S/MIME) Version 3.1 Message Specification", + RFC 3851, July 2004. + + [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", + RFC 4409, April 2006. + + [RMX] Danish, H., "The RMX DNS RR Type for light weight sender + authentication", Work In Progress + + [DMP] Fecyk, G., "Designated Mailers Protocol", Work In Progress + + [Vixie] Vixie, P., "Repudiating MAIL FROM", 2002. + + [Green] Green, D., "Domain-Authorized SMTP Mail", 2002. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wong & Schlitt Experimental [Page 41] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +Appendix A. Collected ABNF + + This section is normative and any discrepancies with the ABNF + fragments in the preceding text are to be resolved in favor of this + grammar. + + See [RFC4234] for ABNF notation. Please note that as per this ABNF + definition, literal text strings (those in quotes) are case- + insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx". + + record = version terms *SP + version = "v=spf1" + + terms = *( 1*SP ( directive / modifier ) ) + + directive = [ qualifier ] mechanism + qualifier = "+" / "-" / "?" / "~" + mechanism = ( all / include + / A / MX / PTR / IP4 / IP6 / exists ) + + all = "all" + include = "include" ":" domain-spec + A = "a" [ ":" domain-spec ] [ dual-cidr-length ] + MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] + PTR = "ptr" [ ":" domain-spec ] + IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] + IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] + exists = "exists" ":" domain-spec + + modifier = redirect / explanation / unknown-modifier + redirect = "redirect" "=" domain-spec + explanation = "exp" "=" domain-spec + unknown-modifier = name "=" macro-string + + ip4-cidr-length = "/" 1*DIGIT + ip6-cidr-length = "/" 1*DIGIT + dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] + + ip4-network = qnum "." qnum "." qnum "." qnum + qnum = DIGIT ; 0-9 + / %x31-39 DIGIT ; 10-99 + / "1" 2DIGIT ; 100-199 + / "2" %x30-34 DIGIT ; 200-249 + / "25" %x30-35 ; 250-255 + ; conventional dotted quad notation. e.g., 192.0.2.0 + ip6-network = <as per [RFC 3513], section 2.2> + ; e.g., 2001:DB8::CD30 + + + + +Wong & Schlitt Experimental [Page 42] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + domain-spec = macro-string domain-end + domain-end = ( "." toplabel [ "." ] ) / macro-expand + toplabel = ( *alphanum ALPHA *alphanum ) / + ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) + ; LDH rule plus additional TLD restrictions + ; (see [RFC3696], Section 2) + + alphanum = ALPHA / DIGIT + + explain-string = *( macro-string / SP ) + + macro-string = *( macro-expand / macro-literal ) + macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) + / "%%" / "%_" / "%-" + macro-literal = %x21-24 / %x26-7E + ; visible characters except "%" + macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / + "c" / "r" / "t" + transformers = *DIGIT [ "r" ] + delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" + + name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) + + header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] + [ key-value-list ] CRLF + + result = "Pass" / "Fail" / "SoftFail" / "Neutral" / + "None" / "TempError" / "PermError" + + key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) + [";"] + + key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) + + key = "client-ip" / "envelope-from" / "helo" / + "problem" / "receiver" / "identity" / + mechanism / "x-" name / name + + identity = "mailfrom" ; for the "MAIL FROM" identity + / "helo" ; for the "HELO" identity + / name ; other identities + + dot-atom = <unquoted word as per [RFC2822]> + quoted-string = <quoted string as per [RFC2822]> + comment = <comment string as per [RFC2822]> + CFWS = <comment or folding white space as per [RFC2822]> + FWS = <folding white space as per [RFC2822]> + CRLF = <standard end-of-line token as per [RFC2822]> + + + +Wong & Schlitt Experimental [Page 43] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +Appendix B. Extended Examples + + These examples are based on the following DNS setup: + + ; A domain with two mail servers, two hosts + ; and two servers at the domain name + $ORIGIN example.com. + @ MX 10 mail-a + MX 20 mail-b + A 192.0.2.10 + A 192.0.2.11 + amy A 192.0.2.65 + bob A 192.0.2.66 + mail-a A 192.0.2.129 + mail-b A 192.0.2.130 + www CNAME example.com. + + ; A related domain + $ORIGIN example.org. + @ MX 10 mail-c + mail-c A 192.0.2.140 + + ; The reverse IP for those addresses + $ORIGIN 2.0.192.in-addr.arpa. + 10 PTR example.com. + 11 PTR example.com. + 65 PTR amy.example.com. + 66 PTR bob.example.com. + 129 PTR mail-a.example.com. + 130 PTR mail-b.example.com. + 140 PTR mail-c.example.org. + + ; A rogue reverse IP domain that claims to be + ; something it's not + $ORIGIN 0.0.10.in-addr.arpa. + 4 PTR bob.example.com. + +B.1. Simple Examples + + These examples show various possible published records for + example.com and which values if <ip> would cause check_host() to + return "Pass". Note that <domain> is "example.com". + + v=spf1 +all + -- any <ip> passes + + v=spf1 a -all + -- hosts 192.0.2.10 and 192.0.2.11 pass + + + +Wong & Schlitt Experimental [Page 44] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + v=spf1 a:example.org -all + -- no sending hosts pass since example.org has no A records + + v=spf1 mx -all + -- sending hosts 192.0.2.129 and 192.0.2.130 pass + + v=spf1 mx:example.org -all + -- sending host 192.0.2.140 passes + + v=spf1 mx mx:example.org -all + -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass + + v=spf1 mx/30 mx:example.org/30 -all + -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes + + v=spf1 ptr -all + -- sending host 192.0.2.65 passes (reverse DNS is valid and is in + example.com) + -- sending host 192.0.2.140 fails (reverse DNS is valid, but not + in example.com) + -- sending host 10.0.0.4 fails (reverse IP is not valid) + + v=spf1 ip4:192.0.2.128/28 -all + -- sending host 192.0.2.65 fails + -- sending host 192.0.2.129 passes + +B.2. Multiple Domain Example + + These examples show the effect of related records: + + example.org: "v=spf1 include:example.com include:example.net -all" + + This record would be used if mail from example.org actually came + through servers at example.com and example.net. Example.org's + designated servers are the union of example.com's and example.net's + designated servers. + + la.example.org: "v=spf1 redirect=example.org" + ny.example.org: "v=spf1 redirect=example.org" + sf.example.org: "v=spf1 redirect=example.org" + + These records allow a set of domains that all use the same mail + system to make use of that mail system's record. In this way, only + the mail system's record needs to be updated when the mail setup + changes. These domains' records never have to change. + + + + + + +Wong & Schlitt Experimental [Page 45] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +B.3. DNSBL Style Example + + Imagine that, in addition to the domain records listed above, there + are these: + + $ORIGIN _spf.example.com. mary.mobile-users A + 127.0.0.2 fred.mobile-users A 127.0.0.2 + 15.15.168.192.joel.remote-users A 127.0.0.2 + 16.15.168.192.joel.remote-users A 127.0.0.2 + + The following records describe users at example.com who mail from + arbitrary servers, or who mail from personal servers. + + example.com: + + v=spf1 mx + include:mobile-users._spf.%{d} + include:remote-users._spf.%{d} + -all + + mobile-users._spf.example.com: + + v=spf1 exists:%{l1r+}.%{d} + + remote-users._spf.example.com: + + v=spf1 exists:%{ir}.%{l1r+}.%{d} + +B.4. Multiple Requirements Example + + Say that your sender policy requires both that the IP address is + within a certain range and that the reverse DNS for the IP matches. + This can be done several ways, including the following: + + example.com. SPF ( "v=spf1 " + "-include:ip4._spf.%{d} " + "-include:ptr._spf.%{d} " + "+all" ) + ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all" + ptr._spf.example.com. SPF "v=spf1 -ptr +all" + + This example shows how the "-include" mechanism can be useful, how an + SPF record that ends in "+all" can be very restrictive, and the use + of De Morgan's Law. + + + + + + + +Wong & Schlitt Experimental [Page 46] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +Authors' Addresses + + Meng Weng Wong + Singapore + + EMail: mengwong+spf@pobox.com + + + Wayne Schlitt + 4615 Meredeth #9 + Lincoln Nebraska, NE 68506 + United States of America + + EMail: wayne@schlitt.net + URI: http://www.schlitt.net/spf/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wong & Schlitt Experimental [Page 47] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Wong & Schlitt Experimental [Page 48] + |