--- draft-schlitt-spf-classic-02pre2.clean.txt 2005-06-05 15:13:24.000000000 -0500 +++ draft-schlitt-spf-classic-02pre3.clean.txt 2005-06-06 10:41:23.000000000 -0500 @@ -3,12 +3,12 @@ Network Working Group M. Wong Internet-Draft W. Schlitt -Expires: November 21, 2005 May 20, 2005 +Expires: December 8, 2005 June 6, 2005 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-MAIL, version 1 - draft-schlitt-spf-classic-01 + draft-schlitt-spf-classic-02 Status of this Memo @@ -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 21, 2005. + This Internet-Draft will expire on December 8, 2005. Copyright Notice @@ -45,8 +45,8 @@ 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 SPF protocol, whereby a domain can explicitly authorize the hosts - that are allowed to use its domain name, and a receiving host can + the 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 @@ -128,8 +128,10 @@ 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 + C.1. Changes in Version -02 . . . . . . . . . . . . . . . . . . 51 + C.2. Changes in Version -01 . . . . . . . . . . . . . . . . . . 52 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 55 + Intellectual Property and Copyright Statements . . . . . . . . . . 56 1. Introduction The current e-mail infrastructure has the property that any host @@ -163,15 +165,12 @@ This draft version attempts to resolve all known issues and address 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 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. + mailing lists both in January and in May. 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. + post comments on the spf-discuss@v2.listbox.com mailing list or + e-mail them directly to the author. I am sorry for the length of this I-D; I have not had time to make it shorter. @@ -179,7 +178,6 @@ RFC Editor Note: Please remove this section for the final publication of the document. It has been inspired by draft-ietf-tools-draft-submission-09.txt. - 1.2. Protocol Status SPF has been in development since the Summer of 2003, and has seen @@ -263,7 +261,7 @@ 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 email has been checked. + legitimate e-mail has been checked. 2.4. Checking Authorization @@ -314,7 +312,7 @@ 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 + 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 @@ -338,7 +336,7 @@ Performing the authorization after the SMTP transaction has finished 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 + 2) Legitimate e-mail may fail because the sender's policy may have since changed. Generating non-delivery notifications to forged identities that have @@ -363,9 +361,10 @@ 2.5.3. Pass A "Pass" result means that the client is authorized to inject mail - with the given identity. Further policy checks, such as reputation, - or black and/or white listing, can now proceed with confidence in the - identity. + 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 @@ -444,8 +443,8 @@ 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 is used. - The example above in Section 3 might be published easily via this - lines in a domain zone file: + The example above in Section 3 might be published via this 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" @@ -489,7 +488,7 @@ 3.1.3. Multiple Strings in a Single DNS record - As defined in [RFC1035] sections 3.3 and 3.3.14, a single text DNS + As defined in [RFC1035] sections 3.3.14 and 3.3, 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 @@ -617,7 +616,7 @@ version = "v=spf1" Starting with the set of records that were returned by the lookup, - record selection proceeds in two steps: + record selection proceeds in three steps: 1. Records that do not begin with a version section of exactly "v=spf1" are discarded. Note that the version section is @@ -626,7 +625,7 @@ must be discarded. 2. If there are both SPF and TXT records in the set and if they are - not identical, return a "PermError". + not all identical, return a "PermError". 3. If any records of type SPF are in the set, then all records of type TXT are discarded. @@ -658,8 +657,8 @@ terms = *( 1*SP ( directive / modifier ) ) - directive = [ prefix ] mechanism - prefix = "+" / "-" / "?" / "~" + directive = [ qualifier ] mechanism + qualifier = "+" / "-" / "?" / "~" mechanism = ( all / include / A / MX / PTR / IP4 / IP6 / exists ) modifier = redirect / explanation / unknown-modifier @@ -687,22 +686,22 @@ When a mechanism is evaluated, one of three things can happen: it can match, it can not match, or it can throw an exception. - If it matches, processing ends and the prefix value is returned as + 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 prefixes, and the results they return are: + The possible qualifiers, and the results they return are: "+" Pass "-" Fail "~" SoftFail "?" Neutral - The prefix is optional and defaults to "+". + The qualifier 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. + 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. @@ -961,10 +960,11 @@ dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] ip4-network = ... - qnum = 2*1DIGIT - / "1" 2DIGIT - / "2" ("0" / "1" / "2" / "3" / "4" ) DIGIT - / "25" ("0" / "1" / "2" / "3" / "4" / "5" ) + 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 = ; e.g. 2001:DB8::CD30 @@ -1000,7 +1000,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 DNSBLs use. + existing anti-spam DNS blacklists (DNSBL) use. 6. Modifier Definitions Modifiers are name/value pairs that provide additional information. @@ -1009,8 +1009,8 @@ 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 modifiers MUST NOT appear in a record more than once each. If - they do, then check_host() exits with a result of "PermError". + 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 @@ -1031,7 +1031,7 @@ 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 domain-spec is malformed, the result + 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 @@ -1273,8 +1273,8 @@ specify delimiter characters which 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". + address was 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 @@ -1547,8 +1547,8 @@ Within an organization, MTA relays can be effectively deployed. However, for purposes of this document, such relays are effectively - transparent. The "MAIL FROM" identity authorization check is a check - between border MTAs of different domains. + 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, @@ -1600,15 +1600,16 @@ 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. 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. - + that do DNS lookups to at most 10 per SPF check, including any + lookups caused by the use of the "include" mechanism or the + "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. @@ -1659,6 +1660,7 @@ 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 @@ -1707,6 +1709,7 @@ 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 @@ -1715,8 +1718,8 @@ 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 - email and then later generates a DSN to a forged address, or when an - email forwarder does not direct the DSN back to the original sender. + 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 @@ -1770,11 +1773,16 @@ Header field name: Received-SPF Applicable protocol: mail ([RFC2822]) Status: standard - Author/Change controller: wayne@schlitt.net + (Note to RFC Editor: Replace the status with the final + determination by the IESG) + Author/Change controller: IETF Specification document(s): this Internet Draft (Note to RFC Editor: Replace this with RFC YYYY (RFC number of this spec)) - Related information: http://spf.mehnle.net/ + Related information: + Requesting SPF Council review of any proposed changes and + additions to this field is recommended. For information about SPF + Council see http://spf.mehnle.net/ 13. References 13.1 Normative References @@ -1879,8 +1887,8 @@ terms = *( 1*SP ( directive / modifier ) ) - directive = [ prefix ] mechanism - prefix = "+" / "-" / "?" / "~" + directive = [ qualifier ] mechanism + qualifier = "+" / "-" / "?" / "~" mechanism = ( all / include / A / MX / PTR / IP4 / IP6 / exists ) @@ -1903,10 +1911,11 @@ dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] ip4-network = ... - qnum = 2*1DIGIT - / "1" 2DIGIT - / "2" ("0" / "1" / "2" / "3" / "4" ) DIGIT - / "25" ("0" / "1" / "2" / "3" / "4" / "5" ) + 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 = ; e.g. 2001:DB8::CD30 @@ -2098,7 +2107,75 @@ RFC Editor Note: This section is to be removed during the final publication of the document. - Version 01 +C.1. Changes in Version -02 + + o The abstract notes that SPF-classic covers both the HELO and MAIL + FROM identities. (ietf-822 review) + + o In section 2.3 "Publishing Authorization", it now makes it clear + that publishing is optional. (ietf-smtp review) + + o The definition of the "SoftFail" result have been recast from + Receiver Policy to Sender Policy. + + o The definitions of Neutral, Pass and PermError have been updated/ + clarified to more correctly reflect the semantics of + draft-mengwong-spf-01. + + o A note to the RFC editor was made indicating that the SPF DNS RR + type number should be added to the draft once the IANA has made an + allocation. + + o The ip4-network ABNF has been fixed to give the ABNF of the + dotted-quad format, rather than just using words to explain it. + + o The ABNF for the Received-SPF header now shows that it ends with a + CRLF. (ietf-822 review) + + o The new, optional, "scope" keyword-value pair has been renamed to + "identity". + + o The "exp=" modifier no longer counts toward the DoS DNS lookup + limits. + + o In section 10.5 "Untrusted Information Sources", the explanation + about explanation strings going to only the sender has been fixed + to note that, in some cases, it can go to other people. (ietf-822 + review) + + o Sections 3.1.2 and 3.1.3 were updated to make the distinction + between "multiple TXT RRs" and "multiple strings within a TXT" + clearer. (ietf-822 review) + + o A normative reference to US-ASCII has been added. + o Text describing how to lookup and process the SPF records has been + removed from section 3.1.1 "DNS Resource Record Types" and merged + into similar text in sections 4.4 "Record Lookup" and 4.5 + "Selecting Records" + + o Section 4.5 "Selecting Records" has been updated to give an + algorithm that says to return a PermError when it discovers that + SPF and TXT records don't match. + + o In section 6.1 "redirect: Redirected Query", the semantics have + been changed to specify a result of PermError instead of None in + cases where the target domain does not have any SPF records. It + makes no sense to return None, that is "no SPF records found", + when SPF records were found. + + o In section 6.2 "exp: Explanation", it is explained that the record + must be in US-ASCII due to requirements of RFC2821. + + o In section 6.2 "exp: Explanation", the duplicate warning about + source being from a third party was deleted. + + o A note has been added to section 9.3.1.2 warning about domain + labels being over 63 characters. + + o The "prefix" ABNF rule was renamed to "qualifier" to reflect the + semantics of the rule, rather than the syntax. + +C.2. Changes in Version -01 o IETF boilerplate was updated to BCP 79. @@ -2117,7 +2194,6 @@ o The HELO identity checking has been changed from "MAY" to "RECOMMENDED". - 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. @@ -2139,6 +2215,7 @@ 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 has been clarified and strengthened. @@ -2147,7 +2224,7 @@ o The suggested e-mail receiver policy when a "PermError" is encountered has been changed to be, effectively, the same - semantics as were in draft-mengwong-01. (MAAWG review) + semantics as were in draft-mengwong-spf-01. (MAAWG review) o ABNF cleaned up to pass Bill Fenner's checker and not just the one at http://www.apps.ietf.org/abnf.html @@ -2163,11 +2240,10 @@ o Section 7.1 "Process Limits" has been merged into the similar language in the "Security Considerations" section. - o The ABNF for the Received-SPF e-mail header has been made to be - more compatible with draft-mengwong-01. It was fixed to require - whitespace when needed and to show where the suggested comment - should be added to the header. + more compatible with draft-mengwong-spf-01. It was fixed to + require whitespace when needed and to show where the suggested + comment should be added to the header. o The IANA Considerations section now has the required information to document the Received-SPF header. @@ -2250,5 +2326,5 @@ -Wong & Schlitt Expires November 21, 2005 [Page 54] +Wong & Schlitt Expires December 8, 2005 [Page 56]