######################################################################### # Table of Contents # ######################################################################### OLD: [...] 10.2. SPF-Authorized E-Mail May Be UBE .........................35 [...] 12.2. The Received-SPF Mail Header .............................37 [...] CHANGES: [...] 10.2. SPF-Authorized E-Mail May Contain Other False Identities .35 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^-changed [...] 12.2. The Received-SPF Mail Header Field .......................37 ^^^^^^-changed [...] NEW: [...] 10.2. SPF-Authorized E-Mail May Contain Other False Identities .35 [...] 12.2. The Received-SPF Mail Header Field .......................37 [...] REASON: Reflect changes from below in the ToC. ######################################################################### # Section 2.4, 2nd paragraph # ######################################################################### OLD: [...] The scenario described in Section 9.3. is another example. [...] CHANGES: [...] The scenario described in Section 9.3, sub-section 1.2, is ^^^^^^^^^^^^^^^^^^-added another example. [...] NEW: [...] The scenario described in Section 9.3, sub-section 1.2, is another example. [...] REASON: Not section 9.3 in general is meant, but the scenario in section 9.3.1.2 in particular. ######################################################################### # Section 2.5, 2nd paragraph # ######################################################################### OLD: [...] such as the following: (1) It may be difficult to accurately extract the required information from potentially deceptive headers; and (2) legitimate E-Mail may fail because the sender's policy may have since changed. CHANGES: [...] such as the following: (1) It may be difficult to accurately extract the required information from potentially deceptive headers; and (2) legitimate E-Mail may fail because the sender's policy may ^^^-removed have since changed. NEW: [...] such as the following: (1) It may be difficult to accurately extract the required information from potentially deceptive headers; (2) legitimate E-Mail may fail because the sender's policy may have since changed. REASON: The enumeration of problems is not exhaustive. ######################################################################### # Section 2.5.2 # ######################################################################### OLD: The domain owner has explicitly stated that it cannot or does not [...] Treating "Neutral" more harshly than "None" will discourage domain owners from testing the use of SPF records (see Section 9.1). CHANGES: The domain owner has explicitly stated that he cannot or does not ^^-changed [...] Treating "Neutral" more harshly than "None" would discourage ^^^^^-changed domain owners from testing the use of SPF records (see Section 9.1). NEW: The domain owner has explicitly stated that he cannot or does not [...] Treating "Neutral" more harshly than "None" would discourage domain owners from testing the use of SPF records (see Section 9.1). REASON: The domain owner is generally a person, not an organization; use conditional "would". ######################################################################### # Section 3.1, 1st paragraph # ######################################################################### OLD: [...] This is the same whether the TXT or SPF RR type is used. CHANGES: [...] This is the same whether the TXT or SPF RR type (see Section added-^^^^^^^^^^^^^ 3.1.1) is used. ^^^^^^-added NEW: [...] This is the same whether the TXT or SPF RR type (see Section 3.1.1) is used. REASON: SPF RR type has not been introduced at this stage of document. ######################################################################### # Section 3.1.1, 1st paragraph # ######################################################################### OLD: This document defines a new DNS RR of type SPF, 99. [...] CHANGES: This document defines a new DNS RR of type SPF, code 99. [...] ^^^^-added NEW: This document defines a new DNS RR of type SPF, code 99. [...] REASON: Clarification. ######################################################################### # Section 3.1.3, 1st paragraph # ######################################################################### OLD: 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. [...] CHANGES: As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS record (either TXT or SPF RR types) can be composed of more than one ^^-changed from "and" string. [...] NEW: As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS record (either TXT or SPF RR types) can be composed of more than one string. [...] REASON: Grammar error -- "either" requires "or". ######################################################################### # Section 4.4, 2nd paragraph # ######################################################################### OLD: 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". CHANGES: If all DNS lookups that are made return a server failure (RCODE 2), ^^^-changed ^^^^^^^^^^^^^^^^^^^^^^-changed or other error (RCODE other than 0 or 3), or the query times out, removed-^^^^^^^^^ ^-removed then check_host() exits immediately with the result "TempError". NEW: If all DNS lookups that are made return a server failure (RCODE 2), or other error (RCODE other than 0 or 3), or time out, then check_host() exits immediately with the result "TempError". REASON: Even if both TXT and SPF records are always changed at the same time in DNS zone and kept in sync, they can get out of sync on caching DNS servers. For this reason giving "PermError" when records do not match is inappropriate and SPF-type records should be preferred over TXT-type ones (see the following change). Thus, only if _both_ lookups fail should "TempError" be given. NOTE: This change may require IESG review. ######################################################################### # Section 4.5 # ######################################################################### OLD: 1. Records that do not begin with a version section of exactly "v=spf1" are discarded. Note that the version section is terminated either by an SP character or the end of the record. A record with a version section of "v=spf10" does not match and must be discarded. 2. If 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. CHANGES: 2. If there are both SPF and TXT records in the set and if they are ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^-removed not all identical, return a "PermError". ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^-removed 3. If any records of type SPF are in the set, then all records of ^^-changed to "2." NEW: 1. Records that do not begin with a version section of exactly "v=spf1" are discarded. Note that the version section is terminated either by an SP character or the end of the record. A record with a version section of "v=spf10" does not match and must be discarded. 2. If any records of type SPF are in the set, then all records of type TXT are discarded. REASON: Even if both TXT and SPF records are always changed at the same time in DNS zone and kept in sync, they can get out of sync on caching DNS servers. For this reason giving "PermError" when records do not match is inappropriate and SPF-type records should be preferred over TXT-type ones. NOTE: This change may require IESG review. ######################################################################### # Section 4.6.2, 2nd paragraph # ######################################################################### OLD: When a mechanism is evaluated, one of three things can happen: it can match, it cannot match, or it can throw an exception. CHANGES: When a mechanism is evaluated, one of three things can happen: it can match, it cannot match, or it can throw an exception. ^^^^^^-removed ^^^^^^^-removed NEW: When a mechanism is evaluated, one of three things can happen: it can match, not match, or throw an exception. REASON: In the enumeration of possibilities, "not match" is /more/ of a semantical unit than "can not" (AKA "cannot"). ######################################################################### # Section 5, 7th paragraph # ######################################################################### OLD: If no CIDR-length is given in the directive, then and the IP address are compared for equality. Here, CIDR is Classless Inter- Domain Routing. CHANGES: If no CIDR-length is given in the directive, then and the IP address are compared for equality. (Here, CIDR is Classless Inter- Domain Routing.) ^^-added ^-added NEW: If no CIDR-length is given in the directive, then and the IP address are compared for equality. (Here, CIDR is Classless Inter- Domain Routing.) REASON: The explanation of the term "CIDR" is only a secondary detail. ######################################################################### # Section 5.6, ABNF definitions # ######################################################################### OLD: [...] 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 = ; e.g., 2001:DB8::CD30 CHANGES: [...] ip4-cidr-length = "/" 1*DIGIT ^-added line break ip6-cidr-length = "/" 1*DIGIT ^-added line break dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] ip4-network = qnum "." qnum "." qnum "." qnum ^-added line break qnum = DIGIT ; 0-9 ^-removed line break / %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 removed line break-^ ^-added line break ip6-network = ; e.g., 2001:DB8::CD30 NEW: [...] 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 = ; e.g., 2001:DB8::CD30 REASON: Formatting was garbled. ######################################################################### # Section 6.2, 10th paragraph # ######################################################################### OLD: "%{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 CHANGES: "%{i} is not one of %{d}'s designated mail servers." -- a message with a little more information, including the IP ^^^^^^^-added address that failed the check NEW: "%{i} is not one of %{d}'s designated mail servers." -- a message with a little more information, including the IP address that failed the check REASON: "info" is not a complete word. ######################################################################### # Section 7, 1st to 3rd paragraphs # ######################################################################### OLD: 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 as follows: header = "Received-SPF:" [CFWS] result FWS [comment FWS] [ key-value-list ] CRLF CHANGES: It is RECOMMENDED that SMTP receivers record the result of SPF processing in the message headers. If an SMTP receiver chooses to do ^-removed so, it SHOULD use the "Received-SPF" header field defined here for each ^^^^^-added 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 field is a trace field (see [RFC2822] Section ^^^^^-added 3.6.7) and SHOULD be prepended to the existing headers, above the ^^^-added ^-removed Received: field that is generated by the SMTP receiver. It MUST ^^^^^-changed appear above all other Received-SPF fields in the message. The ^^^-changed ^^^^^^-changed header field has the following format: ^^^^^-added ^^^^^^^^^^^^^^^^-changed header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] ^^^^^^-added [ key-value-list ] CRLF NEW: It is RECOMMENDED that SMTP receivers record the result of SPF processing in the message header. If an SMTP receiver chooses to do so, it SHOULD use the "Received-SPF" header field defined here for each identity that was checked. This information is intended for the recipient. (Information intended for the sender is described in Section 6.2, Explanation.) The Received-SPF header field is a trace field (see [RFC2822] Section 3.6.7) and SHOULD be prepended to the existing header, above the Received: field that is generated by the SMTP receiver. It MUST appear above all other Received-SPF fields in the message. The header field has the following format: header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] [ key-value-list ] CRLF REASON: Several editorial fixes to change 'header' into 'header field' or just 'field' as that is appropriate terminology. Same for several other changes below. ######################################################################### # Section 7, 10th paragraph # ######################################################################### OLD: The header SHOULD include a "(...)" style after the result, CHANGES: The header field SHOULD include a "(...)" style after the ^^^^^-added result, [...] NEW: The header field SHOULD include a "(...)" style after the result, [...] REASON: Correct terminology. ######################################################################### # Section 7, 20th paragraph # ######################################################################### OLD: SPF clients MUST make sure that the Received-SPF header does not [...] CHANGES: SPF clients MUST make sure that the Received-SPF header field does not ^^^^^-added [...] NEW: SPF clients MUST make sure that the Received-SPF header field does not [...] REASON: Correct terminology. ######################################################################### # Section 8.1, ABNF definitions # ######################################################################### OLD: [...] domain-end = ( "." toplabel ) / macro-expand [...] toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum ; LDH rule (See [RFC3696]) [...] CHANGES: [...] domain-end = ( "." toplabel [ "." ] ) / macro-expand ^^^^^^^-added [...] toplabel = ; LDH rule plus additional TLD restrictions changed-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [...] NEW: [...] domain-end = ( "." toplabel [ "." ] ) / macro-expand [...] toplabel = ; LDH rule plus additional TLD restrictions [...] REASON: The current spec is too restrictive and prohibits the use of trailing dots in literal domain names. (They were allowed as the result of macro expansions already.) The definition of TLDs is also too restrictive, but instead of including a complex grammar definition, we just defer to RFC3696. NOTE: This change may require IESG review. ######################################################################### # Section 8.1, 2nd paragraph after the lists and examples # ######################################################################### OLD: 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 that are used instead of ".". CHANGES: 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. Older ^-begin addition implementations of SPF prohibit trailing dots in domain names, so trailing dots should not be published by domain owners, although they must be accepted by implementations conforming to this document. Macros may specify delimiter characters that are used ^-end addition instead of ".". NEW: 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. Older implementations of SPF prohibit trailing dots in domain names, so trailing dots should not be published by domain owners, although they must be accepted by implementations conforming to this document. Macros may specify delimiter characters that are used instead of ".". REASON: The above change allows the use of trailing dots in domain names, however a warning is required that older SPF implementations may not accept it, so trailing dots should not be published. NOTE: This change may require IESG review. ######################################################################### # Section 9.4, 1st paragraph # ######################################################################### OLD: 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. [...] CHANGES: Service providers that offer mail services to third-party domains, such as sending of bulk mail, may want to adjust their setup in light ^^^^-changed of the authorization check described in this document. [...] NEW: Service providers that offer mail services to third-party domains, such as sending of bulk mail, may want to adjust their setup in light of the authorization check described in this document. [...] REASON: SPF is an optional addition to e-mail, so use of "have to" is not appropriate here. ######################################################################### # Section 9.5, 4th paragraph # ######################################################################### OLD: [...] which can be difficult to extract from headers. CHANGES: [...] which can be difficult to extract from the message header. ^^^^^^^^^^^^^^^^^^-changed NEW: [...] which can be difficult to extract from the message header. REASON: Correct terminology. ######################################################################### # Section 10.2, section name # ######################################################################### OLD: 10.2. SPF-Authorized E-Mail May Be UBE CHANGES: 10.2. SPF-Authorized E-Mail May Contain Other False Identities ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^-changed NEW: 10.2. SPF-Authorized E-Mail May Contain Other False Identities REASON: What the section really talks about is that e-mail messages may contain other false identities when it is SPF-authorized. Whether such a message is or is not UBE is a completely separate issue. ######################################################################### # Section 10.2 # ######################################################################### OLD: 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 his own domain in the identities used by SPF, to have that domain's SPF record authorize the sending host, and yet the message content can easily claim other identities in the headers. Unless the user or the MUA takes care to note that the authorized identity does not match the other more commonly-presented identities (such as the From: header), the user may be lulled into a false sense of security. CHANGES: 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 his own domain in the identities used by SPF, to have that domain's SPF record authorize the sending host, and yet the message content can ^^^^^^^-removed easily list other identities in its header. Unless the user or the ^^^^-changed ^^^^^^^^^^-changed MUA takes care to note that the authorized identity does not match the other more commonly-presented identities (such as the From: header field), the user may be lulled into a false sense of security. ^^^^^-added NEW: 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 his own domain in the identities used by SPF, to have that domain's SPF record authorize the sending host, and yet the message can easily list other identities in its header. Unless the user or the MUA takes care to note that the authorized identity does not match the other more commonly-presented identities (such as the From: header field), the user may be lulled into a false sense of security. REASON: Correct terminology. ######################################################################### # Section 10.3, 2nd paragraph # ######################################################################### OLD: [...] See [RFC3833] for a description of the DNS weaknesses. CHANGES: [...] See [RFC3833] for a description of the DNS weaknesses. ^^^-removed NEW: [...] See [RFC3833] for a description of DNS weaknesses. REASON: RFC 3833 contains _known_ weaknesses only, not all that might exist. ######################################################################### # Section 10.5, 1st paragraph # ######################################################################### OLD: [...] This information is then passed to the receiver in the Received-SPF: mail headers and [...] CHANGES: [...] This information is then passed to the receiver in the Received-SPF: trace fields and [...] ^^^^^^^^^^^^-changed NEW: [...] This information is then passed to the receiver in the Received-SPF: trace fields and [...] REASON: Correct terminology. ######################################################################### # Section 11, 4th paragraph # ######################################################################### OLD: [...] They are far too numerous to name, but they include the people on the following mailing lists: NEW: [...] They are far too numerous to name, but they include the following: REASON: The following list contains four mailing lists and one IRC channel. Saying "people on the following mailing lists" is largely redundant, and in the case of the IRC channel outright inappropriate. ######################################################################### # Section 12.1 # ######################################################################### OLD: The IANA has assigned a new Resource Record Type and Qtype from the DNS Parameters Registry for the SPF RR type. CHANGES: The IANA has assigned a new Resource Record Type and Qtype from the DNS Parameters Registry for the SPF RR type with code 99. ^^^^^^^^^^^^^-added NEW: The IANA has assigned a new Resource Record Type and Qtype from the DNS Parameters Registry for the SPF RR type with code 99. REASON: The section should mention the code of the new RR type. ######################################################################### # Section 12.2, section name # ######################################################################### OLD: 12.2. The Received-SPF Mail Header CHANGES: 12.2. The Received-SPF Mail Header Field ^^^^^-added NEW: 12.2. The Received-SPF Mail Header Field REASON: Correct terminology. ######################################################################### # Section 12.2, 2nd paragraph # ######################################################################### OLD: [...] 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/ CHANGES: [...] Requesting SPF Council review of any proposed changes and additions to this field is recommended. For information about the ^^^^-added SPF Council see http://www.openspf.org/Council ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^-changed NEW: [...] Requesting SPF Council review of any proposed changes and additions to this field is recommended. For information about the SPF Council see http://www.openspf.org/Council REASON: The website address of the SPF Council has permanently changed. ######################################################################### # Appendix A, "domain-end", "toplabel", and "header" ABNF definitions # ######################################################################### OLD: [...] domain-end = ( "." toplabel ) / macro-expand [...] toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum ; LDH rule (See [RFC3696]) [...] header = "Received-SPF:" [CFWS] result FWS [comment FWS] [ key-value-list ] CRLF [...] CHANGES: [...] domain-end = ( "." toplabel [ "." ] ) / macro-expand ^^^^^^^-added [...] toplabel = ; LDH rule plus additional TLD restrictions, e.g. com changed-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [...] header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] ^^^^^^-added [ key-value-list ] CRLF [...] NEW: [...] domain-end = ( "." toplabel [ "." ] ) / macro-expand [...] toplabel = ; LDH rule plus additional TLD restrictions, e.g. com [...] header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] [ key-value-list ] CRLF [...] REASON: Reflect the ABNF grammar changes from the document body in the collated ABNF grammar. ######################################################################### # "Authors' Addresses" section # ######################################################################### OLD: Meng Weng Wong Singapore EMail: mengwong(_at_)dumbo(_dot_)pobox(_dot_)com [...] CHANGES: Meng Weng Wong Singapore EMail: mengwong+spf(_at_)pobox(_dot_)com ^^^^^^^^^^^^^^^^^^^^^^-changed [...] NEW: Meng Weng Wong Singapore EMail: mengwong+spf(_at_)pobox(_dot_)com [...] REASON: Meng Weng Wong's e-mail address was inappropriately changed by the RFC Editor. This change should be reverted.