--- draft-schlitt-spf-classic-02pre1.clean.txt 2005-05-30 02:13:11.000000000 -0500 +++ draft-schlitt-spf-classic-02pre2.clean.txt 2005-06-05 15:13:24.000000000 -0500 @@ -70,8 +70,8 @@ 3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Publishing . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.1. DNS Resource Record Types . . . . . . . . . . . . . . 11 - 3.1.2. Multiple Records . . . . . . . . . . . . . . . . . . . 12 - 3.1.3. Multiple Strings . . . . . . . . . . . . . . . . . . . 12 + 3.1.2. Multiple DNS Records . . . . . . . . . . . . . . . . . 12 + 3.1.3. Multiple Strings in a Single DNS record . . . . . . . 12 3.1.4. Record Size . . . . . . . . . . . . . . . . . . . . . 12 3.1.5. Wildcard Records . . . . . . . . . . . . . . . . . . . 13 4. The check_host() Function . . . . . . . . . . . . . . . . . . 14 @@ -86,50 +86,50 @@ 4.6.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . 17 4.7. Default Result . . . . . . . . . . . . . . . . . . . . . . 17 4.8. Domain Specification . . . . . . . . . . . . . . . . . . . 17 - 5. Mechanism Definitions . . . . . . . . . . . . . . . . . . . . 18 - 5.1. "all" . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 5.2. "include" . . . . . . . . . . . . . . . . . . . . . . . . 19 - 5.3. "a" . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 5.5. "ptr" . . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 22 - 5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 24 - 6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 24 - 6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 25 - 7. The Received-SPF header field . . . . . . . . . . . . . . . . 27 - 8. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 - 8.1. Macro definitions . . . . . . . . . . . . . . . . . . . . 29 - 8.2. Expansion Examples . . . . . . . . . . . . . . . . . . . . 32 - 9. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 33 - 9.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 33 - 9.2. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 33 - 9.3. Forwarding Services and Aliases . . . . . . . . . . . . . 33 - 9.4. Mail Services . . . . . . . . . . . . . . . . . . . . . . 35 - 9.5. MTA Relays . . . . . . . . . . . . . . . . . . . . . . . . 36 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 37 - 10.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 37 - 10.2. SPF-Authorized E-Mail May Be UBE . . . . . . . . . . . . . 38 - 10.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 39 - 10.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 39 - 10.5. Untrusted Information Sources . . . . . . . . . . . . . . 39 - 10.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 40 - 11. Contributors and Acknowledgements . . . . . . . . . . . . . . 41 - 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 - 12.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 42 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 43 - 13.2. Informative References . . . . . . . . . . . . . . . . . . 43 - 12.2. The Received-SPF mail header . . . . . . . . . . . . . . . 42 - Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 45 - Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 47 - B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 47 - B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 48 - B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 49 - B.4. Multiple Requirements Example . . . . . . . . . . . . . . 49 - Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 50 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 52 - Intellectual Property and Copyright Statements . . . . . . . . . . 53 + 5. Mechanism Definitions . . . . . . . . . . . . . . . . . . . . 19 + 5.1. "all" . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 5.2. "include" . . . . . . . . . . . . . . . . . . . . . . . . 20 + 5.3. "a" . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 5.5. "ptr" . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 23 + 5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 25 + 6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 25 + 6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 26 + 7. The Received-SPF header field . . . . . . . . . . . . . . . . 28 + 8. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 8.1. Macro definitions . . . . . . . . . . . . . . . . . . . . 30 + 8.2. Expansion Examples . . . . . . . . . . . . . . . . . . . . 33 + 9. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 9.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 34 + 9.2. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 34 + 9.3. Forwarding Services and Aliases . . . . . . . . . . . . . 34 + 9.4. Mail Services . . . . . . . . . . . . . . . . . . . . . . 36 + 9.5. MTA Relays . . . . . . . . . . . . . . . . . . . . . . . . 37 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 38 + 10.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 38 + 10.2. SPF-Authorized E-Mail May Be UBE . . . . . . . . . . . . . 39 + 10.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 40 + 10.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 40 + 10.5. Untrusted Information Sources . . . . . . . . . . . . . . 40 + 10.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 41 + 11. Contributors and Acknowledgements . . . . . . . . . . . . . . 42 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 + 12.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 43 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 + 13.2. Informative References . . . . . . . . . . . . . . . . . . 44 + 12.2. The Received-SPF mail header . . . . . . . . . . . . . . . 43 + Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 46 + Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 48 + B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 48 + B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 49 + B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 50 + B.4. Multiple Requirements Example . . . . . . . . . . . . . . 50 + Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 51 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53 + Intellectual Property and Copyright Statements . . . . . . . . . . 54 1. Introduction The current e-mail infrastructure has the property that any host @@ -353,12 +353,12 @@ the client host is authorized or not. 2.5.2. Neutral - The domain owner has explicitly stated that they don't know whether - the IP address is authorized or not. A "Neutral" result MUST be - treated exactly like the "None" result; the distinction exists only - for informational purposes. Treating "Neutral" more harshly than - "None" will discourage domain owners from testing the use of SPF - records (see Section 9.1). + The domain owner has explicitly stated that they cannot or do not + want to assert whether the IP address is authorized or not. A + "Neutral" result MUST be treated exactly like the "None" result; the + distinction exists only for informational purposes. Treating + "Neutral" more harshly than "None" will discourage domain owners from + testing the use of SPF records (see Section 9.1). 2.5.3. Pass @@ -459,7 +459,7 @@ This document defines a new DNS RR of type SPF, type code to be determined. 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. + encoded as [US-ASCII]. RFC Editor Note: Please add the DNS RR type code once it has been allocated by the IANA. @@ -478,27 +478,22 @@ 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" - An SPF-compliant check SHOULD try to look up and use a record of the - SPF type first, before falling back to the TXT type. However, the - client MAY also look up both types in parallel. If, for a domain, - both types are obtained but their contents do not match, the SPF - client SHOULD return a "PermError" result. - 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 Records +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 +3.1.3. Multiple Strings in a Single DNS record - A text DNS record (either TXT and 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: + As defined in [RFC1035] sections 3.3 and 3.3.14, a single text DNS + record (either TXT and 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..." @@ -507,8 +502,8 @@ IN TXT "v=spf1 .... firstsecond string..." SPF or TXT records containing multiple strings are useful in order to - construct longer records which would otherwise exceed the maximum - length of a string within a TXT or SPF RR record. + construct records which would exceed the 255 byte maximum length of a + string within a single TXT or SPF RR record. 3.1.4. Record Size @@ -607,7 +602,8 @@ In accordance with how the records are published, see Section 3.1 above, a DNS query needs to be made for the name, querying - for either RR type TXT, SPF, or both. + 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 the DNS lookup returns a server failure (RCODE 2), or other error (RCODE other than 0 or 3), or the query times out, check_host() exits @@ -623,15 +619,18 @@ Starting with the set of records that were returned by the lookup, record selection proceeds in two steps: - 1. If any records of type SPF are in the set, then all records of - type TXT are discarded. - - 2. Records that do not begin with a version section of exactly + 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 a 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 there are both SPF and TXT records in the set and if they are + not identical, return a "PermError". + + 3. 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 @@ -647,7 +646,6 @@ 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 @@ -675,7 +673,8 @@ 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. + Terms that do not contain any of "=", ":" or "/" are mechanisms, as + defined in Section 5. As per the definition of the ABNF notation in [I-D.crocker-abnf- rfc2234bis], mechanism and modifier names are case-insensitive. @@ -694,11 +693,11 @@ mechanism processing ends and the exception value is returned. The possible prefixes, and the results they return are: - "+" Pass "-" Fail "~" SoftFail "?" Neutral + The prefix is optional and defaults to "+". When a mechanism matches and the prefix is "-", then a "Fail" result @@ -828,7 +827,7 @@ Example.net could say - "v=spf1 include:example.com include:example.org -all". + 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 @@ -1031,7 +1030,9 @@ 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. + the result of the current evaluation with the exception that if no + SPF record is found, or if the domain-spec is malformed, the result + is a "PermError" rather than "None". Note that the newly-queried domain may itself specify redirect processing. @@ -1077,18 +1078,18 @@ The fetched TXT record's strings are concatenated with no spaces, and then treated as an which is macro-expanded. This - final result is the explanation string. + 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 + 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. - - Implementations MAY limit the length of the resulting explanation - string to allow for other protocol constraints and/or reasonable - processing limits. The SPF client SHOULD make it clear when an - explanation string is coming from a third party, such as shown in + string "%{o} explains: " to the explanation, such as shown in Section 2.5.4. Suppose example.com has this record: @@ -1475,14 +1476,20 @@ 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. @@ -1525,7 +1532,6 @@ FROM" identity used for such e-mail uses the domain of the service provider, then the provider needs only to ensure that their sending host is authorized by their 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 @@ -1808,6 +1814,14 @@ Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 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", @@ -2236,5 +2250,5 @@ -Wong & Schlitt Expires November 21, 2005 [Page 53] +Wong & Schlitt Expires November 21, 2005 [Page 54]