--- draft-schlitt-spf-classic-01.clean.txt 2005-05-20 01:37:48.000000000 -0500 +++ draft-schlitt-spf-classic-02pre1.clean.txt 2005-05-30 02:13:11.000000000 -0500 @@ -43,11 +43,11 @@ 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. This document - describes version 1 of the SPF protocol, whereby a domain can - explicitly authorize the hosts that are allowed to use its domain - name in a reverse-path, and a receiving host can check such - authorization. + host can use as the reverse-path of a message or the domain given on + the SMTP HELO/EHLO commands. This document describes version 1 of + the SPF protocol, whereby a domain can explicitly authorize the hosts + that are allowed to use its domain name, and a receiving host can + check such authorization. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 @@ -93,7 +93,7 @@ 5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.5. "ptr" . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 22 - 5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 24 6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 24 6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 25 @@ -255,9 +255,9 @@ in Section 3. This record authorizes the use of the domain name in the "HELO" and "MAIL FROM" identities by the MTAs it specifies. - It is RECOMMENDED that domains publish SPF records that end in - "-all", or redirect to other records that do, so that a definitive - determination of authorization can be made. + 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. Domain holders may publish SPF records that explicitly authorize no hosts if mail should never originate using that domain. @@ -376,12 +376,13 @@ 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 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: + [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: @@ -393,15 +394,15 @@ 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. + subject the message to closer scrutiny than normal. - Since the domain has discouraged the use of this host, receivers MAY - try to inform either the sender or the recipient of the e-mail. For + The domain owner wants to discourage the use of this host and so they + desire limited feedback when a "SoftFail" result occurs. For example, the recipient's MUA could highlight the "SoftFail" status, - or the MTA could give the sender a message using a technique called - "greylisting" whereby the MTA can issue an SMTP reply code of 451 - (4.3.0 DSN code) with a note the first time the message is received, - but accept it the second time. + 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 @@ -415,10 +416,11 @@ 2.5.7. PermError A "PermError" result means that the domain's published records - couldn't be correctly interpreted. Checking software should treat - this result similar to the "SoftFail" result. Be aware that if the - domain owner uses macros (Section 8), it is possible that this result - is due to the checked identities having an unexpected format. + 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. 3. SPF Records An SPF record is a DNS Resource Record (RR) that declares which hosts @@ -459,12 +461,14 @@ [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. - 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 @@ -957,8 +961,12 @@ ip6-cidr-length = "/" 1*DIGIT dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] - ip4-network = - ; e.g. 192.0.2.0 + ip4-network = ... + qnum = 2*1DIGIT + / "1" 2DIGIT + / "2" ("0" / "1" / "2" / "3" / "4" ) DIGIT + / "25" ("0" / "1" / "2" / "3" / "4" / "5" ) + ; as per conventional dotted quad notation. e.g. 192.0.2.0 ip6-network = ; e.g. 2001:DB8::CD30 @@ -969,7 +977,6 @@ 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. - 5.7. "exists" This mechanism is used to construct an arbitrary domain name that is @@ -1103,7 +1110,7 @@ generated with detailed, custom instructions Note: During recursion into an "include" mechanism, an exp= modifier - from the target domain MUST NOT be used. In contrast, when executing + from the MUST NOT be used. In contrast, when executing a "redirect" modifier, an exp= modifier from the original domain MUST NOT be used. 7. The Received-SPF header field @@ -1122,7 +1129,7 @@ header has the format: header = "Received-SPF:" [CFWS] result FWS [comment FWS] - [ key-value-list ] + [ key-value-list ] CRLF result = "Pass" / "Fail" / "SoftFail" / "Neutral" / "None" / "TempError" / "PermError" @@ -1133,10 +1140,10 @@ key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) key = "client-ip" / "envelope-from" / "helo" / - "problem" / "receiver" / "scope" / + "problem" / "receiver" / "identity" / mechanism / "x-" name / name - scope = "mfrom" ; for the "MAIL FROM" identity + identity = "mailfrom" ; for the "MAIL FROM" identity / "helo" ; for the "HELO" identity / name ; other identities @@ -1145,6 +1152,7 @@ comment = CFWS = FWS = + CRLF = The header SHOULD include a "(...)" style after the result, conveying supporting information for the result, such as , @@ -1154,6 +1162,7 @@ SPF clients SHOULD give enough information so that the SPF results can be verified. That is, at least the "client-ip", "helo", and, if the "MAIL FROM" identity was checked, the "envelope-from". + client-ip the IP address of the SMTP client envelope-from the envelope sender mailbox @@ -1167,7 +1176,7 @@ receiver the host name of the SPF client - scope the identity that was checked, see the ABNF + identity the identity that was checked, see the ABNF rule. Other keys may be defined by SPF clients. Until a new key name @@ -1188,7 +1197,7 @@ Received-SPF: Fail (mybox.example.org: domain of myname@example.com does not designate 192.0.2.1 as permitted sender) - client-ip=192.0.2.1; + identity=mailfrom; client-ip=192.0.2.1; envelope-from=; 8. Macros @@ -1588,13 +1597,16 @@ that do DNS lookups to at most 10 per SPF check. If this number is exceeded during a check, a PermError MUST be returned. The "include", "a", "mx", "ptr", and "exists" mechanisms as well as the - "redirect" and "exp" modifiers do count against this limit. The - "all", "ip4" and "ip6" mechanisms do not require DNS lookups and - therefore do not count against this limit. + "redirect" modifier do count against this limit. The "all", "ip4" + and "ip6" mechanisms do not require DNS lookups and therefore do not + count against this limit. The "exp" modifier does not count against + this limit because the DNS lookup to fetch the explanation string + occurs after the SPF record has been evaluated. When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, there MUST be a limit of no more than 10 MX or PTR RRs looked up and checked. + 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 @@ -1676,18 +1688,6 @@ 10.5. Untrusted Information Sources - 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 - 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 source is the SPF record published by the domain in the - identity claimed by that very sender. To put it another way, the - only people who see malicious explanation strings are people whose - messages claim to be from domains that publish such strings in their - SPF records. SPF uses information supplied by third parties, such as the "HELO" domain name, the "MAIL FROM" address, and SPF records. This information is then passed to the receiver in the Received-SPF: mail @@ -1695,6 +1695,23 @@ 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 + 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 + email and then later generates a DSN to a forged address, or when an + email forwarder does not direct the DSN back to the original sender. + 10.6. Privacy Exposure Checking SPF records causes DNS queries to be sent to the domain @@ -1871,11 +1888,14 @@ ip6-cidr-length = "/" 1*DIGIT dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] - ip4-network = - ; e.g. 192.0.2.0 + ip4-network = ... + qnum = 2*1DIGIT + / "1" 2DIGIT + / "2" ("0" / "1" / "2" / "3" / "4" ) DIGIT + / "25" ("0" / "1" / "2" / "3" / "4" / "5" ) + ; conventional dotted quad notation. e.g. 192.0.2.0 ip6-network = ; e.g. 2001:DB8::CD30 - domain-spec = macro-string domain-end domain-end = ( "." toplabel ) / macro-expand toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum @@ -1897,7 +1917,7 @@ name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) header = "Received-SPF:" [CFWS] result FWS [comment FWS] - [ key-value-list ] + [ key-value-list ] CRLF result = "Pass" / "Fail" / "SoftFail" / "Neutral" / "None" / "TempError" / "PermError" @@ -1908,10 +1928,10 @@ key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) key = "client-ip" / "envelope-from" / "helo" / - "problem" / "receiver" / "scope" / + "problem" / "receiver" / "identity" / mechanism / "x-" name / name - scope = "mfrom" ; for the "MAIL FROM" identity + identity = "mailfrom" ; for the "MAIL FROM" identity / "helo" ; for the "HELO" identity / name ; other identities @@ -1920,6 +1940,7 @@ comment = CFWS = FWS = + CRLF = Appendix B. Extended Examples These examples are based on the following DNS setup: