diff --git a/doc/rfc/index b/doc/rfc/index index 6d8e3d255a..2a7ebaf04d 100644 --- a/doc/rfc/index +++ b/doc/rfc/index @@ -107,3 +107,5 @@ 4367: What's in a Name: False Assumptions about DNS Names 4398: Storing Certificates in the Domain Name System (DNS) 4431: The DNSSEC Lookaside Validation (DLV) DNS Resource Record +4408: Sender Policy Framework (SPF) for Authorizing Use of Domains + in E-Mail, Version 1 diff --git a/doc/draft/draft-schlitt-spf-classic-02.txt b/doc/rfc/rfc4408.txt similarity index 59% rename from doc/draft/draft-schlitt-spf-classic-02.txt rename to doc/rfc/rfc4408.txt index 3bd9594c6d..bc1b3f539c 100644 --- a/doc/draft/draft-schlitt-spf-classic-02.txt +++ b/doc/rfc/rfc4408.txt @@ -1,43 +1,77 @@ + + + Network Working Group M. Wong -Internet-Draft W. Schlitt -Expires: December 8, 2005 June 6, 2005 +Request for Comments: 4408 W. Schlitt +Category: Experimental April 2006 -Sender Policy Framework (SPF) for Authorizing Use of Domains in E-MAIL, - version 1 - draft-schlitt-spf-classic-02 + Sender Policy Framework (SPF) for + Authorizing Use of Domains in E-Mail, Version 1 -Status of this Memo +Status of This Memo - 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. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on December 8, 2005. + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. Copyright Notice - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). + +IESG Note + + The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) + are published simultaneously as Experimental RFCs, although there is + no general technical consensus and efforts to reconcile the two + approaches have failed. As such, these documents have not received + full IETF review and are published "AS-IS" to document the different + approaches as they were considered in the MARID working group. + + The IESG takes no position about which approach is to be preferred + and cautions the reader that there are serious open issues for each + approach and concerns about using them in tandem. The IESG believes + that documenting the different approaches does less harm than not + documenting them. + + Note that the Sender ID experiment may use DNS records that may have + been created for the current SPF experiment or earlier versions in + this set of experiments. Depending on the content of the record, + this may mean that Sender-ID heuristics would be applied incorrectly + to a message. Depending on the actions associated by the recipient + with those heuristics, the message may not be delivered or may be + discarded on receipt. + + Participants relying on Sender ID experiment DNS records are warned + that they may lose valid messages in this set of circumstances. + aParticipants publishing SPF experiment DNS records should consider + the advice given in section 3.4 of RFC 4406 and may wish to publish + both v=spf1 and spf2.0 records to avoid the conflict. + + + + +Wong & Schlitt Experimental [Page 1] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + Participants in the Sender-ID experiment need to be aware that the + way Resent-* header fields are used will result in failure to receive + legitimate email when interacting with standards-compliant systems + (specifically automatic forwarders which comply with the standards by + not adding Resent-* headers, and systems which comply with RFC 822 + but have not yet implemented RFC 2822 Resent-* semantics). It would + be inappropriate to advance Sender-ID on the standards track without + resolving this interoperability problem. + + The community is invited to observe the success or failure of the two + approaches during the two years following publication, in order that + a community consensus can be reached in the future. Abstract @@ -45,149 +79,125 @@ Abstract 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 may explicitly authorize the hosts - that are allowed to use its domain name, and a receiving host may - check such authorization. - - - - -Wong & Schlitt Expires December 8, 2005 [Page 1] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - + the Sender Policy Framework (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 - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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 - 2.3. Publishing Authorization . . . . . . . . . . . . . . . . . 6 - 2.4. Checking Authorization . . . . . . . . . . . . . . . . . . 7 - 2.5. Interpreting the Result . . . . . . . . . . . . . . . . . 8 - 2.5.1. None . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 10 - 2.5.7. PermError . . . . . . . . . . . . . . . . . . . . . . 10 - 3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 3.1. Publishing . . . . . . . . . . . . . . . . . . . . . . . . 11 - 3.1.1. DNS Resource Record Types . . . . . . . . . . . . . . 11 - 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 - 4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 14 - 4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 14 - 4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 15 - 4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 15 - 4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 15 - 4.6.1. Term Evaluation . . . . . . . . . . . . . . . . . . . 16 - 4.6.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 16 - 4.6.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . 17 - 4.7. Default Result . . . . . . . . . . . . . . . . . . . . . . 17 - 4.8. Domain Specification . . . . . . . . . . . . . . . . . . . 17 - 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 + 1. Introduction ....................................................4 + 1.1. Protocol Status ............................................4 + 1.2. Terminology ................................................5 + 2. Operation .......................................................5 + 2.1. The HELO Identity ..........................................5 + 2.2. The MAIL FROM Identity .....................................5 + 2.3. Publishing Authorization ...................................6 + 2.4. Checking Authorization .....................................6 + 2.5. Interpreting the Result ....................................7 + 2.5.1. None ................................................8 + 2.5.2. Neutral .............................................8 + 2.5.3. Pass ................................................8 + 2.5.4. Fail ................................................8 + 2.5.5. SoftFail ............................................9 + 2.5.6. TempError ...........................................9 + 2.5.7. PermError ...........................................9 + 3. SPF Records .....................................................9 + 3.1. Publishing ................................................10 + 3.1.1. DNS Resource Record Types ..........................10 + 3.1.2. Multiple DNS Records ...............................11 + 3.1.3. Multiple Strings in a Single DNS record ............11 + 3.1.4. Record Size ........................................11 + 3.1.5. Wildcard Records ...................................11 -Wong & Schlitt Expires December 8, 2005 [Page 2] +Wong & Schlitt Experimental [Page 2] -Internet-Draft Sender Policy Framework (SPF) June 2005 +RFC 4408 Sender Policy Framework (SPF) April 2006 - 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 - 12.2. The Received-SPF mail header . . . . . . . . . . . . . . . 43 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 - 13.2. Informative References . . . . . . . . . . . . . . . . . . 44 - 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 - C.1. Changes in Version -02 . . . . . . . . . . . . . . . . . . 51 - C.2. Changes in Version -01 . . . . . . . . . . . . . . . . . . 52 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 55 - Intellectual Property and Copyright Statements . . . . . . . . . . 56 + 4. The check_host() Function ......................................12 + 4.1. Arguments .................................................12 + 4.2. Results ...................................................13 + 4.3. Initial Processing ........................................13 + 4.4. Record Lookup .............................................13 + 4.5. Selecting Records .........................................13 + 4.6. Record Evaluation .........................................14 + 4.6.1. Term Evaluation ....................................14 + 4.6.2. Mechanisms .........................................15 + 4.6.3. Modifiers ..........................................15 + 4.7. Default Result ............................................16 + 4.8. Domain Specification ......................................16 + 5. Mechanism Definitions ..........................................16 + 5.1. "all" .....................................................17 + 5.2. "include" .................................................18 + 5.3. "a" .......................................................19 + 5.4. "mx" ......................................................20 + 5.5. "ptr" .....................................................20 + 5.6. "ip4" and "ip6" ...........................................21 + 5.7. "exists" ..................................................22 + 6. Modifier Definitions ...........................................22 + 6.1. redirect: Redirected Query ................................23 + 6.2. exp: Explanation ..........................................23 + 7. The Received-SPF Header Field ..................................25 + 8. Macros .........................................................27 + 8.1. Macro Definitions .........................................27 + 8.2. Expansion Examples ........................................30 + 9. Implications ...................................................31 + 9.1. Sending Domains ...........................................31 + 9.2. Mailing Lists .............................................32 + 9.3. Forwarding Services and Aliases ...........................32 + 9.4. Mail Services .............................................34 + 9.5. MTA Relays ................................................34 + 10. Security Considerations .......................................35 + 10.1. Processing Limits ........................................35 + 10.2. SPF-Authorized E-Mail May Contain Other False + Identities ...............................................37 + 10.3. Spoofed DNS and IP Data ..................................37 + 10.4. Cross-User Forgery .......................................37 + 10.5. Untrusted Information Sources ............................38 + 10.6. Privacy Exposure .........................................38 + 11. Contributors and Acknowledgements .............................38 + 12. IANA Considerations ...........................................39 + 12.1. The SPF DNS Record Type ..................................39 + 12.2. The Received-SPF Mail Header Field .......................39 + 13. References ....................................................39 + 13.1. Normative References .....................................39 + 13.2. Informative References ...................................40 - - - - - - - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 3] +Wong & Schlitt Experimental [Page 3] -Internet-Draft Sender Policy Framework (SPF) June 2005 +RFC 4408 Sender Policy Framework (SPF) April 2006 + Appendix A. Collected ABNF .......................................42 + Appendix B. Extended Examples ....................................44 + B.1. Simple Examples ..........................................44 + B.2. Multiple Domain Example ..................................45 + B.3. DNSBL Style Example ......................................46 + B.4. Multiple Requirements Example ............................46 + 1. Introduction - The current e-mail infrastructure has the property that any host + 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. 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"). + particular, the session, the envelope, and the mail headers. + Although this feature is desirable in some circumstances, it is a + major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam). Furthermore, many domain name holders are understandably concerned about the ease with which other entities may make use of their domain names, often with malicious intent. 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 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. + Compliant domain holders publish Sender Policy Framework (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 Mail Transfer Agents (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 @@ -195,40 +205,12 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 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. + stronger action against such E-Mail, such as rejecting it. -1.1. State of this draft +1.1. Protocol Status - 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 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 - 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. - - 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. - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 4] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - -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 + SPF has been in development since the summer of 2003 and has seen + deployment beyond the developers beginning in December 2003. The design of SPF slowly evolved until the spring of 2004 and has since stabilized. There have been quite a number of forms of SPF, some written up as documents, some submitted as Internet Drafts, and many @@ -238,11 +220,19 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 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 + + + +Wong & Schlitt Experimental [Page 4] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + deployments may differ from, and build upon, this work. It is hoped that we have nonetheless captured the common understanding of SPF version 1. -1.3. Terminology +1.2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this @@ -251,35 +241,10 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 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. - - - - - - - - - - - - - - - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 5] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - + 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 @@ -291,10 +256,10 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 presented in the EHLO or HELO command are not always clear to the sending party, and SPF clients must be prepared for the "HELO" identity to be malformed or an IP address literal. At the time of - this writing, many legitimate e-mails are delivered with invalid HELO + this writing, many legitimate E-Mails are delivered with invalid HELO domains. - It is RECOMMENDED that SPF clients check not only the "MAIL FROM" + It is RECOMMENDED that SPF clients not only check the "MAIL FROM" identity, but also separately check the "HELO" identity by applying the check_host() function (Section 4) to the "HELO" identity as the . @@ -307,13 +272,21 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 which notification messages are to be sent if there are problems delivering the message. - [RFC2821] allows the reverse-path to be null (see Section 4.5.5). In - this case, there is no explicit sender mailbox, and such a message - can be assumed to be a notification message from the mail system - itself. When the reverse-path is null, this document defines the - "MAIL FROM" identity to be the mailbox composed of the localpart - "postmaster" and the "HELO" identity (which may or may not have been - checked separately before). + [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in + RFC 2821). In this case, there is no explicit sender mailbox, and + such a message can be assumed to be a notification message from the + mail system itself. When the reverse-path is null, this document + + + +Wong & Schlitt Experimental [Page 5] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + defines the "MAIL FROM" identity to be the mailbox composed of the + localpart "postmaster" and the "HELO" identity (which may or may not + have been checked separately before). SPF clients MUST check the "MAIL FROM" identity. SPF clients check the "MAIL FROM" identity by applying the check_host() function to the @@ -329,20 +302,12 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 that they end in "-all", or redirect to other records that do, so that a definitive determination of authorization can be made. - - - -Wong & Schlitt Expires December 8, 2005 [Page 6] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - Domain holders may publish SPF records that explicitly authorize no 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 - legitimate e-mail has been checked. + legitimate E-Mail has been checked. 2.4. Checking Authorization @@ -359,39 +324,37 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 there are cases that are known to give incorrect results. For 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. + message. The scenario described in Section 9.3, sub-section 1.2, is + another example. Documents that define other identities should + define the method for explicit approval. It is possible that mail receivers will use the SPF check as part of a larger set of tests on incoming mail. The results of other tests may influence whether or not a particular SPF check is performed. For example, finding the sending host's IP address on a local white + + + +Wong & Schlitt Experimental [Page 6] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + 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 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. + with the correct parameters. Although 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: - the IP address of the SMTP client that is emitting the - mail, either IPv4 or IPv6. - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 7] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - + mail, either IPv4 or IPv6. - the domain portion of the "MAIL FROM" or "HELO" identity. @@ -403,18 +366,18 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 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, + Although 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 case of invalid "MAIL FROM". In order to prevent - the circumvention of SPF records, rejecting e-mail from invalid + 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 + 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 @@ -423,13 +386,21 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 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. + returned directly to the sending MTA by way of SMTP replies. + + + + +Wong & Schlitt Experimental [Page 7] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + 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 e-mail may fail because the sender's policy may have - since changed. + may cause problems, such as the following: (1) It may be difficult to + accurately extract the required information from potentially + deceptive headers; (2) legitimate E-Mail 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 @@ -437,26 +408,19 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 2.5.1. None - 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 whether - the client host is authorized or not. - - - -Wong & Schlitt Expires December 8, 2005 [Page 8] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - + 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 whether or not the + client host is authorized. 2.5.2. Neutral - The domain owner has explicitly stated that they cannot or do not - want to assert whether the IP address is authorized or not. A + The domain owner has explicitly stated that he cannot or does not + want to assert whether or not the IP address is authorized. 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). + "Neutral" more harshly than "None" would discourage domain owners + from testing the use of SPF records (see Section 9.1). 2.5.3. Pass @@ -470,7 +434,7 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 A "Fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. The checking - software can choose to mark the mail based on this, or to reject the + software can choose to mark the mail based on this or to reject the mail outright. If the checking software chooses to reject the mail during the SMTP @@ -478,10 +442,18 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification (DSN) code (see [RFC3464]), in addition to an appropriate reply text. The check_host() function may return either a default explanation - string, or one from the domain that published the SPF records (see - Section 6.2). If the information doesn't originate with the checking - software, it should be made clear that the text is provided by the - sender's domain. For example: + string or one from the domain that published the SPF records (see + Section 6.2). If the information does not originate with the + + + +Wong & Schlitt Experimental [Page 8] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + checking software, it should be made clear that the text is provided + by the sender's domain. For example: 550-5.7.1 SPF MAIL FROM check failed: 550-5.7.1 The domain example.com explains: @@ -490,26 +462,18 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 2.5.5. SoftFail A "SoftFail" result should be treated as somewhere between a "Fail" - and a "Neutral". The domain believes the host isn't authorized but - isn't willing to make that strong of a statement. Receiving software - SHOULD NOT reject the message based solely on this result, but MAY - subject the message to closer scrutiny than normal. + and a "Neutral". The domain believes the host is not authorized but + is not willing to make that strong of a statement. Receiving + software SHOULD NOT reject the message based solely on this result, + but MAY subject the message to closer scrutiny than normal. - The domain owner wants to discourage the use of this host and so they - desire limited feedback when a "SoftFail" result occurs. For - - - -Wong & Schlitt Expires December 8, 2005 [Page 9] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - - example, the recipient's MUA could highlight the "SoftFail" status, - or the receiving 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 is received, but accept it the second time. + The domain owner wants to discourage the use of this host and thus + desires limited feedback when a "SoftFail" result occurs. For + example, the recipient's Mail User Agent (MUA) could highlight the + "SoftFail" status, or the receiving 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 is received, but accept it the second time. 2.5.6. TempError @@ -522,54 +486,30 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 2.5.7. PermError - A "PermError" result means that the domain's published records - couldn't be correctly interpreted. This signals an error condition - that requires manual intervention to be resolved, as opposed to the + A "PermError" result means that the domain's published records could + not be correctly interpreted. This signals an error condition that + requires manual intervention to be resolved, as opposed to the TempError 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 10] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - 3. SPF Records An SPF record is a DNS Resource Record (RR) that declares which hosts are, and are not, authorized to use a domain name for the "HELO" and "MAIL FROM" identities. Loosely, the record partitions all hosts - into permitted and not-permitted sets. (Though some hosts might fall - into neither category.) + into permitted and not-permitted sets (though some hosts might fall + into neither category). - The SPF record is a single string of text. An example record is: + + +Wong & Schlitt Experimental [Page 9] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + The SPF record is a single string of text. An example record is the + following: v=spf1 +mx a:colo.example.com/28 -all @@ -582,10 +522,11 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 for the hosts that are used in the "MAIL FROM" and "HELO" identities. The SPF records are placed in the DNS tree at the host name it 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. + records. This is the same whether the TXT or SPF RR type (see + Section 3.1.1) is used. - The example above in Section 3 might be published via this lines in a - domain zone file: + The example above in Section 3 might be published via these 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" @@ -596,13 +537,9 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 3.1.1. DNS Resource Record Types - 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]. - - RFC Editor Note: Please add the DNS RR type code once it has been - allocated by the IANA. + This document defines a new DNS RR of type SPF, code 99. 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]. 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 @@ -610,24 +547,26 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 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. - - -Wong & Schlitt Expires December 8, 2005 [Page 11] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - 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 + identical content. For example, instead of publishing just one record as in Section 3.1 above, it is better to publish: 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" - 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. + + + +Wong & Schlitt Experimental [Page 10] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + 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 DNS Records @@ -638,7 +577,7 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 3.1.3. Multiple Strings in a Single DNS record 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 + record (either TXT or 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: @@ -649,9 +588,9 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 IN TXT "v=spf1 .... firstsecond string..." - SPF or TXT records containing multiple strings are useful in order to - construct records which would exceed the 255 byte maximum length of a - string within a single TXT or SPF RR record. + SPF or TXT records containing multiple strings are useful in + constructing records that would exceed the 255-byte maximum length of + a string within a single TXT or SPF RR record. 3.1.4. Record Size @@ -665,14 +604,6 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 DNS answers should fit in UDP packets. Note that when computing the sizes for queries of the TXT format, one must take into account any other TXT records published at the domain name. Records that are too - - - -Wong & Schlitt Expires December 8, 2005 [Page 12] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - long to fit in a single UDP packet MAY be silently ignored by SPF clients. @@ -681,10 +612,18 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 Use of wildcard records for publishing is not recommended. Care must be taken if wildcard records are used. If a domain publishes wildcard MX records, it may want to publish wildcard declarations, + + + +Wong & Schlitt Experimental [Page 11] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + subject to the same requirements and problems. In particular, the declaration must be repeated for any host that has any RR records at all, and for subdomains thereof. For example, the example given in - [RFC1034], Section 4.3.3, could be extended with: + [RFC1034], Section 4.3.3, could be extended with the following: X.COM. MX 10 A.X.COM X.COM. TXT "v=spf1 a:A.X.COM -all" @@ -707,28 +646,6 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 under the domain to exist and queries against arbitrary names will never return RCODE 3 (Name Error). - - - - - - - - - - - - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 13] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - 4. The check_host() Function The check_host() function fetches SPF records, parses them, and @@ -743,14 +660,21 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 4.1. Arguments - The function check_host() takes these arguments: + The check_host() function takes these arguments: - the IP address of the SMTP client that is emitting the - mail, either IPv4 or IPv6. + 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. + + + +Wong & Schlitt Experimental [Page 12] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + - the "MAIL FROM" or "HELO" identity. @@ -770,31 +694,24 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 4.3. Initial Processing - If the is malformed (label longer than 63 characters, zero - length label not at the end, etc.), is not a fully qualified domain + If the is malformed (label longer than 63 characters, zero- + length label not at the end, etc.) or is not a fully qualified domain name, or if the DNS lookup returns "domain does not exist" (RCODE 3), check_host() immediately returns the result "None". If the has no localpart, substitute the string "postmaster" for the localpart. - - -Wong & Schlitt Expires December 8, 2005 [Page 14] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - 4.4. Record Lookup - In accordance with how the records are published, see Section 3.1 - above, a DNS query needs to be made for the name, querying + 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. 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 - immediately with the result "TempError". + If all DNS lookups that are made return a server failure (RCODE 2), + or other error (RCODE other than 0 or 3), or time out, then + check_host() exits immediately with the result "TempError". 4.5. Selecting Records @@ -804,19 +721,25 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 version = "v=spf1" Starting with the set of records that were returned by the lookup, - record selection proceeds in three steps: + record selection proceeds in two steps: - 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 all identical, return a "PermError". - 3. If any records of type SPF are in the set, then all records of - type TXT are discarded. + + +Wong & Schlitt Experimental [Page 13] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + 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 an 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 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 @@ -834,13 +757,6 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 there are any syntax errors, check_host() returns immediately with the result "PermError". - - -Wong & Schlitt Expires December 8, 2005 [Page 15] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - 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 @@ -849,7 +765,8 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 4.6.1. Term Evaluation There are two types of terms: mechanisms and modifiers. A record - contains an ordered list of these as specified in the following ABNF. + contains an ordered list of these as specified in the following + Augmented Backus-Naur Form (ABNF). terms = *( 1*SP ( directive / modifier ) ) @@ -864,15 +781,22 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 Most mechanisms allow a ":" or "/" character after the name. + + +Wong & Schlitt Experimental [Page 14] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + Modifiers always contain an equals ('=') character immediately after 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, as + 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. + As per the definition of the ABNF notation in [RFC4234], mechanism + and modifier names are case-insensitive. 4.6.2. Mechanisms @@ -880,22 +804,14 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 are no more mechanisms, the result is specified in Section 4.7. When a mechanism is evaluated, one of three things can happen: it can - match, it can not match, or it can throw an exception. + match, not match, or throw an exception. 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 qualifiers, and the results they return are: - - - - -Wong & Schlitt Expires December 8, 2005 [Page 16] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - + The possible qualifiers, and the results they return are as follows: "+" Pass "-" Fail @@ -913,9 +829,20 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 4.6.3. Modifiers Modifiers are not mechanisms: they do not return match or not-match. - Instead they provide additional information. While modifiers do not - directly affect the evaluation of the record, the "redirect" modifier - has an effect after all the mechanisms have been evaluated. + Instead they provide additional information. Although modifiers do + not directly affect the evaluation of the record, the "redirect" + modifier has an effect after all the mechanisms have been evaluated. + + + + + + + +Wong & Schlitt Experimental [Page 15] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + 4.7. Default Result @@ -924,7 +851,7 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 "?all" were specified as the last directive. If there is a "redirect" modifier, check_host() proceeds as defined in Section 6.1. - Note that records SHOULD always either use a "redirect" modifier or + Note that records SHOULD always use either a "redirect" modifier or an "all" mechanism to explicitly terminate processing. For example: @@ -943,72 +870,13 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 Note: The result of the macro expansion is not subject to any further escaping. Hence, this facility cannot produce all characters that - are legal in a DNS label (e.g. the control characters). However, - this facility is powerful enough to express legal host names, and - - - -Wong & Schlitt Expires December 8, 2005 [Page 17] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - + are legal in a DNS label (e.g., the control characters). However, + this facility is powerful enough to express legal host names and common utility labels (such as "_spf") that are used in DNS. For several mechanisms, the is optional. If it is not provided, the is used as the . - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 18] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - 5. Mechanism Definitions This section defines two types of mechanisms. @@ -1023,6 +891,15 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 addresses as being permitted or not permitted to use the for sending mail. + + + + +Wong & Schlitt Experimental [Page 16] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + a mx ptr @@ -1034,7 +911,8 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 comparison between and an IP address at any point: If no CIDR-length is given in the directive, then and the IP - address are compared for equality. + address are compared for equality. (Here, CIDR is Classless Inter- + Domain Routing.) If a CIDR-length is specified, then only the specified number of high-order bits of and the IP address are compared for equality. @@ -1042,7 +920,7 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 When any mechanism fetches host addresses to compare with , when is an IPv4 address, A records are fetched, when is an IPv6 address, AAAA records are fetched. Even if the SMTP connection is - via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513] section + via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section 2.5.5) MUST still be considered an IPv4 address. Several mechanisms rely on information fetched from DNS. For these @@ -1057,14 +935,6 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 all = "all" The "all" mechanism is a test that always matches. It is used as the - - - -Wong & Schlitt Expires December 8, 2005 [Page 19] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - rightmost mechanism in a record to provide an explicit default. For example: @@ -1074,9 +944,21 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 Mechanisms after "all" will never be tested. Any "redirect" modifier (Section 6.1) has no effect when there is an "all" mechanism. + + + + + + + +Wong & Schlitt Experimental [Page 17] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + 5.2. "include" - include = "include" ":" domain-spec + include = "include" ":" domain-spec The "include" mechanism triggers a recursive evaluation of check_host(). The domain-spec is expanded as per Section 8. Then @@ -1106,8 +988,6 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 were not permitted for either of those domains would the result be "Fail". - Whether this mechanism matches, does not match, or throws an error, - depends on the result of the recursive evaluation of check_host(): @@ -1116,11 +996,26 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 -Wong & Schlitt Expires December 8, 2005 [Page 20] + + + + + + + + + + + +Wong & Schlitt Experimental [Page 18] -Internet-Draft Sender Policy Framework (SPF) June 2005 +RFC 4408 Sender Policy Framework (SPF) April 2006 + Whether this mechanism matches, does not match, or throws an + exception depends on the result of the recursive evaluation of + check_host(): + +---------------------------------+---------------------------------+ | A recursive check_host() result | Causes the "include" mechanism | | of: | to: | @@ -1141,12 +1036,12 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 +---------------------------------+---------------------------------+ The "include" mechanism is intended for crossing administrative - boundaries. While it is possible to use includes to consolidate + boundaries. Although it is possible to use includes to consolidate multiple domains that share the same set of designated hosts, domains are encouraged to use redirects where possible, and to minimize the number of includes within a single administrative domain. For example, if example.com and example.org were managed by the same - entity, and if the permitted set of hosts for both domains were + entity, and if the permitted set of hosts for both domains was "mx:example.com", it would be possible for example.org to specify "include:example.com", but it would be preferable to specify "redirect=example.com" or even "mx:example.com". @@ -1162,6 +1057,17 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 to the returned address(es). If any address matches, the mechanism matches. + + + + + + +Wong & Schlitt Experimental [Page 19] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + 5.4. "mx" This mechanism matches if is one of the MX hosts for a domain @@ -1169,36 +1075,28 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] - - - -Wong & Schlitt Expires December 8, 2005 [Page 21] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - 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 an - "mx" mechanism (see Section 10). If any address matches, the - mechanism matches. + compared to each returned IP address. To prevent Denial of Service + (DoS) attacks, more 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. - Note regarding implicit MXes: If the has no MX records, + Note regarding implicit MXs: If the has no MX records, check_host() MUST NOT pretend the target is its single MX, and MUST NOT default to an A lookup on the directly. This - behavior breaks with the legacy "implicit MX" rule. See [RFC2821] + behavior breaks with the legacy "implicit MX" rule. See [RFC2821], Section 5. If such behavior is desired, the publisher should specify an "a" directive. 5.5. "ptr" - This mechanism tests whether the DNS reverse mapping for exists + 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 ] - First the 's name is looked up using this procedure: perform a + First, the 's name is looked up using this procedure: perform a DNS reverse-mapping for , looking up the corresponding PTR record in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa." if it is an IPv6 address. For each record returned, validate the @@ -1207,32 +1105,30 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 a "ptr" mechanism (see Section 10). If is among the returned IP addresses, then that domain name is validated. In pseudocode: - sending-domain_names := ptr_lookup(sending-host_IP); - if more than 10 sending-domain_names are found, use at most 10. - for each name in (sending-domain_names) { + sending-domain_names := ptr_lookup(sending-host_IP); if more than 10 + sending-domain_names are found, use at most 10. for each name in + (sending-domain_names) { IP_addresses := a_lookup(name); if the sending-domain_IP is one of the IP_addresses { validated-sending-domain_names += name; - } - } + } } Check all validated domain names to see if they end in the domain. If any do, this mechanism matches. If no validated domain name can be found, or if none of the validated + + + +Wong & Schlitt Experimental [Page 20] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + domain names end in the , this mechanism fails to match. If a DNS error occurs while doing the PTR RR lookup, then this mechanism fails to match. If a DNS error occurs while doing an A RR lookup, then that domain name is skipped and the search continues. - - - - -Wong & Schlitt Expires December 8, 2005 [Page 22] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - Pseudocode: for each name in (validated-sending-domain_names) { @@ -1242,15 +1138,15 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 return no-match. This mechanism matches if the is either an ancestor of - a validated domain name, or if the and a validated + a validated domain name or if the and a validated domain name are the same. For example: "mail.example.com" is within the domain "example.com", but "mail.bad-example.com" is not. - Note: Use of this mechanism is discouraged because it is slow, is not - as reliable as other mechanisms in cases of DNS errors and it places - a large burden on the arpa name servers. If used, proper PTR records - must be in place for the domain's hosts and the "ptr" mechanism - should be one of the last mechanisms checked. + Note: Use of this mechanism is discouraged because it is slow, it is + not as reliable as other mechanisms in cases of DNS errors, and it + places a large burden on the arpa name servers. If used, proper PTR + records must be in place for the domain's hosts and the "ptr" + mechanism should be one of the last mechanisms checked. 5.6. "ip4" and "ip6" @@ -1270,25 +1166,25 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 / "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 + ; as per conventional dotted quad notation. e.g., 192.0.2.0 ip6-network = - ; e.g. 2001:DB8::CD30 + ; e.g., 2001:DB8::CD30 The is compared to the given network. If CIDR-length high-order bits match, the mechanism matches. - If ip4-cidr-length is omitted it is taken to be "/32". If - ip6-cidr-length is omitted it is taken to be "/128". It is not + + +Wong & Schlitt Experimental [Page 21] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + If ip4-cidr-length is omitted, it is taken to be "/32". If + ip6-cidr-length is omitted, it is taken to be "/128". It is not permitted to omit parts of the IP address instead of using CIDR notations. That is, use 192.0.2.0/24 instead of 192.0.2. - - -Wong & Schlitt Expires December 8, 2005 [Page 23] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - 5.7. "exists" This mechanism is used to construct an arbitrary domain name that is @@ -1300,7 +1196,7 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 The domain-spec is expanded as per Section 8. The resulting domain name is used for a DNS A RR lookup. If any A record is returned, - this mechanism matches. The lookup type is 'A' even when the + this mechanism matches. The lookup type is A even when the connection type is IPv6. Domains can use this mechanism to specify arbitrarily complex @@ -1315,36 +1211,6 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 This mechanism enables queries that mimic the style of tests that existing anti-spam DNS blacklists (DNSBL) use. - - - - - - - - - - - - - - - - - - - - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 24] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - 6. Modifier Definitions Modifiers are name/value pairs that provide additional information. @@ -1361,6 +1227,15 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 gracefully handle records with modifiers that are defined in other specifications. + + + + +Wong & Schlitt Experimental [Page 22] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + 6.1. redirect: Redirected Query If all mechanisms fail to match, and a "redirect" modifier is @@ -1393,21 +1268,13 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 the same record. This can be an administrative advantage. Note: In general, the domain "A" cannot reliably use a redirect to - - - -Wong & Schlitt Expires December 8, 2005 [Page 25] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - another domain "B" not under the same administrative control. Since the stays the same, there is no guarantee that the record at domain "B" will correctly work for mailboxes in domain "A", especially if domain "B" uses mechanisms involving localparts. An "include" directive may be more appropriate. - For clarity it is RECOMMENDED that any "redirect" modifier appear as + For clarity, it is RECOMMENDED that any "redirect" modifier appear as the very last term in a record. 6.2. exp: Explanation @@ -1417,6 +1284,14 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 If check_host() results in a "Fail" due to a mechanism match (such as "-all"), and the "exp" modifier is present, then the explanation string returned is computed as described below. If no "exp" modifier + + + +Wong & Schlitt Experimental [Page 23] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + is present, then either a default explanation string or an empty explanation string may be returned. @@ -1429,41 +1304,34 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 explanation string, then proceed as if no exp modifier was given. The fetched TXT record's strings are concatenated with no spaces, and - then treated as an which is macro-expanded. This + then treated as an , which is macro-expanded. This 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 + 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 comes from a third party. For example, it can prepend the macro - string "%{o} explains: " to the explanation, such as shown in - Section 2.5.4. + string "%{o} explains: " to the explanation, such as shown in Section + 2.5.4. Suppose example.com has this record: v=spf1 mx -all exp=explain._spf.%{d} Here are some examples of possible explanation TXT records at - - - -Wong & Schlitt Expires December 8, 2005 [Page 26] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - explain._spf.example.com: + "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." - -- a message with a little more info, including the IP address - that failed the check + -- a message with a little more information, including the IP + address that failed the check "See http://%{d}/why.html?s=%{S}&i=%{I}" -- a complicated example that constructs a URL with the @@ -1472,63 +1340,33 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 Note: During recursion into an "include" mechanism, an exp= modifier from the MUST NOT be used. In contrast, when executing + + + +Wong & Schlitt Experimental [Page 24] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + a "redirect" modifier, an exp= modifier from the original domain MUST NOT be used. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 27] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - -7. The Received-SPF header field +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 - so, it SHOULD use the "Received-SPF" header defined here for each - identity that was checked. This information is intended for the + processing in the message header. If an SMTP receiver chooses to do + so, it SHOULD use the "Received-SPF" header field defined here for + each identity that was checked. This information is intended for the recipient. (Information intended for the sender is described in Section 6.2, Explanation.) - The Received-SPF header is a trace field (see [RFC2822] section - 3.6.7) and SHOULD be prepended to existing headers, above the - Received: header that is generated by the SMTP receiver. It MUST - appear above any other Received-SPF headers in the message. The - header has the format: + The Received-SPF header field is a trace field (see [RFC2822] Section + 3.6.7) and SHOULD be prepended to the existing header, above the + Received: field that is generated by the SMTP receiver. It MUST + appear above all other Received-SPF fields in the message. The + header field has the following format: - header = "Received-SPF:" [CFWS] result FWS [comment FWS] + header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] [ key-value-list ] CRLF result = "Pass" / "Fail" / "SoftFail" / "Neutral" / @@ -1554,22 +1392,22 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 FWS = CRLF = - The header SHOULD include a "(...)" style after the result, - conveying supporting information for the result, such as , - and . + The header field SHOULD include a "(...)" style after the + result, conveying supporting information for the result, such as + , , and . + + + + +Wong & Schlitt Experimental [Page 25] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + 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 - - - -Wong & Schlitt Expires December 8, 2005 [Page 28] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - - the "MAIL FROM" identity was checked, the "envelope-from". + can be verified. That is, at least "client-ip", "helo", and, if the + "MAIL FROM" identity was checked, "envelope-from". client-ip the IP address of the SMTP client @@ -1578,30 +1416,30 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 helo the host name given in the HELO or EHLO command mechanism the mechanism that matched (if no mechanisms matched, - substitute the word "default".) + substitute the word "default") problem if an error was returned, details about the error receiver the host name of the SPF client - identity the identity that was checked, see the ABNF - rule. + identity the identity that was checked; see the ABNF + rule Other keys may be defined by SPF clients. Until a new key name 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 not excessively long, and does not + SPF clients MUST make sure that the Received-SPF header field does + not 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: + Examples of various header styles that could be generated are the + following: Received-SPF: Pass (mybox.example.org: domain of myname@example.com designates 192.0.2.1 as permitted sender) receiver=mybox.example.org; client-ip=192.0.2.1; envelope-from=; helo=foo.example.com; - Received-SPF: Fail (mybox.example.org: domain of myname@example.com does not designate 192.0.2.1 as permitted sender) @@ -1617,26 +1455,25 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 - - - -Wong & Schlitt Expires December 8, 2005 [Page 29] +Wong & Schlitt Experimental [Page 26] -Internet-Draft Sender Policy Framework (SPF) June 2005 +RFC 4408 Sender Policy Framework (SPF) April 2006 8. Macros -8.1. Macro definitions +8.1. Macro Definitions Many mechanisms and modifiers perform macro expansion on part of the term. domain-spec = macro-string domain-end - domain-end = ( "." toplabel ) / macro-expand + domain-end = ( "." toplabel [ "." ] ) / macro-expand - toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum - ; LDH rule (See [RFC3696]) + toplabel = ( *alphanum ALPHA *alphanum ) / + ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) + ; LDH rule plus additional TLD restrictions + ; (see [RFC3696], Section 2) alphanum = ALPHA / DIGIT explain-string = *( macro-string / SP ) @@ -1654,7 +1491,7 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 A literal "%" is expressed by "%%". "%_" expands to a single " " space. - "%-" expands to a URL-encoded space, viz. "%20". + "%-" expands to a URL-encoded space, viz., "%20". The following macro letters are expanded in term arguments: @@ -1667,22 +1504,26 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 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: + + + + + + + +Wong & Schlitt Experimental [Page 27] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + The following macro letters are allowed only in "exp" text: c = SMTP client IP (easily readable format) r = domain name of host performing the check t = current timestamp - - - -Wong & Schlitt Expires December 8, 2005 [Page 30] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - A '%' character not followed by a '{', '%', '-', or '_' character is - a syntax error. So, + a syntax error. So -exists:%(ir).sbl.spamhaus.example.org @@ -1691,7 +1532,7 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 -exists:%{ir}.sbl.spamhaus.example.org - Optional transformers are: + Optional transformers are the following: *DIGIT = zero or more digits 'r' = reverse value, splitting on dots by default @@ -1702,9 +1543,12 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 using "." and not the original splitting characters. By default, strings are split on "." (dots). Note that no special - treatment is given to leading, trailing or consecutive delimiters, - and so the list of parts may contain empty strings. Macros may - specify delimiter characters which are used instead of ".". + treatment is given to leading, trailing, or consecutive delimiters, + and so the list of parts may contain empty strings. Older + implementations of SPF prohibit trailing dots in domain names, so + trailing dots should not be published by domain owners, although they + must be accepted by implementations conforming to this document. + Macros may specify delimiter characters that 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" @@ -1719,48 +1563,49 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 support at least a value of 128, as that is the maximum number of labels in a domain name. - The "s" macro expands to the argument. It is an e-mail + + + + +Wong & Schlitt Experimental [Page 28] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + The "s" macro expands to the argument. It is an E-Mail address with a localpart, an "@" character, and a domain. The "l" macro expands to just the localpart. The "o" macro expands to just 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 - - - -Wong & Schlitt Expires December 8, 2005 [Page 31] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - standard dotted-quad format. For IPv6 addresses, the "i" macro expands to a dot-format address; it is intended for use in %{ir}. The "c" macro may expand to any of the - hexadecimal colon-format addresses specified in [RFC3513] section + hexadecimal colon-format addresses specified in [RFC3513], Section 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 the checking is done by a MUA) or if policy restrictions dictate otherwise, the word "unknown" SHOULD be substituted. The domain name - may be different than the name found in the MX record that the client + may be different from the name found in the MX record that the client MTA used to locate the receiving MTA. The "t" macro expands to the decimal representation of the - approximate number of seconds since the Epoch (Midnight, January 1st, + approximate number of seconds since the Epoch (Midnight, January 1, 1970, UTC). This is the same value as is returned by the POSIX time() function in most standards-compliant libraries. @@ -1770,34 +1615,35 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 successive domain labels until the total length does not exceed 253 characters. - Uppercased macros expand exactly as their lower case equivalents, and + Uppercased macros expand exactly as their lowercased equivalents, and are then URL escaped. URL escaping must be performed for characters not in the "uric" set, which is defined in [RFC3986]. + + + + +Wong & Schlitt Experimental [Page 29] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + Note: Care must be taken so that macro expansion for legitimate - e-mail does not exceed the 63 character limit on DNS labels. The - localpart of e-mail addresses, in particular, can have more than 63 + E-Mail does not exceed the 63-character limit on DNS labels. The + localpart of E-Mail addresses, in particular, can have more than 63 characters between dots. Note: Domains should avoid using the "s", "l", "o", or "h" macros in - conjunction with any mechanism directive. While these macros are + conjunction with any mechanism directive. Although these macros are powerful and allow per-user records to be published, they severely limit the ability of implementations to cache results of check_host() and they reduce the effectiveness of DNS caches. - - - -Wong & Schlitt Expires December 8, 2005 [Page 32] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - Implementations should be aware that if no directive processed during - the evaluation of check_host() contains an "s", "l", "o" or "h" + the evaluation of check_host() contains an "s", "l", "o", or "h" macro, then the results of the evaluation can be cached on the basis - of and alone for as long as the shortest TTL of all the - DNS records involved. + of and alone for as long as the shortest Time To Live + (TTL) of all the DNS records involved. 8.2. Expansion Examples @@ -1806,7 +1652,6 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 The IPv6 SMTP client IP is 2001:DB8::CB01. The PTR domain name of the client IP is mx.example.org. - macro expansion ------- ---------------------------- %{s} strong-bad@email.example.com @@ -1824,6 +1669,21 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 %{lr-} bad.strong %{l1r-} strong + + + + + + + + + + +Wong & Schlitt Experimental [Page 30] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + macro-string expansion -------------------------------------------------------------------- %{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com @@ -1842,21 +1702,14 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 %{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0. 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com - - -Wong & Schlitt Expires December 8, 2005 [Page 33] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - 9. Implications This section outlines the major implications that adoption of this - document will have on various entities involved in Internet e-mail. + document will have on various entities involved in Internet E-Mail. It is intended to make clear to the reader where this document knowingly affects the operation of such entities. This section is - not a "how-to" manual, nor a "best practices" document, and is not a - comprehensive list of what such entities should do in light of this + not a "how-to" manual, or a "best practices" document, and it is not + a comprehensive list of what such entities should do in light of this document. This section is non-normative. @@ -1876,15 +1729,26 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all + + + + + + +Wong & Schlitt Experimental [Page 31] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + 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 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 - reverse-path are many and long standing, SPF adds enforcement to this - requirement. + [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. Whereas the reasons for + changing the reverse-path are many and long-standing, SPF adds + enforcement to this requirement. In practice, almost all mailing list software in use already complies with this requirement. Mailing lists that do not comply may or may @@ -1897,129 +1761,125 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 Forwarding services take mail that is received at a mailbox and direct it to some external mailbox. At the time of this writing, the - - - -Wong & Schlitt Expires December 8, 2005 [Page 34] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - near-universal practice of such services is to use the original "MAIL FROM" of a message when re-injecting it for delivery to the external mailbox. [RFC1123] and [RFC2821] describe this action as an "alias" - rather than a "mail list". This means the external mailbox's MTA - sees all such mail in a connection from a host of the forwarding + rather than a "mail list". This means that the external mailbox's + MTA sees all such mail in a connection from a host of the forwarding service, and so the "MAIL FROM" identity will not, in general, pass authorization. There are three places that techniques can be used to ameliorate this problem. - 1. The beginning, when e-mail is first sent. + 1. The beginning, when E-Mail is first sent. - 1. "Neutral" results could be given for IP addresses that may be - forwarders, instead of "Fail" results. For example: + 1. "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.example.org ?all" + "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.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. - - 2. 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. - - 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. + This would cause a lookup on an anti-spam DNS blacklist + (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. -Wong & Schlitt Expires December 8, 2005 [Page 35] + +Wong & Schlitt Experimental [Page 32] -Internet-Draft Sender Policy Framework (SPF) June 2005 +RFC 4408 Sender Policy Framework (SPF) April 2006 - "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all" + 2. 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: - 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 exists:%{l}._spf_verify.%{d} -all" - "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}" + Then, a specialized DNS server can be set up to serve the + _spf_verify subdomain that validates the localpart. Although + this requires an extra DNS lookup, this happens only when the + E-Mail would otherwise be rejected as not coming from a known + good source. - 2. The middle, when e-mail is forwarded. + 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. - 1. 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. + 3. Similarly, a specialized DNS server could be set up that will + rate-limit the E-Mail coming from unexpected IP addresses. - 2. 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"). + "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all" - 3. The end, when e-mail is received. + 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: - 1. 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. + "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}" - 2. Tests against other identities, such as the "HELO" identity, - may be used to override a failed test against the "MAIL FROM" - identity. + 2. The middle, when E-Mail is forwarded. - 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. + 1. 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. + + 2. 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"). + + + + + + + +Wong & Schlitt Experimental [Page 33] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + 3. The end, when E-Mail is received. + + 1. If the owner of the external mailbox wishes to trust the + forwarding service, he can direct the external mailbox's MTA + to skip SPF tests when the client host belongs to the + forwarding service. + + 2. Tests against other identities, such as the "HELO" identity, + may be used to override a failed test against the "MAIL FROM" + identity. + + 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. 9.4. Mail Services Service providers that offer mail services to third-party domains, - such as sending of bulk mail, may have to adjust their setup in light + such as sending of bulk mail, may want 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 - provider, then the provider needs only to ensure that their sending - host is authorized by their own SPF record, if any. - - - -Wong & Schlitt Expires December 8, 2005 [Page 36] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - + FROM" identity used for such E-Mail uses the domain of the service + provider, then the provider needs only to ensure that its sending + host is authorized by its 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 + several options for the third-party domain to authorize the service provider's MTAs to send mail on its behalf. For mail service providers, such as ISPs, that have a wide variety of customers using the same MTA, steps should be taken to prevent cross-customer forgery @@ -2028,7 +1888,7 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 9.5. MTA Relays The authorization check generally precludes the use of arbitrary MTA - relays between sender and receiver of an e-mail message. + relays between sender and receiver of an E-Mail message. Within an organization, MTA relays can be effectively deployed. However, for purposes of this document, such relays are effectively @@ -2040,57 +1900,41 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 these are just the border MTAs as internal MTAs simply forward mail to these MTAs for delivery. + + + +Wong & Schlitt Experimental [Page 34] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + Mail receivers will generally want to perform the authorization check - at the border MTAs, specifically including all secondary MXes. This + at the border MTAs, specifically including all secondary MXs. This allows mail that fails to be rejected during the SMTP session rather than bounced. Internal MTAs then do not perform the authorization test. To perform the authorization test other than at the border, the host that first transferred the message to the organization must - be determined, which can be difficult to extract from headers. - Testing other than at the border is not recommended. - - - - - - - - - - - - - - - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 37] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - + be determined, which can be difficult to extract from the message + header. Testing other than at the border is not recommended. 10. Security Considerations 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 for a Denial- - of-Service (DoS) attack. The processing limits outlined here are - designed to prevent attacks such as: + As with most aspects of E-Mail, there are a number of ways that + 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 the following: o A malicious party could create an SPF record with many references - to a victim's domain and send many e-mails to different SPF + 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 + o Whereas implementations of check_host() are supposed to limit the number of DNS lookups, malicious domains could publish records that exceed these limits in an attempt to waste computation effort at their targets when they send them mail. Malicious domains @@ -2107,28 +1951,28 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 the easiest for a DoS attack to effectively exploit. As a result, limits that may seem reasonable for an individual mail server can still allow an unreasonable amount of bandwidth amplification. - Therefore the processing limits need to be quite low. + 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, including any lookups caused by the use of the "include" mechanism or the + + + +Wong & Schlitt Experimental [Page 35] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + "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 + 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. - - - -Wong & Schlitt Expires December 8, 2005 [Page 38] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - 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. @@ -2136,8 +1980,8 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 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 - usage, and DoS attacks. + will be accepted to prevent excessive bandwidth usage or memory usage + and DoS attacks. MTAs or other processors MAY also impose a limit on the maximum amount of elapsed time to evaluate check_host(). Such a limit SHOULD @@ -2151,7 +1995,7 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 that require less DNS information and placing lower-cost mechanisms earlier in the SPF record. - For example, consider a domain set up as: + For example, consider a domain set up as follows: example.com. IN MX 10 mx.example.com. mx.example.com. IN A 192.0.2.1 @@ -2161,32 +2005,32 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 Evaluating check_host() for the domain "a.example.com" requires the MX records for "example.com", and then the A records for the listed - hosts. Evaluating for "b.example.com" only requires the A records. + hosts. Evaluating for "b.example.com" requires only the A records. Evaluating for "c.example.com" requires none. 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 + + + +Wong & Schlitt Experimental [Page 36] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +10.2. SPF-Authorized E-Mail May Contain Other False Identities The "MAIL FROM" and "HELO" identity authorizations must not be construed to provide more assurance than they do. It is entirely - possible for a malicious sender to inject a message using their own + possible for a malicious sender to inject a message using his 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 - - - -Wong & Schlitt Expires December 8, 2005 [Page 39] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - - the other more commonly-presented identities (such as the From: - header), the user may be lulled into a false sense of security. + record authorize the sending host, and yet the message can easily + list other identities in its header. 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 + field), the user may be lulled into a false sense of security. 10.3. Spoofed DNS and IP Data @@ -2198,7 +2042,7 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 check_host() to see spoofed DNS data, and then return incorrect 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. + [RFC3833] for a description of DNS weaknesses. o The client IP address, , is assumed to be correct. A malicious attacker could spoof TCP sequence numbers to make mail @@ -2208,39 +2052,42 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 10.4. Cross-User Forgery By definition, SPF policies just map domain names to sets of - authorized MTAs, not whole e-mail addresses to sets of authorized + 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 + define individual sets of authorized MTAs for specific E-Mail addresses, it is generally impossible to verify, through SPF, the use - of specific e-mail addresses by individual users of the same MTA. + 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 [RFC4409], Section 6.1). Another means to + verify the identity of individual users is message cryptography such + as PGP ([RFC2440]) or S/MIME ([RFC3851]). + + + + + + + +Wong & Schlitt Experimental [Page 37] + +RFC 4408 Sender Policy Framework (SPF) April 2006 - 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 [I-D.gellens-submit-bis] section 6.1). - 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 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 - headers and possibly returned to the client MTA in the form of an - SMTP rejection message. This information must be checked for invalid + information is then passed to the receiver in the Received-SPF: trace + fields and possibly returned to the client MTA in the form of an SMTP + rejection message. This information must be checked for invalid characters and excessively long lines. When the authorization check fails, an explanation string may be included in the reject response. Both the sender and the rejecting receiver need to be aware that the explanation was determined by the - - - -Wong & Schlitt Expires December 8, 2005 [Page 40] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - 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. @@ -2252,62 +2099,39 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 someone other than the actual sender, 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. In - practice DSNs can be misdirected, such as when an MTA accepts an - 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. + practice, DSNs can be misdirected, such as when an MTA accepts an + 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 Checking SPF records causes DNS queries to be sent to the domain owner. These DNS queries, especially if they are caused by the "exists" mechanism, can contain information about who is sending - e-mail and likely to which MTA the e-mail is being sent to. This can + E-Mail and likely to which MTA the E-Mail is being sent. This can introduce some privacy concerns, which may be more or less of an issue depending on local laws and the relationship between the domain - owner and the person sending the e-mail. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 41] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - + owner and the person sending the E-Mail. 11. Contributors and Acknowledgements This document is largely based on the work of Meng Weng Wong and Mark - Lentczner. While, as this section acknowledges, many people have + Lentczner. Although, as this section acknowledges, many people have contributed to this document, a very large portion of the writing and editing are due to Meng and Mark. This design owes a debt of parentage to [RMX] by Hadmut Danisch and to [DMP] by Gordon Fecyk. The idea of using a DNS record to check - the legitimacy of an e-mail address traces its ancestry farther back + the legitimacy of an E-Mail address traces its ancestry further back through messages on the namedroppers mailing list by Paul Vixie + + + +Wong & Schlitt Experimental [Page 38] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + [Vixie] (based on suggestion by Jim Miller) and by David Green [Green]. @@ -2317,7 +2141,7 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 The authors would also like to thank the literally hundreds of individuals who have participated in the development of this design. - They are far too numerous to name, but they include: + They are far too numerous to name, but they include the following: The folks on the spf-discuss mailing list. The folks on the SPAM-L mailing list. @@ -2325,42 +2149,14 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 The folks on the IETF MARID mailing list. The folks on #perl. - - - - - - - - - - - - - - - - - - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 42] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - 12. IANA Considerations 12.1. The SPF DNS Record Type - The IANA needs to assign a new Resource Record Type and Qtype from - the DNS Parameters Registry for the SPF RR type. + The IANA has assigned a new Resource Record Type and Qtype from the + DNS Parameters Registry for the SPF RR type with code 99. -12.2. The Received-SPF mail header +12.2. The Received-SPF Mail Header Field Per [RFC3864], the "Received-SPF:" header field is added to the IANA Permanent Message Header Field Registry. The following is the @@ -2368,74 +2164,45 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 Header field name: Received-SPF Applicable protocol: mail ([RFC2822]) - Status: standard - (Note to RFC Editor: Replace the status with the final - determination by the IESG) + Status: Experimental Author/Change controller: IETF - Specification document(s): this Internet Draft - (Note to RFC Editor: Replace this with RFC YYYY (RFC number of - this spec)) + Specification document(s): RFC 4408 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/ - - - - - - - - - - - - - - - - - - - - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 43] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - + additions to this field are recommended. For information about + the SPF Council see http://www.openspf.org/Council 13. References -13.1 Normative References +13.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. + + + + +Wong & Schlitt Experimental [Page 39] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 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. [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format - for Delivery Status Notifications", RFC 3464, - January 2003. + for Delivery Status Notifications", RFC 3464, January + 2003. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. @@ -2445,41 +2212,37 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 September 2004. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", STD 66, - RFC 3986, January 2005. + Resource Identifier (URI): Generic Syntax", STD 66, RFC + 3986, January 2005. - [US-ASCII] - American National Standards Institute (formerly United + [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 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. - - - - -Wong & Schlitt Expires December 8, 2005 [Page 44] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - + 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", 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. [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 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. + + +Wong & Schlitt Experimental [Page 40] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + [RFC2554] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. @@ -2494,14 +2257,13 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. + [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", + RFC 4409, April 2006. + [RMX] Danish, H., "The RMX DNS RR Type for light weight sender - authentication", October 2003. + authentication", Work In Progress - Work In Progress - - [DMP] Fecyk, G., "Designated Mailers Protocol", December 2003. - - Work In Progress + [DMP] Fecyk, G., "Designated Mailers Protocol", Work In Progress [Vixie] Vixie, P., "Repudiating MAIL FROM", 2002. @@ -2516,9 +2278,26 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 -Wong & Schlitt Expires December 8, 2005 [Page 45] + + + + + + + + + + + + + + + + + +Wong & Schlitt Experimental [Page 41] -Internet-Draft Sender Policy Framework (SPF) June 2005 +RFC 4408 Sender Policy Framework (SPF) April 2006 Appendix A. Collected ABNF @@ -2527,10 +2306,9 @@ Appendix A. Collected ABNF fragments in the preceding text are to be resolved in favor of this grammar. - 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". + See [RFC4234] 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" @@ -2566,21 +2344,25 @@ Appendix A. Collected ABNF / "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 + ; conventional dotted quad notation. e.g., 192.0.2.0 ip6-network = - ; e.g. 2001:DB8::CD30 + ; e.g., 2001:DB8::CD30 -Wong & Schlitt Expires December 8, 2005 [Page 46] + +Wong & Schlitt Experimental [Page 42] -Internet-Draft Sender Policy Framework (SPF) June 2005 +RFC 4408 Sender Policy Framework (SPF) April 2006 domain-spec = macro-string domain-end - domain-end = ( "." toplabel ) / macro-expand - toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum - ; LDH rule (See [RFC3696]) + domain-end = ( "." toplabel [ "." ] ) / macro-expand + toplabel = ( *alphanum ALPHA *alphanum ) / + ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) + ; LDH rule plus additional TLD restrictions + ; (see [RFC3696], Section 2) + alphanum = ALPHA / DIGIT explain-string = *( macro-string / SP ) @@ -2597,7 +2379,7 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) - header = "Received-SPF:" [CFWS] result FWS [comment FWS] + header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] [ key-value-list ] CRLF result = "Pass" / "Fail" / "SoftFail" / "Neutral" / @@ -2625,12 +2407,9 @@ Internet-Draft Sender Policy Framework (SPF) June 2005 - - - -Wong & Schlitt Expires December 8, 2005 [Page 47] +Wong & Schlitt Experimental [Page 43] -Internet-Draft Sender Policy Framework (SPF) June 2005 +RFC 4408 Sender Policy Framework (SPF) April 2006 Appendix B. Extended Examples @@ -2684,9 +2463,9 @@ B.1. Simple Examples -Wong & Schlitt Expires December 8, 2005 [Page 48] +Wong & Schlitt Experimental [Page 44] -Internet-Draft Sender Policy Framework (SPF) June 2005 +RFC 4408 Sender Policy Framework (SPF) April 2006 v=spf1 a:example.org -all @@ -2740,9 +2519,9 @@ B.2. Multiple Domain Example -Wong & Schlitt Expires December 8, 2005 [Page 49] +Wong & Schlitt Experimental [Page 45] -Internet-Draft Sender Policy Framework (SPF) June 2005 +RFC 4408 Sender Policy Framework (SPF) April 2006 B.3. DNSBL Style Example @@ -2750,9 +2529,8 @@ B.3. DNSBL Style Example Imagine that, in addition to the domain records listed above, there are these: - $ORIGIN _spf.example.com. - mary.mobile-users A 127.0.0.2 - fred.mobile-users A 127.0.0.2 + $ORIGIN _spf.example.com. mary.mobile-users A + 127.0.0.2 fred.mobile-users A 127.0.0.2 15.15.168.192.joel.remote-users A 127.0.0.2 16.15.168.192.joel.remote-users A 127.0.0.2 @@ -2776,9 +2554,9 @@ B.3. DNSBL Style Example B.4. Multiple Requirements Example - Say that your sender policy requires that both the IP address is + Say that your sender policy requires both that the IP address is within a certain range and that the reverse DNS for the IP matches. - This can be done several ways, including: + This can be done several ways, including the following: example.com. SPF ( "v=spf1 " "-include:ip4._spf.%{d} " @@ -2788,241 +2566,18 @@ B.4. Multiple Requirements Example ptr._spf.example.com. SPF "v=spf1 -ptr +all" 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. + SPF record that ends in "+all" can be very restrictive, and the use + of De Morgan's Law. -Wong & Schlitt Expires December 8, 2005 [Page 50] + +Wong & Schlitt Experimental [Page 46] -Internet-Draft Sender Policy Framework (SPF) June 2005 - - -Appendix C. Change Log - - RFC Editor Note: This section is to be removed during the final - publication of the document. - -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. - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 51] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - - 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. - - o A version number was added to the title. (IESG review) - - 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 - 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 The HELO identity checking has been changed from "MAY" to - "RECOMMENDED". - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 52] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - - 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 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 will 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 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 - 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-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 - - o A few host names/IP addresses were fixed to use appropriate ones - for I-Ds. - - 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. - - o Section 7.1 "Process Limits" has been merged into the similar - language in the "Security Considerations" section. - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 53] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - - o The ABNF for the Received-SPF e-mail header has been made to be - 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. - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 54] - -Internet-Draft Sender Policy Framework (SPF) June 2005 +RFC 4408 Sender Policy Framework (SPF) April 2006 Authors' Addresses @@ -3030,8 +2585,7 @@ Authors' Addresses Meng Weng Wong Singapore - Email: mengwong+spf@pobox.com - URI: http://spf.pobox.com/ + EMail: mengwong+spf@pobox.com Wayne Schlitt @@ -3039,7 +2593,7 @@ Authors' Addresses Lincoln Nebraska, NE 68506 United States of America - Email: wayne@schlitt.net + EMail: wayne@schlitt.net URI: http://www.schlitt.net/spf/ @@ -3076,12 +2630,29 @@ Authors' Addresses -Wong & Schlitt Expires December 8, 2005 [Page 55] + +Wong & Schlitt Experimental [Page 47] -Internet-Draft Sender Policy Framework (SPF) June 2005 +RFC 4408 Sender Policy Framework (SPF) April 2006 -Intellectual Property Statement +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to @@ -3105,32 +2676,16 @@ Intellectual Property Statement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. +Acknowledgement -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). -Wong & Schlitt Expires December 8, 2005 [Page 56] + + + +Wong & Schlitt Experimental [Page 48]