--- draft-schlitt-spf-classic-01pre4.clean.txt 2005-04-28 11:18:52.000000000 -0500 +++ draft-schlitt-spf-classic-01pre5.clean.txt 2005-05-03 01:01:58.000000000 -0500 @@ -1,27 +1,26 @@ + Network Working Group M. Wong Internet-Draft W. Schlitt -Expires: October 27, 2005 April 28, 2005 +Expires: October 27, 2005 April 25, 2005 - Sender Policy Framework (SPF version 1): Authorizing Use of Domains - in E-MAIL +Sender Policy Framework (SPF) For Authorizing Use of Domains in E-MAIL, + version 1 draft-schlitt-spf-classic-01 Status of this Memo - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. + other groups may also distribute working documents as Internet- + Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any @@ -106,7 +105,7 @@ 9.2 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 33 9.3 Forwarding Services and Aliases . . . . . . . . . . . . . 33 9.4 Mail Services . . . . . . . . . . . . . . . . . . . . . . 35 - 9.5 MTA Relays . . . . . . . . . . . . . . . . . . . . . . . . 35 + 9.5 MTA Relays . . . . . . . . . . . . . . . . . . . . . . . . 36 10. Security Considerations . . . . . . . . . . . . . . . . . . 37 10.1 SPF-Authorized E-Mail May Still Be UBE . . . . . . . . . . 37 10.2 Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 37 @@ -118,8 +117,8 @@ 12.1 The SPF DNS Record Type . . . . . . . . . . . . . . . . . 41 12.2 The Received-SPF mail header . . . . . . . . . . . . . . . 41 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 - 13.1 Normative References . . . . . . . . . . . . . . . . . . . . 42 - 13.2 Informative References . . . . . . . . . . . . . . . . . . . 42 + 13.1 Normative References . . . . . . . . . . . . . . . . . . . 42 + 13.2 Informative References . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 43 A. Collected ABNF . . . . . . . . . . . . . . . . . . . . . . . . 44 B. Extended Examples . . . . . . . . . . . . . . . . . . . . . . 46 @@ -270,7 +269,9 @@ - the IP address of the SMTP client that is emitting the mail, either IPv4 or IPv6. + - the domain portion of the "MAIL FROM" or "HELO" identity. + - the "MAIL FROM" or "HELO" identity. Note that the argument may not be a well formed domain name. @@ -278,7 +279,6 @@ 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. - While 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, @@ -410,7 +410,7 @@ The example above in Section 3 might be published easily via this lines in a domain zone file: - example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all" + example.com. IN TXT "v=spf1 +mx a:colo.example.com -all" smtp-out.example.com. IN TXT "v=spf1 a -all" When publishing via TXT records, beware of other TXT records @@ -534,9 +534,11 @@ - the IP address of the SMTP client that is emitting the mail, either IPv4 or IPv6. + - the domain that provides the sought-after authorization - information; initially the domain portion of the "MAIL FROM" - or "HELO" identity. + information; initially the domain portion of the "MAIL FROM" or + "HELO" identity. + - the "MAIL FROM" or "HELO" identity. The domain portion of will usually be the same as the @@ -584,6 +586,7 @@ 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 "v=spf1" are discarded. Note that the version section is terminated either by a SP character or the end of the record. A @@ -610,6 +613,7 @@ 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 @@ -634,8 +638,8 @@ Terms that do not contain any of "=", ":" or "/" are mechanisms. - As per the definition of the ABNF notation in [RFC2234], mechanism - and modifier names are case-insensitive. + As per the definition of the ABNF notation in [I-D.crocker-abnf- + rfc2234bis], mechanism and modifier names are case-insensitive. 4.6.2 Mechanisms @@ -651,12 +655,13 @@ 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 is returned and the explanation string is computed as described in Section 6.2. @@ -678,14 +683,12 @@ "redirect" modifier, check_host() proceeds as defined in Section 6.1. Note that records SHOULD always either use a "redirect" modifier or - an "all" mechanism to explicitly terminate processing. - - For example: + 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 @@ -753,6 +756,7 @@ 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 @@ -1047,17 +1051,14 @@ Here are some examples of possible explanation TXT records at explain._spf.example.com: - Example.com mail should only be sent by its own servers. - + "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. - + "%{i} is not one of %{d}'s designated mail servers." -- a message with a little more info, including the IP address that failed the check - See http://%{d}/why.html?s=%{S}&i=%{I} - + "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 @@ -1080,7 +1081,6 @@ appear above any other Received-SPF headers in the message. The header has the format: - header = "Received-SPF:" [CFWS] result [FWS [comment]] [ key-value-list ] @@ -1111,11 +1111,16 @@ "envelope-from" or "helo" information so that the SPF results can be verified. 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 Other keys may be defined by SPF clients. Until a new key name @@ -1165,38 +1170,40 @@ 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 = l = local-part of o = domain of d = i = p = the validated domain name of - v = the string "in-addr" if is ipv4, or "ip6" if is - ipv6 + v = the string "in-addr" if is ipv4, or "ip6" if is ipv6 h = HELO/EHLO domain The following macro letters are only allowed 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.org + is incorrect and will cause check_host() to return a "PermError". Instead, say + -exists:%{ir}.sbl.spamhaus.org Optional transformers are: - *DIGIT : zero or more digits - 'r' : reverse value, splitting on dots by default + *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 @@ -1227,8 +1234,9 @@ 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 had no localpart, the - localpart was set to "postmaster" in initial processing (see Section - 4.3). + 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. @@ -1238,12 +1246,12 @@ 2.2. It is intended for humans to read. The "p" macro expands to the validated domain name of . The - procedure for finding the validated domain name is defined in Section - 5.5. If the is present in the list of validated domains, it - SHOULD be used. Otherwise, if a subdomain of the 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. + procedure for finding the validated domain name is defined in + Section 5.5. If the is present in the list of validated + domains, it SHOULD be used. Otherwise, if a subdomain of the + 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 @@ -1290,6 +1298,7 @@ The IPv6 SMTP client IP is 5f05:2000:80ad:5800::1. The PTR domain name of the client IP is mx.example.org. + macro expansion ------- ---------------------------- %{s} strong-bad@email.example.com @@ -1307,7 +1316,6 @@ %{lr-} bad.strong %{l1r-} strong - macro-string expansion -------------------------------------------------------------------- %{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com @@ -1349,8 +1357,10 @@ 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 + 9.2 Mailing Lists Mailing lists must be aware of how they re-inject mail that is sent @@ -1382,58 +1392,76 @@ There are three places that techniques can be used to ameliorate this problem. + 1. The beginning, when e-mail is first sent. + * "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.org ?all" + This would cause a lookup on an anti-spam DNS blocklist (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. + * 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 which validates the localpart. While this requires an extra DNS lookup, this only happens when the e-mail would otherwise be rejected as not coming from a known, good source. + * 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" + * 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. + * 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. + * 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"). + 3. The end, when e-mail is received. + * If the owner of the external mailbox wishes to trust the forwarding service, they can direct the external mailbox's MTA to skip SPF tests when the client host belongs to the forwarding service. + * Tests against other identities, such as the "HELO" identity, may be used to override a failed test against the "MAIL FROM" identity. + * 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, @@ -1447,7 +1475,6 @@ 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. - 9.5 MTA Relays The authorization check generally precludes the use of arbitrary MTA @@ -1496,17 +1523,19 @@ results. This could include returning "Pass" for an value where the actual domain's record would evaluate to "Fail". See [RFC3833] for a description of the DNS weaknesses. + The client IP address, , 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.3 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 of a - Denial-of-Service (DoS) attack. The processing limits outlined here - are designed to prevent attacks such as: + malicious parties could use the protocol as an avenue of a Denial-of- + Service (DoS) attack. The processing limits outlined here are + designed to prevent attacks such as: o A malicious party could create an SPF record with many references to a victim's domain, send many e-mails to different SPF clients @@ -1522,6 +1551,7 @@ 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 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 @@ -1562,8 +1592,8 @@ 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: + 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" @@ -1650,14 +1680,14 @@ Permanent Message Header Field Registry. The following is the registration template: - o Header field name: Received-SPF - o Applicable protocol: mail - o Status: standard - o Author/Change controller: wayne@schlitt.net - o Specification document(s): this Internet Draft - o (Note to RFC Editor: Replace this with RFC YYYY (RFC number of + Header field name: Received-SPF + Applicable protocol: mail + Status: standard + Author/Change controller: wayne@schlitt.net + Specification document(s): this Internet Draft + (Note to RFC Editor: Replace this with RFC YYYY (RFC number of this spec)) - o Related information: http://spf.mehnle.net/ + Related information: http://spf.mehnle.net/ 13. References 13.1 Normative References @@ -1674,40 +1704,38 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. + [I-D.crocker-abnf-rfc2234bis] + Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", draft-crocker-abnf-rfc2234bis-00 + (work in progress), March 2005. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. - [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April - 2001. + [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, + April 2001. [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 + [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. + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. 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. + [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, + August 1996. [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. @@ -1730,7 +1758,7 @@ Meng Weng Wong Singapore - EMail: mengwong+spf@pobox.com + Email: mengwong+spf@pobox.com URI: http://spf.pobox.com/ @@ -1739,7 +1767,7 @@ Lincoln Nebraska, NE 68506 United States of America - EMail: wayne@schlitt.net + Email: wayne@schlitt.net URI: http://www.schlitt.net/spf/ Appendix A. Collected ABNF @@ -1747,9 +1775,10 @@ fragments in the preceding text are to be resolved in favor of this grammar. - See [RFC2234] 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". + See [I-D.crocker-abnf-rfc2234bis] 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" @@ -1789,6 +1818,7 @@ toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum ; LDH rule (See [RFC3696]) alphanum = ALPHA / DIGIT + explain-string = *( macro-string / SP ) macro-string = *( macro-expand / macro-literal ) @@ -1889,10 +1919,10 @@ -- 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 IP is valid and in - example.com) - -- sending host 192.0.2.140 fails (reverse IP is valid, but not in - example.com) + -- 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 @@ -1911,13 +1941,16 @@ 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. + B.3 DNSBL Style Example Imagine that, in addition to the domain records listed above, there