diff options
| author | dougb <dougb@FreeBSD.org> | 2007-12-02 19:17:26 +0000 |
|---|---|---|
| committer | dougb <dougb@FreeBSD.org> | 2007-12-02 19:17:26 +0000 |
| commit | 4632e549b6bb0304daa5e3eb10552a2ca2c76f4e (patch) | |
| tree | 2884ed373b74190b67e838220658366c1e6a1299 /contrib/bind9/doc | |
| parent | 475b1eb4b268dca03c0dc03b6cf87b918ba80099 (diff) | |
| download | FreeBSD-src-4632e549b6bb0304daa5e3eb10552a2ca2c76f4e.zip FreeBSD-src-4632e549b6bb0304daa5e3eb10552a2ca2c76f4e.tar.gz | |
This commit was generated by cvs2svn to compensate for changes in r174190,
which included commits to RCS files with non-trunk default branches.
Diffstat (limited to 'contrib/bind9/doc')
| -rw-r--r-- | contrib/bind9/doc/draft/draft-schlitt-spf-classic-02.txt | 3136 |
1 files changed, 0 insertions, 3136 deletions
diff --git a/contrib/bind9/doc/draft/draft-schlitt-spf-classic-02.txt b/contrib/bind9/doc/draft/draft-schlitt-spf-classic-02.txt deleted file mode 100644 index 3bd9594..0000000 --- a/contrib/bind9/doc/draft/draft-schlitt-spf-classic-02.txt +++ /dev/null @@ -1,3136 +0,0 @@ - - - -Network Working Group M. Wong -Internet-Draft W. Schlitt -Expires: December 8, 2005 June 6, 2005 - - -Sender Policy Framework (SPF) for Authorizing Use of Domains in E-MAIL, - version 1 - draft-schlitt-spf-classic-02 - -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. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - E-mail on the Internet can be forged in a number of ways. In - 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 - - -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 - - - -Wong & Schlitt Expires December 8, 2005 [Page 2] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - - 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 - - - - - - - - - - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 3] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - -1. Introduction - - 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"). - 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. - - An additional benefit to mail receivers is that after the use of an - identity is verified, local policy decisions about the mail can be - made based on the sender's domain, rather than the host's IP address. - This is advantageous because reputation of domain names is likely to - be more accurate than reputation of host IP addresses. Furthermore, - if a claimed identity fails verification, local policy can take - stronger action against such e-mail, such as rejecting it. - -1.1. State of this draft - - This draft version attempts to resolve all known issues and address - all comments received from the IESG review of 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 - 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 - discussed and debated in development forums. - - The goal of this document is to clearly document the protocol defined - by earlier draft specifications of SPF as used in existing - implementations. This conception of SPF is sometimes called "SPF - Classic". It is understood that particular implementations and - deployments may differ from, and build upon, this work. It is hoped - that we have nonetheless captured the common understanding of SPF - version 1. - -1.3. Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - 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 - - -2. Operation - -2.1. The HELO Identity - - The "HELO" identity derives from either the SMTP HELO or EHLO command - (see [RFC2821]). These commands supply the SMTP client (sending - host) for the SMTP session. Note that requirements for the domain - 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 - domains. - - It is RECOMMENDED that SPF clients check not only 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 - <sender>. - -2.2. The MAIL FROM Identity - - The "MAIL FROM" identity derives from the SMTP MAIL command (see - [RFC2821]). This command supplies the "reverse-path" for a message, - which generally consists of the sender mailbox, and is the mailbox to - 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). - - SPF clients MUST check the "MAIL FROM" identity. SPF clients check - the "MAIL FROM" identity by applying the check_host() function to the - "MAIL FROM" identity as the <sender>. - -2.3. Publishing Authorization - - An SPF-compliant domain MUST publish a valid SPF record as described - in Section 3. This record authorizes the use of the domain name in - the "HELO" and "MAIL FROM" identities by the MTAs it specifies. - - If domain owners choose to publish SPF records, it is RECOMMENDED - 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. - -2.4. Checking Authorization - - A mail receiver can perform a set of SPF checks for each mail message - it receives. An SPF check tests the authorization of a client host - to emit mail with a given identity. Typically, such checks are done - by a receiving MTA, but can be performed elsewhere in the mail - processing chain so long as the required information is available and - reliable. At least the "MAIL FROM" identity MUST be checked, but it - is RECOMMENDED that the "HELO" identity also be checked beforehand. - - Without explicit approval of the domain owner, checking other - identities against SPF version 1 records is NOT RECOMMENDED because - there are cases that are known to give incorrect results. For - example, 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. - - 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 - 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. - - To make the test, the mail receiver MUST evaluate the check_host() - function with the arguments set as follows: - - <ip> - 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 - - - <domain> - the domain portion of the "MAIL FROM" or "HELO" identity. - - <sender> - the "MAIL FROM" or "HELO" identity. - - Note that the <domain> argument may not be a well-formed domain name. - For example, if the reverse-path was null, then the EHLO/HELO domain - is used, with its associated problems (see Section 2.1). In these - cases, check_host() is defined in Section 4.3 to return a "None" - 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, - especially in the case of invalid "MAIL FROM". In order to prevent - the circumvention of SPF records, rejecting e-mail from invalid - domains should be considered. - - Implementations must take care to correctly extract the <domain> from - the data given with the SMTP MAIL FROM command as many MTAs will - still accept such things as source routes (see [RFC2821] appendix C), - the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). These - archaic features have been maliciously used to bypass security - systems. - -2.5. Interpreting the Result - - This section describes how software that performs the authorization - should interpret the results of the check_host() function. The - authorization check SHOULD be performed during the processing of the - SMTP transaction that sends the mail. This allows errors to be - returned directly to the sending server by way of SMTP replies. - - Performing the authorization after the SMTP transaction has finished - may 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. - - Generating non-delivery notifications to forged identities that have - failed the authorization check is generally abusive and against the - explicit wishes of the identity owner. - -2.5.1. None - - 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 - - -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 - "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). - -2.5.3. Pass - - A "Pass" result means that the client is authorized to inject mail - with the given identity. The domain can now, in the sense of - reputation, be considered responsible for sending the message. - Further policy checks can now proceed with confidence in the - legitimate use of the identity. - -2.5.4. Fail - - 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 - mail outright. - - If the checking software chooses to reject the mail during the SMTP - transaction, then it SHOULD use an SMTP reply code of 550 (see - [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: - - 550-5.7.1 SPF MAIL FROM check failed: - 550-5.7.1 The domain example.com explains: - 550 5.7.1 Please see http://www.example.com/mailpolicy.html - -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. - - 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. - -2.5.6. TempError - - A "TempError" result means that the SPF client encountered a - transient error while performing the check. Checking software can - choose to accept or temporarily reject the message. If the message - is rejected during the SMTP transaction for this reason, the software - SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN - code. - -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 - 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.) - - The SPF record is a single string of text. An example record is: - - v=spf1 +mx a:colo.example.com/28 -all - - This record has a version of "spf1" and three directives: "+mx", - "a:colo.example.com/28" (the + is implied), and "-all". - -3.1. Publishing - - Domain owners wishing to be SPF compliant must publish SPF records - 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. - - The example above in Section 3 might be published via this lines in a - domain zone file: - - example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" - smtp-out.example.com. TXT "v=spf1 a -all" - - When publishing via TXT records, beware of other TXT records - published there for other purposes. They may cause problems with - size limits (see Section 3.1.4). - -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. - - It is recognized that the current practice (using a TXT record) is - not optimal, but it is necessary because there are a number of DNS - server and resolver implementations in common use that cannot handle - the new RR type. The two-record-type scheme provides a forward path - to the better solution of using 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 - 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. - -3.1.2. Multiple DNS Records - - A domain name MUST NOT have multiple records that would cause an - authorization check to select more than one record. See Section 4.5 - for the selection rules. - -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 - 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: - - IN TXT "v=spf1 .... first" "second string..." - - MUST be treated as equivalent to - - 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. - -3.1.4. Record Size - - The published SPF record for a given domain name SHOULD remain small - enough that the results of a query for it will fit within 512 octets. - This will keep even older DNS implementations from falling over to - TCP. Since the answer size is dependent on many things outside the - scope of this document, it is only possible to give this guideline: - If the combined length of the DNS name and the text of all the - records of a given type (TXT or SPF) is under 450 characters, then - 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. - -3.1.5. Wildcard Records - - 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, - 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: - - X.COM. MX 10 A.X.COM - X.COM. TXT "v=spf1 a:A.X.COM -all" - - *.X.COM. MX 10 A.X.COM - *.X.COM. TXT "v=spf1 a:A.X.COM -all" - - A.X.COM. A 1.2.3.4 - A.X.COM. MX 10 A.X.COM - A.X.COM. TXT "v=spf1 a:A.X.COM -all" - - *.A.X.COM. MX 10 A.X.COM - *.A.X.COM. TXT "v=spf1 a:A.X.COM -all" - - Notice that SPF records must be repeated twice for every name within - the domain: once for the name, and once with a wildcard to cover the - tree under the name. - - Use of wildcards is discouraged in general as they cause every name - 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 - interprets them to determine whether a particular host is or is not - permitted to send mail with a given identity. Mail receivers that - perform this check MUST correctly evaluate the check_host() function - as described here. - - Implementations MAY use a different algorithm than the canonical - algorithm defined here, so long as the results are the same in all - cases. - -4.1. Arguments - - The function check_host() takes these arguments: - - <ip> - the IP address of the SMTP client that is emitting the - mail, either IPv4 or IPv6. - - <domain> - the domain that provides the sought-after authorization - information; initially the domain portion of the "MAIL FROM" - or "HELO" identity. - - <sender> - the "MAIL FROM" or "HELO" identity. - - The domain portion of <sender> will usually be the same as the - <domain> argument when check_host() is initially evaluated. However, - this will generally not be true for recursive evaluations (see - Section 5.2 below). - - Actual implementations of the check_host() function may need - additional arguments. - -4.2. Results - - The function check_host() can return one of several results described - in Section 2.5. Based on the result, the action to be taken is - determined by the local policies of the receiver. - -4.3. Initial Processing - - If the <domain> is malformed (label longer than 63 characters, zero - length label not at the end, etc.), 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 <sender> 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 <domain> 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". - -4.5. Selecting Records - - Records begin with a version section: - - record = version terms *SP - version = "v=spf1" - - Starting with the set of records that were returned by the lookup, - record selection proceeds in three steps: - - 1. Records that do not begin with a version section of exactly - "v=spf1" are discarded. Note that the version section is - 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. - - After the above steps, there should be exactly one record remaining - and evaluation can proceed. If there are two or more records - remaining, then check_host() exits immediately with the result of - "PermError". - - If no matching records are returned, an SPF client MUST assume that - the domain makes no SPF declarations. SPF processing MUST stop and - return "None". - -4.6. Record Evaluation - - After one SPF record has been selected, the check_host() function - parses and interprets it to find a result for the current test. If - 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 - be detected. - -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. - - terms = *( 1*SP ( directive / modifier ) ) - - directive = [ qualifier ] mechanism - qualifier = "+" / "-" / "?" / "~" - mechanism = ( all / include - / A / MX / PTR / IP4 / IP6 / exists ) - modifier = redirect / explanation / unknown-modifier - unknown-modifier = name "=" macro-string - - name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) - - Most mechanisms allow a ":" or "/" character after the name. - - 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 - 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. - -4.6.2. Mechanisms - - Each mechanism is considered in turn from left to right. If there - 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. - - 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 - - - "+" Pass - "-" Fail - "~" SoftFail - "?" Neutral - - The qualifier is optional and defaults to "+". - - When a mechanism matches and the qualifier is "-", then a "Fail" - result is returned and the explanation string is computed as - described in Section 6.2. - - The specific mechanisms are described in Section 5. - -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. - -4.7. Default Result - - If none of the mechanisms match and there is no "redirect" modifier, - then the check_host() returns a result of "Neutral", just as if - "?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 - an "all" mechanism to explicitly terminate processing. - - For example: - - v=spf1 +mx -all - or - v=spf1 +mx redirect=_spf.example.com - -4.8. Domain Specification - - Several of these mechanisms and modifiers have a <domain-spec> - section. The <domain-spec> string is macro expanded (see Section 8). - The resulting string is the common presentation form of a fully- - qualified DNS name: a series of labels separated by periods. This - domain is called the <target-name> in the rest of this document. - - 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 - - - common utility labels (such as "_spf") that are used in DNS. - - For several mechanisms, the <domain-spec> is optional. If it is not - provided, the <domain> is used as the <target-name>. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -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. - - Basic mechanisms contribute to the language framework. They do not - specify a particular type of authorization scheme. - - all - include - - Designated sender mechanisms are used to designate a set of <ip> - addresses as being permitted or not permitted to use the <domain> for - sending mail. - - a - mx - ptr - ip4 - ip6 - exists - - The following conventions apply to all mechanisms that perform a - comparison between <ip> and an IP address at any point: - - If no CIDR-length is given in the directive, then <ip> and the IP - address are compared for equality. - - If a CIDR-length is specified, then only the specified number of - high-order bits of <ip> and the IP address are compared for equality. - - When any mechanism fetches host addresses to compare with <ip>, when - <ip> is an IPv4 address, A records are fetched, when <ip> 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 - 2.5.5) MUST still be considered an IPv4 address. - - Several mechanisms rely on information fetched from DNS. For these - DNS queries, except where noted, if the DNS server returns an error - (RCODE other than 0 or 3) or the query times out, the mechanism - throws the exception "TempError". If the server returns "domain does - not exist" (RCODE 3), then evaluation of the mechanism continues as - if the server returned no error (RCODE 0) and zero answer records. - -5.1. "all" - - 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: - - v=spf1 a mx -all - - Mechanisms after "all" will never be tested. Any "redirect" modifier - (Section 6.1) has no effect when there is an "all" mechanism. - -5.2. "include" - - include = "include" ":" domain-spec - - The "include" mechanism triggers a recursive evaluation of - check_host(). The domain-spec is expanded as per Section 8. Then - check_host() is evaluated with the resulting string as the <domain>. - The <ip> and <sender> arguments remain the same as in the current - evaluation of check_host(). - - In hindsight, the name "include" was poorly chosen. Only the - evaluated result of the referenced SPF record is used, rather than - acting as if the referenced SPF record was literally included in the - first. For example, evaluating a "-all" directive in the referenced - record does not terminate the overall processing and does not - necessarily result in an overall "Fail". (Better names for this - mechanism would have been "if-pass", "on-pass", etc.) - - The "include" mechanism makes it possible for one domain to designate - multiple administratively-independent domains. For example, a vanity - domain "example.net" might send mail using the servers of - administratively-independent domains example.com and example.org. - - Example.net could say - - IN TXT "v=spf1 include:example.com include:example.org -all" - - This would direct check_host() to, in effect, check the records of - example.com and example.org for a "Pass" result. Only if the host - were not permitted for either of those domains would the result be - "Fail". - - Whether this mechanism matches, does not match, or throws an error, - depends on the result of the recursive evaluation of check_host(): - - - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 20] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - - +---------------------------------+---------------------------------+ - | A recursive check_host() result | Causes the "include" mechanism | - | of: | to: | - +---------------------------------+---------------------------------+ - | Pass | match | - | | | - | Fail | not match | - | | | - | SoftFail | not match | - | | | - | Neutral | not match | - | | | - | TempError | throw TempError | - | | | - | PermError | throw PermError | - | | | - | None | throw PermError | - +---------------------------------+---------------------------------+ - - The "include" mechanism is intended for crossing administrative - boundaries. While 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 - "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". - -5.3. "a" - - This mechanism matches if <ip> is one of the <target-name>'s IP - addresses. - - A = "a" [ ":" domain-spec ] [ dual-cidr-length ] - - An address lookup is done on the <target-name>. The <ip> is compared - to the returned address(es). If any address matches, the mechanism - matches. - -5.4. "mx" - - This mechanism matches if <ip> is one of the MX hosts for a domain - name. - - 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 <target-name>. Then - it performs an address lookup on each MX name returned. The <ip> 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. - - Note regarding implicit MXes: If the <target-name> 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 <target-name> directly. This - 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 <ip> exists - and correctly points to a domain name within a particular domain. - - PTR = "ptr" [ ":" domain-spec ] - - First the <ip>'s name is looked up using this procedure: perform a - DNS reverse-mapping for <ip>, 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 - domain name by looking up its IP address. To prevent DoS attacks, - more than 10 PTR names MUST NOT be looked up during the evaluation of - a "ptr" mechanism (see Section 10). If <ip> 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) { - 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 - <target-name> domain. If any do, this mechanism matches. If no - validated domain name can be found, or if none of the validated - domain names end in the <target-name>, 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) { - if name ends in <domain-spec>, return match. - if name is <domain-spec>, return match. - } - return no-match. - - This mechanism matches if the <target-name> is either an ancestor of - a validated domain name, or if the <target-name> 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. - -5.6. "ip4" and "ip6" - - These mechanisms test whether <ip> is contained within a given IP - network. - - IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] - IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] - - ip4-cidr-length = "/" 1*DIGIT - ip6-cidr-length = "/" 1*DIGIT - dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] - - ip4-network = qnum "." qnum "." qnum "." qnum - qnum = DIGIT ; 0-9 - / %x31-39 DIGIT ; 10-99 - / "1" 2DIGIT ; 100-199 - / "2" %x30-34 DIGIT ; 200-249 - / "25" %x30-35 ; 250-255 - ; as per conventional dotted quad notation. e.g. 192.0.2.0 - ip6-network = <as per [RFC 3513], section 2.2> - ; e.g. 2001:DB8::CD30 - - The <ip> 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 - 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 - used for a DNS A record query. It allows for complicated schemes - involving arbitrary parts of the mail envelope to determine what is - permitted. - - exists = "exists" ":" domain-spec - - 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 - connection type is IPv6. - - Domains can use this mechanism to specify arbitrarily complex - queries. For example, suppose example.com publishes the record: - - v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all - - The <target-name> might expand to - "1.2.0.192.someuser._spf.example.com". This makes fine-grained - decisions possible at the level of the user and client IP address. - - 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. - Modifiers always have an "=" separating the name and the value. - - The modifiers defined in this document ("redirect" and "exp") MAY - appear anywhere in the record, but SHOULD appear at the end, after - all mechanisms. Ordering of these two modifiers does not matter. - These two modifiers MUST NOT appear in a record more than once each. - If they do, then check_host() exits with a result of "PermError". - - Unrecognized modifiers MUST be ignored no matter where in a record, - or how often. This allows implementations of this document to - gracefully handle records with modifiers that are defined in other - specifications. - -6.1. redirect: Redirected Query - - If all mechanisms fail to match, and a "redirect" modifier is - present, then processing proceeds as follows: - - redirect = "redirect" "=" domain-spec - - The domain-spec portion of the redirect section is expanded as per - the macro rules in Section 8. Then check_host() is evaluated with - the resulting string as the <domain>. The <ip> and <sender> - arguments remain the same as current evaluation of check_host(). - - The result of this new evaluation of check_host() is then considered - the result of the current evaluation with the exception that if no - SPF record is found, or if the target-name is malformed, the result - is a "PermError" rather than "None". - - Note that the newly-queried domain may itself specify redirect - processing. - - This facility is intended for use by organizations that wish to apply - the same record to multiple domains. For example: - - la.example.com. TXT "v=spf1 redirect=_spf.example.com" - ny.example.com. TXT "v=spf1 redirect=_spf.example.com" - sf.example.com. TXT "v=spf1 redirect=_spf.example.com" - _spf.example.com. TXT "v=spf1 mx:example.com -all" - - In this example, mail from any of the three domains is described by - 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 <sender> 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 - the very last term in a record. - -6.2. exp: Explanation - - explanation = "exp" "=" domain-spec - - 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 - is present, then either a default explanation string or an empty - explanation string may be returned. - - The <domain-spec> is macro expanded (see Section 8) and becomes the - <target-name>. The DNS TXT record for the <target-name> is fetched. - - If <domain-spec> is empty, or there are any DNS processing errors - (any RCODE other than 0), or if no records are returned, or if more - than one record is returned, or if there are syntax errors in the - 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 <explain-string> 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 - 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. - - 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 - - "See http://%{d}/why.html?s=%{S}&i=%{I}" - -- a complicated example that constructs a URL with the - arguments to check_host() so that a web page can be - generated with detailed, custom instructions - - Note: During recursion into an "include" mechanism, an exp= modifier - from the <target-name> MUST NOT be used. In contrast, when executing - 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 - - 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 - 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: - - header = "Received-SPF:" [CFWS] result FWS [comment FWS] - [ key-value-list ] CRLF - - result = "Pass" / "Fail" / "SoftFail" / "Neutral" / - "None" / "TempError" / "PermError" - - key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) - [";"] - - key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) - - key = "client-ip" / "envelope-from" / "helo" / - "problem" / "receiver" / "identity" / - mechanism / "x-" name / name - - identity = "mailfrom" ; for the "MAIL FROM" identity - / "helo" ; for the "HELO" identity - / name ; other identities - - dot-atom = <unquoted word as per [RFC2822]> - quoted-string = <quoted string as per [RFC2822]> - comment = <comment string as per [RFC2822]> - CFWS = <comment or folding white space as per [RFC2822]> - FWS = <folding white space as per [RFC2822]> - CRLF = <standard end-of-line token as per [RFC2822]> - - The header SHOULD include a "(...)" style <comment> after the result, - conveying supporting information for the result, such as <ip>, - <sender> and <domain>. - - 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". - - client-ip the IP address of the SMTP client - - envelope-from the envelope sender mailbox - - helo the host name given in the HELO or EHLO command - - mechanism the mechanism that matched (if no mechanisms matched, - substitute the word "default".) - - problem if an error was returned, details about the error - - receiver the host name of the SPF client - - identity the identity that was checked, see the <identity> 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 - contain malicious data that has been provided by the sender. - - Examples of various header styles that could be generated: - - 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=<myname@example.com>; 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) - identity=mailfrom; client-ip=192.0.2.1; - envelope-from=<myname@example.com>; - - - - - - - - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 29] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - -8. Macros - -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 - - toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum - ; LDH rule (See [RFC3696]) - alphanum = ALPHA / DIGIT - - explain-string = *( macro-string / SP ) - - macro-string = *( macro-expand / macro-literal ) - macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) - / "%%" / "%_" / "%-" - macro-literal = %x21-24 / %x26-7E - ; visible characters except "%" - macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / - "c" / "r" / "t" - transformers = *DIGIT [ "r" ] - delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" - - A literal "%" is expressed by "%%". - - "%_" expands to a single " " space. - "%-" expands to a URL-encoded space, viz. "%20". - - The following macro letters are expanded in term arguments: - - s = <sender> - l = local-part of <sender> - o = domain of <sender> - d = <domain> - i = <ip> - p = the validated domain name of <ip> - v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6 - h = HELO/EHLO domain - - The following macro letters are only allowed in "exp" text: - - c = SMTP client IP (easily readable format) - r = domain name of host performing the check - t = current timestamp - - - - -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, - - -exists:%(ir).sbl.spamhaus.example.org - - is incorrect and will cause check_host() to return a "PermError". - Instead, say - - -exists:%{ir}.sbl.spamhaus.example.org - - Optional transformers are: - - *DIGIT = zero or more digits - 'r' = reverse value, splitting on dots by default - - If transformers or delimiters are provided, the replacement value for - a macro letter is split into parts. After performing any reversal - operation and/or removal of left-hand parts, the parts are rejoined - 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 ".". - - The 'r' transformer indicates a reversal operation: if the client IP - address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1" - and the macro %{ir} would expand to "1.2.0.192". - - The DIGIT transformer indicates the number of right-hand parts to - use, after optional reversal. If a DIGIT is specified, the value - MUST be nonzero. If no DIGITs are specified, or if the value - specifies more parts than are available, all the available parts are - used. If the DIGIT was 5, and only 3 parts were available, the macro - interpreter would pretend the DIGIT was 3. Implementations MUST - 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 <sender> 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 <sender> had no localpart, the - 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 - 2.2. It is intended for humans to read. - - The "p" macro expands to the validated domain name of <ip>. The - procedure for finding the validated domain name is defined in - Section 5.5. If the <domain> is present in the list of validated - domains, it SHOULD be used. Otherwise, if a subdomain of the - <domain> 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 - 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, - 1970, UTC). This is the same value as is returned by the POSIX - time() function in most standards-compliant libraries. - - When the result of macro expansion is used in a domain name query, if - the expanded domain name exceeds 253 characters (the maximum length - of a domain name), the left side is truncated to fit, by removing - successive domain labels until the total length does not exceed 253 - characters. - - Uppercased macros expand exactly as their lower case equivalents, and - are then URL escaped. URL escaping must be performed for characters - not in the "uric" set, which is defined in [RFC3986]. - - 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 - 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 - 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" - macro, then the results of the evaluation can be cached on the basis - of <domain> and <ip> alone for as long as the shortest TTL of all the - DNS records involved. - -8.2. Expansion Examples - - The <sender> is strong-bad@email.example.com. - The IPv4 SMTP client IP is 192.0.2.3. - 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 - %{o} email.example.com - %{d} email.example.com - %{d4} email.example.com - %{d3} email.example.com - %{d2} example.com - %{d1} com - %{dr} com.example.email - %{d2r} example.email - %{l} strong-bad - %{l-} strong.bad - %{lr} strong-bad - %{lr-} bad.strong - %{l1r-} strong - - macro-string expansion - -------------------------------------------------------------------- - %{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com - %{lr-}.lp._spf.%{d2} bad.strong.lp._spf.example.com - - %{lr-}.lp.%{ir}.%{v}._spf.%{d2} - bad.strong.lp.3.2.0.192.in-addr._spf.example.com - - %{ir}.%{v}.%{l1r-}.lp._spf.%{d2} - 3.2.0.192.in-addr.strong.lp._spf.example.com - - %{d2}.trusted-domains.example.net - example.com.trusted-domains.example.net - - IPv6: - %{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. - 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 - document. - - This section is non-normative. - -9.1. Sending Domains - - Domains that wish to be compliant with this specification will need - to determine the list of hosts that they allow to use their domain - name in the "HELO" and "MAIL FROM" identities. It is recognized that - forming such a list is not just a simple technical exercise, but - involves policy decisions with both technical and administrative - considerations. - - It can be helpful to publish records that include a "tracking - exists:" mechanism. By looking at the name server logs, a rough list - may then be generated. For example: - - v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all - -9.2. Mailing Lists - - Mailing lists must be aware of how they re-inject mail that is sent - 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. - - In practice, almost all mailing list software in use already complies - with this requirement. Mailing lists that do not comply may or may - not encounter problems depending on how access to the list is - restricted. Such lists that are entirely internal to a domain (only - people in the domain can send to or receive from the list) are not - affected. - -9.3. Forwarding Services and Aliases - - 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 - 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. "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" - - 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. - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 35] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - - "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all" - - 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 redirect=%{l1r+}._at_.%{o}._spf.%{d}" - - 2. The middle, when e-mail is forwarded. - - 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"). - - 3. The end, when e-mail is received. - - 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. - - 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 - 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 - - - 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 - 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 - (see Section 10.4). - -9.5. MTA Relays - - The authorization check generally precludes the use of arbitrary MTA - 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 - transparent. The SPF authorization check is a check between border - MTAs of different domains. - - For mail senders, this means that published SPF records must - authorize any MTAs that actually send across the Internet. Usually, - these are just the border MTAs as internal MTAs simply forward mail - to these MTAs for delivery. - - Mail receivers will generally want to perform the authorization check - at the border MTAs, specifically including all secondary MXes. 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 - - -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: - - 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 - clients; those SPF clients would then create a DoS attack. In - effect, the SPF clients are being used to amplify the attacker's - bandwidth by using fewer bytes in the SMTP session than are used - by the DNS queries. Using SPF clients also allows the attacker to - hide the true source of the attack. - - o While implementations of check_host() are supposed to limit the - number of DNS lookups, malicious domains could publish records - that exceed these limits in an attempt to waste computation effort - at their targets when they send them mail. Malicious domains - could also design SPF records that cause particular - implementations to use excessive memory or CPU usage, or to - trigger bugs. - - o Malicious parties could send a large volume of mail purporting to - come from the intended target to a wide variety of legitimate mail - hosts. These legitimate machines would then present a DNS load on - the target as they fetched the relevant records. - - Of these, the case of a third party referenced in the SPF record is - 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. - - 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 - "redirect" modifier. If this number is exceeded during a check, a - PermError MUST be returned. The "include", "a", "mx", "ptr", and - "exists" mechanisms as well as the "redirect" modifier do count - against this limit. The "all", "ip4" and "ip6" mechanisms do not - require DNS lookups and therefore do not count against this limit. - The "exp" modifier does not count against this limit because the DNS - lookup to fetch the explanation string occurs after the SPF record - has been evaluated. - - - - -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. - - 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. - - MTAs or other processors MAY also impose a limit on the maximum - amount of elapsed time to evaluate check_host(). Such a limit SHOULD - allow at least 20 seconds. If such a limit is exceeded, the result - of authorization SHOULD be "TempError". - - Domains publishing records SHOULD try to keep the number of "include" - mechanisms and chained "redirect" modifiers to a minimum. Domains - SHOULD also try to minimize the amount of other DNS information - needed to evaluate a record. This can be done by choosing directives - that require less DNS information and placing lower-cost mechanisms - earlier in the SPF record. - - For example, consider a domain set up as: - - example.com. IN MX 10 mx.example.com. - mx.example.com. IN A 192.0.2.1 - a.example.com. IN TXT "v=spf1 mx:example.com -all" - b.example.com. IN TXT "v=spf1 a:mx.example.com -all" - c.example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all" - - 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. - 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 - - 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 - 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. - -10.3. Spoofed DNS and IP Data - - There are two aspects of this protocol that malicious parties could - exploit to undermine the validity of the check_host() function: - - o The evaluation of check_host() relies heavily on DNS. A malicious - attacker could attack the DNS infrastructure and cause - check_host() to see spoofed DNS data, and then return incorrect - results. This could include returning "Pass" for an <ip> value - where the actual domain's record would evaluate to "Fail". See - [RFC3833] for a description of the DNS weaknesses. - - o The client IP address, <ip>, is assumed to be correct. A - malicious attacker could spoof TCP sequence numbers to make mail - appear to come from a permitted host for a domain that the - attacker is impersonating. - -10.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 - users. Although the "l" macro (Section 8) provides a limited way to - define individual sets of authorized MTAs for specific e-mail - addresses, it is generally impossible to verify, through SPF, the use - of specific e-mail addresses by individual users of the same MTA. - - It is up to mail services and their MTAs to directly prevent cross- - user forgery: based on SMTP AUTH ([RFC2554]), users should be - restricted to using only those e-mail addresses that are actually - under their control (see [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 - 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. - - This is probably less of a concern than it may initially seem since - such messages are returned to the sender, and the explanation strings - come from the sender policy published by the domain in the identity - claimed by that very sender. As long as the DSN is not redirected to - 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. - -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 - 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 - - -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 - 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 - through messages on the namedroppers mailing list by Paul Vixie - [Vixie] (based on suggestion by Jim Miller) and by David Green - [Green]. - - Philip Gladstone contributed the concept of macros to the - specification, multiplying the expressiveness of the language and - making per-user and per-IP lookups possible. - - 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: - - The folks on the spf-discuss mailing list. - The folks on the SPAM-L mailing list. - The folks on the IRTF ASRG mailing list. - 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. - -12.2. The Received-SPF mail header - - Per [RFC3864], the "Received-SPF:" header field is added to the IANA - Permanent Message Header Field Registry. The following is the - registration template: - - 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) - Author/Change controller: IETF - Specification document(s): this Internet Draft - (Note to RFC Editor: Replace this with RFC YYYY (RFC number of - this spec)) - Related information: - 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 - - -13. References - -13.1 Normative References - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [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. - - [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format - 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. - - [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration - Procedures for Message Header Fields", BCP 90, RFC 3864, - September 2004. - - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", STD 66, - RFC 3986, January 2005. - - [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 - - -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. - - [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. - - [RFC2554] Myers, J., "SMTP Service Extension for Authentication", - RFC 2554, March 1999. - - [RFC3696] Klensin, J., "Application Techniques for Checking and - Transformation of Names", RFC 3696, February 2004. - - [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain - Name System (DNS)", RFC 3833, August 2004. - - [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail - Extensions (S/MIME) Version 3.1 Message Specification", - RFC 3851, July 2004. - - [RMX] Danish, H., "The RMX DNS RR Type for light weight sender - authentication", October 2003. - - Work In Progress - - [DMP] Fecyk, G., "Designated Mailers Protocol", December 2003. - - Work In Progress - - [Vixie] Vixie, P., "Repudiating MAIL FROM", 2002. - - [Green] Green, D., "Domain-Authorized SMTP Mail", 2002. - - - - - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 45] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - -Appendix A. Collected ABNF - - This section is normative and any discrepancies with the 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". - - record = version terms *SP - version = "v=spf1" - - terms = *( 1*SP ( directive / modifier ) ) - - directive = [ qualifier ] mechanism - qualifier = "+" / "-" / "?" / "~" - mechanism = ( all / include - / A / MX / PTR / IP4 / IP6 / exists ) - - all = "all" - include = "include" ":" domain-spec - A = "a" [ ":" domain-spec ] [ dual-cidr-length ] - MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] - PTR = "ptr" [ ":" domain-spec ] - IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] - IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] - exists = "exists" ":" domain-spec - - modifier = redirect / explanation / unknown-modifier - redirect = "redirect" "=" domain-spec - explanation = "exp" "=" domain-spec - unknown-modifier = name "=" macro-string - - ip4-cidr-length = "/" 1*DIGIT - ip6-cidr-length = "/" 1*DIGIT - dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] - - ip4-network = qnum "." qnum "." qnum "." qnum - qnum = DIGIT ; 0-9 - / %x31-39 DIGIT ; 10-99 - / "1" 2DIGIT ; 100-199 - / "2" %x30-34 DIGIT ; 200-249 - / "25" %x30-35 ; 250-255 - ; conventional dotted quad notation. e.g. 192.0.2.0 - ip6-network = <as per [RFC 3513], section 2.2> - ; e.g. 2001:DB8::CD30 - - - -Wong & Schlitt Expires December 8, 2005 [Page 46] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - - domain-spec = macro-string domain-end - domain-end = ( "." toplabel ) / macro-expand - toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum - ; LDH rule (See [RFC3696]) - alphanum = ALPHA / DIGIT - - explain-string = *( macro-string / SP ) - - macro-string = *( macro-expand / macro-literal ) - macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) - / "%%" / "%_" / "%-" - macro-literal = %x21-24 / %x26-7E - ; visible characters except "%" - macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / - "c" / "r" / "t" - transformers = *DIGIT [ "r" ] - delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" - - name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) - - header = "Received-SPF:" [CFWS] result FWS [comment FWS] - [ key-value-list ] CRLF - - result = "Pass" / "Fail" / "SoftFail" / "Neutral" / - "None" / "TempError" / "PermError" - - key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) - [";"] - - key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) - - key = "client-ip" / "envelope-from" / "helo" / - "problem" / "receiver" / "identity" / - mechanism / "x-" name / name - - identity = "mailfrom" ; for the "MAIL FROM" identity - / "helo" ; for the "HELO" identity - / name ; other identities - - dot-atom = <unquoted word as per [RFC2822]> - quoted-string = <quoted string as per [RFC2822]> - comment = <comment string as per [RFC2822]> - CFWS = <comment or folding white space as per [RFC2822]> - FWS = <folding white space as per [RFC2822]> - CRLF = <standard end-of-line token as per [RFC2822]> - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 47] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - -Appendix B. Extended Examples - - These examples are based on the following DNS setup: - - ; A domain with two mail servers, two hosts - ; and two servers at the domain name - $ORIGIN example.com. - @ MX 10 mail-a - MX 20 mail-b - A 192.0.2.10 - A 192.0.2.11 - amy A 192.0.2.65 - bob A 192.0.2.66 - mail-a A 192.0.2.129 - mail-b A 192.0.2.130 - www CNAME example.com. - - ; A related domain - $ORIGIN example.org. - @ MX 10 mail-c - mail-c A 192.0.2.140 - - ; The reverse IP for those addresses - $ORIGIN 2.0.192.in-addr.arpa. - 10 PTR example.com. - 11 PTR example.com. - 65 PTR amy.example.com. - 66 PTR bob.example.com. - 129 PTR mail-a.example.com. - 130 PTR mail-b.example.com. - 140 PTR mail-c.example.org. - - ; A rogue reverse IP domain that claims to be - ; something it's not - $ORIGIN 0.0.10.in-addr.arpa. - 4 PTR bob.example.com. - -B.1. Simple Examples - - These examples show various possible published records for - example.com and which values if <ip> would cause check_host() to - return "Pass". Note that <domain> is "example.com". - - v=spf1 +all - -- any <ip> passes - - v=spf1 a -all - -- hosts 192.0.2.10 and 192.0.2.11 pass - - - -Wong & Schlitt Expires December 8, 2005 [Page 48] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - - v=spf1 a:example.org -all - -- no sending hosts pass since example.org has no A records - - v=spf1 mx -all - -- sending hosts 192.0.2.129 and 192.0.2.130 pass - - v=spf1 mx:example.org -all - -- sending host 192.0.2.140 passes - - v=spf1 mx mx:example.org -all - -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass - - v=spf1 mx/30 mx:example.org/30 -all - -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes - - v=spf1 ptr -all - -- sending host 192.0.2.65 passes (reverse DNS is valid and is in - example.com) - -- sending host 192.0.2.140 fails (reverse DNS is valid, but not - in example.com) - -- sending host 10.0.0.4 fails (reverse IP is not valid) - - v=spf1 ip4:192.0.2.128/28 -all - -- sending host 192.0.2.65 fails - -- sending host 192.0.2.129 passes - -B.2. Multiple Domain Example - - These examples show the effect of related records: - - example.org: "v=spf1 include:example.com include:example.net -all" - - This record would be used if mail from example.org actually came - through servers at example.com and example.net. Example.org's - designated servers are the union of example.com's and example.net's - designated servers. - - la.example.org: "v=spf1 redirect=example.org" - ny.example.org: "v=spf1 redirect=example.org" - sf.example.org: "v=spf1 redirect=example.org" - - These records allow a set of domains that all use the same mail - system to make use of that mail system's record. In this way, only - the mail system's record needs to be updated when the mail setup - changes. These domains' records never have to change. - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 49] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - -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 - 15.15.168.192.joel.remote-users A 127.0.0.2 - 16.15.168.192.joel.remote-users A 127.0.0.2 - - The following records describe users at example.com who mail from - arbitrary servers, or who mail from personal servers. - - example.com: - - v=spf1 mx - include:mobile-users._spf.%{d} - include:remote-users._spf.%{d} - -all - - mobile-users._spf.example.com: - - v=spf1 exists:%{l1r+}.%{d} - - remote-users._spf.example.com: - - v=spf1 exists:%{ir}.%{l1r+}.%{d} - -B.4. Multiple Requirements Example - - Say that your sender policy requires that both the IP address is - within a certain range and that the reverse DNS for the IP matches. - This can be done several ways, including: - - example.com. SPF ( "v=spf1 " - "-include:ip4._spf.%{d} " - "-include:ptr._spf.%{d} " - "+all" ) - ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all" - 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. - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 50] - -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 - - -Authors' Addresses - - Meng Weng Wong - Singapore - - Email: mengwong+spf@pobox.com - URI: http://spf.pobox.com/ - - - Wayne Schlitt - 4615 Meredeth #9 - Lincoln Nebraska, NE 68506 - United States of America - - Email: wayne@schlitt.net - URI: http://www.schlitt.net/spf/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Wong & Schlitt Expires December 8, 2005 [Page 55] - -Internet-Draft Sender Policy Framework (SPF) June 2005 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -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. - - - - -Wong & Schlitt Expires December 8, 2005 [Page 56] - |
