--- draft-schlitt-spf-classic-01pre7.clean.txt 2005-05-18 00:01:27.000000000 -0500 +++ draft-schlitt-spf-classic-01.clean.txt 2005-05-20 01:37:48.000000000 -0500 @@ -3,7 +3,7 @@ Network Working Group M. Wong Internet-Draft W. Schlitt -Expires: November 19, 2005 May 18, 2005 +Expires: November 21, 2005 May 20, 2005 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-MAIL, @@ -33,7 +33,7 @@ The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on November 19, 2005. + This Internet-Draft will expire on November 21, 2005. Copyright Notice @@ -46,7 +46,7 @@ host can use as the reverse-path of a message. This document describes version 1 of the SPF protocol, whereby a domain can explicitly authorize the hosts that are allowed to use its domain - name in a reverse-path, and a way for receiving hosts to check such + name in a reverse-path, and a receiving host can check such authorization. Table of Contents @@ -134,7 +134,7 @@ 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 to. Hosts can do this at a variety of levels: in + name it wants. Hosts can do this at a variety of levels: in particular, the session, the envelope, and the mail headers. While this feature is desirable in some circumstances, it is a major obstacle to reducing Unsolicited Bulk E-mail (UBE, aka "spam"). @@ -144,36 +144,36 @@ 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 SPF records about which hosts are - permitted to use their names, and compliant mail receivers use the - published SPF records to test the authorization of hosts using a - given "HELO" or "MAIL FROM" identity during a mail transaction. - - An additional benefit to mail receivers is that when the use of an - identity is verified, then local policy decisions about the mail can - be made on the basis of the 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, then local - policy can take stronger action against such e-mail, such as - rejecting it. + Compliant domain holders publish 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 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. State of this draft This draft version attempts to resolve all known issues and address - all comments received from the IESG review of by 2005/02/17 as well + all comments received from the IESG review of 2005/02/17, as well reviews from the namedroppers, ietf-smtp, ietf-822 and spf-discuss - mailing lists. The SPF project DOES NOT expects IESG to review this - version, instead a two week pseudo last call will be put out to - collect any final changes. After that, an new I-D will be submitted - with the expectation of an IESG review. + mailing lists. The SPF project DOES NOT expect the IESG to review + this version. Instead, a two week pseudo last call will be put out + to collect any final changes. After that, a new I-D will be + submitted with the expectation of an IESG review. - Please check the Change log in Appendix C before proposing changes as - it is possible that your idea has already been discussed. Please + Please check the Change log in Appendix C before proposing changes, + as it is possible that your idea has already been discussed. Please post comments on the spf-discuss@v2.listbox.com mailing list or email them directly to the author. - I am sorry for the length of this I-D, I have not had time to make it + I am sorry for the length of this I-D; I have not had time to make it shorter. RFC Editor Note: Please remove this section for the final publication @@ -190,7 +190,7 @@ discussed and debated in development forums. The goal of this document is to clearly document the protocol defined - by earlier drafts specifications of SPF as used in existing + 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 deployments may differ from, and build upon, this work. It is hoped @@ -203,13 +203,14 @@ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. - This document is concerned with a 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. + 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 @@ -250,15 +251,15 @@ 2.3. Publishing Authorization - An SPF compliant domain MUST publish a valid SPF record as described + 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 MTAs it specifies. + the "HELO" and "MAIL FROM" identities by the MTAs it specifies. It is RECOMMENDED that domains publish SPF records that 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 for domain names that shouldn't be used in sender mailboxes. + 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 @@ -290,11 +291,12 @@ 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 - implement and evaluate the check_host() function (Section 4) - correctly. While 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. + 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. While 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: @@ -305,7 +307,7 @@ - the "MAIL FROM" or "HELO" identity. - Note that the argument may not be a well formed domain name. + Note that the 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" @@ -314,15 +316,16 @@ 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, - especially in the "MAIL FROM". In order to prevent the circumvention - of SPF records, rejecting e-mail from invalid domains should be - considered. - - Care must be taken to correctly extract the from the - 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. + 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 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 @@ -333,7 +336,7 @@ returned directly to the sending server by way of SMTP replies. Performing the authorization after the SMTP transaction has finished - may face problems, such as: 1) It may be difficult to accurately + may cause problems, such as: 1) It may be difficult to accurately extract the required information from potentially deceptive headers. 2) Legitimate email may fail because the sender's policy may have since changed. @@ -346,8 +349,8 @@ 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 if the - client host is authorized or not. + the given identity. The checking software cannot ascertain whether + the client host is authorized or not. 2.5.2. Neutral The domain owner has explicitly stated that they don't know whether @@ -394,16 +397,16 @@ Since the domain has discouraged the use of this host, receivers MAY try to inform either the sender or the recipient of the e-mail. For - example, the recipient's MUA could highlight the "SoftFail" status. - Or the MTA could give the sender a message using a technique called + example, the recipient's MUA could highlight the "SoftFail" status, + or the 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 was received, + (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 when performing the check. Checking software can + 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 @@ -412,7 +415,7 @@ 2.5.7. PermError A "PermError" result means that the domain's published records - couldn't be correctly interpreted. Checking software SHOULD treat + couldn't be correctly interpreted. Checking software should treat this result similar to the "SoftFail" 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. @@ -459,10 +462,10 @@ 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 a RR type reserved for this purpose. + 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 + 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 just publishing one @@ -471,11 +474,11 @@ 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 + 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. + 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. @@ -542,7 +545,7 @@ *.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 + 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 @@ -551,7 +554,7 @@ 4. The check_host() Function The check_host() function fetches SPF records, parses them, and - interprets them to determine if a particular host is or is not + 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. @@ -727,8 +730,8 @@ Several of these mechanisms and modifiers have a section. The 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 + 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 in the rest of this document. Note: The result of the macro expansion is not subject to any further @@ -750,8 +753,8 @@ include Designated sender mechanisms are used to designate a set of - addresses as being permitted or not to use the for sending - mail. + addresses as being permitted or not permitted to use the for + sending mail. a mx @@ -815,21 +818,21 @@ 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 + 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. + administratively-independent domains example.com and example.org. Example.net could say "v=spf1 include:example.com include:example.org -all". - That would direct check_host() to, in effect, check the records of + 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". - Whether this mechanism matches or not, or throws an error depends on - the result of the recursive evaluation of check_host(): + Whether this mechanism matches, does not match, or throws an error, + depends on the result of the recursive evaluation of check_host(): +---------------------------------+---------------------------------+ | A recursive check_host() result | Causes the "include" mechanism | | of: | to: | @@ -880,7 +883,7 @@ check_host() first performs an MX lookup on the . Then it performs an address lookup on each MX name returned. The is compared to each returned IP address. To prevent DoS attacks, more - than 10 MX names MUST NOT be looked up during the evaluation of a + 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. @@ -893,8 +896,8 @@ 5.5. "ptr" - This mechanism tests if the DNS reverse mapping for exists and - correctly points to a domain name within a particular domain. + This mechanism tests whether the DNS reverse mapping for exists + and correctly points to a domain name within a particular domain. PTR = "ptr" [ ":" domain-spec ] @@ -944,7 +947,8 @@ 5.6. "ip4" and "ip6" - These mechanisms test if is contained within a given IP network. + These mechanisms test whether is contained within a given IP + network. IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] @@ -990,7 +994,7 @@ decisions possible at the level of the user and client IP address. This mechanism enables queries that mimic the style of tests that - existing DNSBL lists use. + existing DNSBLs use. 6. Modifier Definitions Modifiers are name/value pairs that provide additional information. @@ -1003,14 +1007,14 @@ they do, then check_host() exits with a result of "PermError". Unrecognized modifiers MUST be ignored no matter where in a record, - nor how often. This allows implementations of this document to + or how often. This allows implementations of this document to gracefully handle records with modifiers that are defined in other specifications. 6.1. redirect: Redirected Query If all mechanisms fail to match, and a "redirect" modifier is - present, then processing proceeds as follows. + present, then processing proceeds as follows: redirect = "redirect" "=" domain-spec @@ -1022,7 +1026,7 @@ The result of this new evaluation of check_host() is then considered the result of the current evaluation. - Note that the newly queried domain may itself specify redirect + Note that the newly-queried domain may itself specify redirect processing. This facility is intended for use by organizations that wish to apply @@ -1080,7 +1084,7 @@ explanation string is coming from a third party, such as shown in Section 2.5.4. - Suppose example.com has this record + Suppose example.com has this record: v=spf1 mx -all exp=explain._spf.%{d} @@ -1146,7 +1150,7 @@ conveying supporting information for the result, such as , and . - The following key-value-pairs are designed for later machine parsing. + 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 the "client-ip", "helo", and, if the "MAIL FROM" identity was checked, the "envelope-from". @@ -1170,8 +1174,8 @@ becomes widely accepted, new key names should start with "x-". SPF clients MUST make sure that the Received-SPF header does not - contain invalid characters, is excessively long, or contains - malicious data that has been provided by the sender. + 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: @@ -1305,8 +1309,8 @@ The "t" macro expands to the decimal representation of the approximate number of seconds since the Epoch (Midnight, January 1st, - 1970, UTC). This is the same value as returned by the POSIX time() - function in most standards compliant libraries. + 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 @@ -1502,11 +1506,11 @@ 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. + generally-recognized forwarding services could be employed. 9.4. Mail Services - Service providers that offer mail services to third party domains, + Service providers that offer mail services to third-party domains, such as sending of bulk mail, may have 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 @@ -1549,17 +1553,17 @@ 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 of a Denial-of- - Service (DoS) attack. The processing limits outlined here are + 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: 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 - and 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 is generated by the - DNS queries. Using SPF clients also allows the attacker to hide - the true source of the attack. + 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 While implementations of check_host() are supposed to limit the number of DNS lookups, malicious domains could publish records @@ -1591,7 +1595,7 @@ 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 implementation SHOULD limit the total amount of data obtained + 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 @@ -1606,7 +1610,7 @@ 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 + that require less DNS information and placing lower-cost mechanisms earlier in the SPF record. For example, consider a domain set up as: @@ -1622,21 +1626,21 @@ hosts. Evaluating for "b.example.com" only requires the A records. Evaluating for "c.example.com" requires none. - However, there may be administrative considerations: Using "a" over + 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. 10.2. SPF-Authorized E-Mail May Be UBE The "MAIL FROM" and "HELO" identity authorizations must not be - construed to provide more assurance than it does. It is entirely + construed to provide more assurance than they do. It is entirely possible for a malicious sender to inject a message using their own domain in the identities used by SPF, to have that domain's SPF record authorize the sending host, and yet the message content can - easily claim other identities in the headers. 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), the user may be lulled into a false sense of security. + easily claim other identities in the headers. 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), 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 @@ -1667,9 +1671,8 @@ 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 [I-D.gellens-submit-bis] section 6.1). - Another means check the authorization of the identity of individual - users is message cryptography such as PGP ([RFC2440]) or S/MIME - ([RFC3851]). + Another means to verify the identity of individual users is message + cryptography such as PGP ([RFC2440]) or S/MIME ([RFC3851]). 10.5. Untrusted Information Sources @@ -1677,14 +1680,14 @@ 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 URLs that may be malicious, - offensive and/or have misleading text. This is probably less of a - concern than it may initially seem since such messages are returned - to the sender, and the source is the SPF record published by the - domain in the identity claimed by that very sender. To put it - another way, 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. + 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 source is the SPF record published by the domain in the + identity claimed by that very sender. To put it another way, 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. 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: mail @@ -2062,13 +2065,13 @@ Version 01 - o Updated IETF boilerplate to BCP 79. + o IETF boilerplate was updated to BCP 79. - o Added version number to title (IESG review) + o A version number was added to the title. (IESG review) - o Many grammatical, typographical and spelling errors corrected, - along with rephrasing sentences to make the intent and meaning - clearer. + o Many grammatical, typographical and spelling errors were + corrected, along with rephrasing sentences to make the intent and + meaning clearer. o Sections have been re-ordered in so that they conform to the instructions2authors.txt document. All required sections and @@ -2077,19 +2080,19 @@ Considerations is such an important part of the spec, it has been moved before the Acknowledgement section. - o HELO identity checking has been changed from "MAY" to + o The HELO identity checking has been changed from "MAY" to "RECOMMENDED". - o Removed e-mail receiver policy definition on how to handle HELO - checking. It was copied incorrectly from draft-mengwong-spf-01, - changing its meaning. + o The e-mail receiver policy definition on how to handle HELO + checking was removed. It was copied incorrectly from + draft-mengwong-spf-01, changing its meaning. - o Note added that when changing SPF records, there needs to be a - transitional period to prevent incorrect results. + o A note was added that when changing SPF records, there needs to be + a transitional period to prevent incorrect results. o The RECOMMENDATION not to use other identities with version 1 SPF records has been clarified. Example cases where checking other - identities would cause incorrect results have been cited. (IESG + identities will cause incorrect results have been cited. (IESG review) o The "zone cut" method of determining if there is an SPF record at @@ -2097,8 +2100,8 @@ often and could not always be easily done. (IESG/namedroppers' review) - o Note added that receivers should consider rejecting e-mail for - non-existent domains in order to prevent circumvention of SPF + o A note was added that receivers should consider rejecting e-mail + for non-existent domains in order to prevent circumvention of SPF policies. This is due to the remove of "zone cuts". (namedroppers' review) o The RECOMMENDATION to perform SPF checks during the SMTP session @@ -2117,8 +2120,8 @@ o A few host names/IP addresses were fixed to use appropriate ones for I-Ds. - o Added a definition of what to should be done if there are syntax - errors in the explanation string. (Use the default.) + o A definition of what to should be done if there are syntax errors + in the explanation string was added. (E.g. use the default.) o Section 10 "Security Considerations" has been broken up into subsections and reorganized. @@ -2212,5 +2215,5 @@ -Wong & Schlitt Expires November 19, 2005 [Page 53] +Wong & Schlitt Expires November 21, 2005 [Page 53]