--- draft-schlitt-spf-classic-01pre6.clean.txt 2005-05-13 17:21:32.000000000 -0500 +++ draft-schlitt-spf-classic-01pre7.clean.txt 2005-05-18 00:01:27.000000000 -0500 @@ -3,10 +3,10 @@ Network Working Group M. Wong Internet-Draft W. Schlitt -Expires: November 14, 2005 May 13, 2005 +Expires: November 19, 2005 May 18, 2005 -Sender Policy Framework (SPF) For 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 @@ -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 14, 2005. + This Internet-Draft will expire on November 19, 2005. Copyright Notice @@ -51,8 +51,9 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Protocol Status . . . . . . . . . . . . . . . . . . . . . 4 - 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. State of this draft . . . . . . . . . . . . . . . . . . . 4 + 1.2. Protocol Status . . . . . . . . . . . . . . . . . . . . . 5 + 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. The HELO Identity . . . . . . . . . . . . . . . . . . . . 6 2.2. The MAIL FROM Identity . . . . . . . . . . . . . . . . . . 6 @@ -60,11 +61,11 @@ 2.4. Checking Authorization . . . . . . . . . . . . . . . . . . 7 2.5. Interpreting the Result . . . . . . . . . . . . . . . . . 8 2.5.1. None . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 2.5.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.5.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 9 2.5.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5.5. SoftFail . . . . . . . . . . . . . . . . . . . . . . . 9 - 2.5.6. TempError . . . . . . . . . . . . . . . . . . . . . . 9 + 2.5.6. TempError . . . . . . . . . . . . . . . . . . . . . . 10 2.5.7. PermError . . . . . . . . . . . . . . . . . . . . . . 10 3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Publishing . . . . . . . . . . . . . . . . . . . . . . . . 11 @@ -96,7 +97,7 @@ 6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 24 6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 24 6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 25 - 7. The Received-SPF header . . . . . . . . . . . . . . . . . . . 27 + 7. The Received-SPF header field . . . . . . . . . . . . . . . . 27 8. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.1. Macro definitions . . . . . . . . . . . . . . . . . . . . 29 8.2. Expansion Examples . . . . . . . . . . . . . . . . . . . . 32 @@ -126,8 +127,9 @@ B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 48 B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 49 B.4. Multiple Requirements Example . . . . . . . . . . . . . . 49 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 50 - Intellectual Property and Copyright Statements . . . . . . . . . . 51 + Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 50 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 52 + Intellectual Property and Copyright Statements . . . . . . . . . . 53 1. Introduction The current e-mail infrastructure has the property that any host @@ -156,7 +158,29 @@ policy can take stronger action against such e-mail, such as rejecting it. -1.1. Protocol Status +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 + 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. + + 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 + shorter. + + 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 deployment beyond the developers beginning in December, 2003. The @@ -173,7 +197,7 @@ that we have nonetheless captured the common understanding of SPF version 1. -1.2. Terminology +1.3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this @@ -236,6 +260,10 @@ Domain holders may publish SPF records that explicitly authorize no hosts for domain names that shouldn't be used in sender mailboxes. + 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. + 2.4. Checking Authorization A mail receiver can perform a set of SPF checks for each mail message @@ -246,11 +274,11 @@ 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 record owner, checking other + 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, most mailing lists rewrite the "MAIL FROM" identity (see - Section 9.2), but some do not change any other identities in the + 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.1.2 is another example. Documents that define other identities should define the method for explicit approval. @@ -273,7 +301,6 @@ - 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. @@ -297,25 +324,23 @@ (see [RFC1983]). These archaic features have been maliciously used to bypass security systems. - This 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 server by way of SMTP replies. - - Software can also perform the authorization after the corresponding - SMTP transaction has completed. However there are two problems with - this approach: 1) It may be difficult to accurately extract all the - required information such as client IP address and HELO domain name. - 2) If the authorization fails, then generating a non-delivery - notification to the alleged sender is problematic due to the large - number of forged e-mails on the Internet today. Such an action would - go against the explicit wishes of the alleged sender. - 2.5. Interpreting the Result - The check_host() function returns one of several result codes. This - section describes how software that performs the authorization must - interpret the results. If the check is being performed during the - SMTP mail transaction, it also describes how to respond. + 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 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 + extract the required information from potentially deceptive headers. + 2) Legitimate email 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 @@ -323,13 +348,14 @@ 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. - 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. + 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 @@ -786,7 +812,7 @@ 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", "call", "eval, etc.) + 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 @@ -1076,7 +1102,7 @@ from the target domain MUST NOT be used. In contrast, when executing a "redirect" modifier, an exp= modifier from the original domain MUST NOT be used. -7. The Received-SPF header +7. The Received-SPF header field It is RECOMMENDED that SMTP receivers record the result of SPF processing in the message headers. If an SMTP receiver chooses to do @@ -1144,8 +1170,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 contain malicious - data that has been provided by the sender. + contain invalid characters, is excessively long, or contains + malicious data that has been provided by the sender. Examples of various header styles that could be generated: @@ -1380,7 +1406,7 @@ 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 requirement in + 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. While the reasons for changing the @@ -1574,7 +1600,7 @@ 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 authentication SHOULD be "TempError". + 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 @@ -1634,16 +1660,16 @@ 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 authenticate, through SPF, - the use of specific e-mail addresses by individual users of the same - MTA. + 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 [RFC2476] section 6.1). Another means to - authenticate the identity of individual users is message cryptography - such as PGP ([RFC2440]) or S/MIME ([RFC2633]). + 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]). 10.5. Untrusted Information Sources @@ -1773,21 +1799,24 @@ [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. - [RFC2476] Gellens, R. and J. Klensin, "Message Submission", - RFC 2476, December 1998. + [I-D.gellens-submit-bis] + Gellens, R. and J. Klensin, "Message Submission for Mail", + draft-gellens-submit-bis-02 (work in progress), + April 2005. [RFC2554] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. - [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", - RFC 2633, June 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. + [RMX] Danish, H., "The RMX DNS RR Type for light weight sender authentication", October 2003. @@ -2026,6 +2055,96 @@ 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. +Appendix C. Change Log + + RFC Editor Note: This section is to be removed during the final + publication of the document. + + Version 01 + + o Updated IETF boilerplate to BCP 79. + + o Added version number to title (IESG review) + + o Many grammatical, typographical and spelling errors 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 + arrangements are included, and only the "Security Considerations" + section is not in the suggested order. Since the Security + 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 + "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 Note 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 + review) + + o The "zone cut" method of determining if there is an SPF record at + the top of the zone has been removed. It wasn't implemented very + 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 + 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. + + o Note added about the consequences of treating "Neutral" results + worse than "None". + + 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) + + o ABNF cleaned up to pass Bill Fenner's checker and not just the one + at http://www.apps.ietf.org/abnf.html + + 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 Section 10 "Security Considerations" has been broken up into + subsections and reorganized. + + 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. + + o The IANA Considerations section now has the required information + to document the Received-SPF header. + + o A new, optional, "scope" keyword has added to the Received-SPF + header. + + o The non-normative Section 9.3 "Forwarding Services and Aliases" + has been expanded to more thoroughly cover the subject. + + o New Security Considerations sections on "Privacy Exposure" and + "Cross-User Forgery" have been added. + + o A new example of an SPF policy with a non-obvious implementation + has been added. Authors' Addresses Meng Weng Wong @@ -2093,5 +2212,5 @@ -Wong & Schlitt Expires November 14, 2005 [Page 51] +Wong & Schlitt Expires November 19, 2005 [Page 53]