Home | Sitemap | Recent Changes | Login |
Sender Policy Framework
draft-schlitt-spf-classic AUTH48 changes
|
The following are last-minute (AUTH48) changes to draft-schlitt-spf-classic as edited by the RFC Editor. (The list is available in plain-text format as well.) 1 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. 2 Section 2.4, 2nd paragraphOLD: The scenario described in Section 9.3. is another example.
CHANGES:
The scenario described in Section 9.3, sub-section 1.2, is another example.
^^^^^^^^^^^^^^^^^^-added
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. 3 Section 2.5, 2nd paragraphOLD: [...] 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)
^^^-removed
legitimate E-Mail may fail because the sender's policy may 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. 4 Section 2.5.2OLD: The domain owner has explicitly stated that it cannot or does not [...]
CHANGES:
The domain owner has explicitly stated that he cannot or does not [...]
^^-changed
NEW: The domain owner has explicitly stated that he cannot or does not [...] Reason: The domain owner is generally a person, not an organization. 5 Section 2.5.2OLD: [...] Treating "Neutral" more harshly than "None" will discourage domain owners from testing the use of SPF records (see Section 9.1).
CHANGES:
[...] Treating "Neutral" more harshly than "None" would discourage domain
^^^^^-changed
owners from testing the use of SPF records (see Section 9.1).
NEW: [...] Treating "Neutral" more harshly than "None" would discourage domain owners from testing the use of SPF records (see Section 9.1). 6 Section 3.1, 1st paragraphOLD: [...] 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 3.1.1)
added-^^^^^^^^^^^^^^^^^^^^
is used.
NEW: [...] This is the same whether the TXT or SPF RR type (see Section 3.1.1) is used. Reason: SPF RR has not been introduced at this stage of document. 7 Section 3.1.1, 1st paragraphOLD: 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. 8 Section 3.1.3, 1st paragraphOLD: 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". 9 Section 4.4, 2nd paragraphOLD: 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. 10 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. 11 Section 4.6.2, 2nd paragraphOLD: 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"). 12 Section 5, 7th paragraphOLD: If no CIDR-length is given in the directive, then <ip> 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 <ip> 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 <ip> 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. 13 Section 5.6, 3rd paragraphOLD: ip4-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" 1*DIGIT dual- cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
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 ]
NEW: ip4-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" 1*DIGIT dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] Reason: Line breaks were missing. 14 Section 5.6, 4th paragraph
OLD:
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
CHANGES:
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 = <as per [RFC 3513], section 2.2>
; e.g., 2001:DB8::CD30
NEW:
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
Reason: 1st "^": line break was missing; 2nd "^": line break was spurious; 3rd "^": line break was spurious; 4th "^": line break was missing. 15 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 address
^^^^^^^-added
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. 16 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 two other changes to section 7 below. 17 Section 7, 10th paragraphOLD: The header SHOULD include a "(...)" style <comment> after the result,
CHANGES:
The header field SHOULD include a "(...)" style <comment> after the result,
^^^^^-added
NEW: The header field SHOULD include a "(...)" style <comment> after the result, 18 Section 7, 20th paragraphOLD: 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 [...] 19 Section 8.1, "domain-end" and "toplabel" 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 = <TLD label as per [RFC3696], Section 2>
; LDH rule plus additional TLD restrictions, e.g. com
changed-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[...]
NEW:
[...]
domain-end = ( "." toplabel [ "." ] ) / macro-expand
[...]
toplabel = <TLD label as per [RFC3696], Section 2>
; LDH rule plus additional TLD restrictions, e.g. com
[...]
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. 20 Section 8.1, 2nd paragraph after the lists and examplesOLD: 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. 21 Section 9.4, 1st paragraphOLD: 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. 22 Section 9.5, 4th paragraphOLD: [...] 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. 23 Section 10.2, section nameOLD: 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. 24 Section 10.2OLD: 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. 25 Section 10.3, 2nd paragraphOLD: [...] 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. 26 Section 10.5, 1st paragraphOLD: [...] 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. 27 Section 11, 4th paragraphOLD: [...] 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. 28 Section 12.1OLD: 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. 29 Section 12.2, section nameOLD: 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. 30 Section 12.2, 2nd paragraph, "Related information" fieldOLD: 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 SPF
^^^^-added
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. 31 Appendix A, "header" ABNF definition
OLD:
header = "Received-SPF:" [CFWS] result FWS [comment FWS]
[ key-value-list ] CRLF
CHANGES:
header-field = "Received-SPF:" [CFWS] result FWS [comment FWS]
^^^^^^-added
[ key-value-list ] CRLF
NEW:
header-field = "Received-SPF:" [CFWS] result FWS [comment FWS]
[ key-value-list ] CRLF
Reason: Correct terminology. 32 Appendix A, "domain-end" and "toplabel" 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 = <TLD label as per [RFC3696], Section 2>
; LDH rule plus additional TLD restrictions, e.g. com
changed-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[...]
NEW:
[...]
domain-end = ( "." toplabel [ "." ] ) / macro-expand
[...]
toplabel = <TLD label as per [RFC3696], Section 2>
; LDH rule plus additional TLD restrictions, e.g. com
[...]
Reason: Reflect the ABNF grammar changes from the document body in the collated ABNF grammar. 33 "Authors' Addresses" sectionOLD: Meng Weng Wong Singapore EMail: mengwong@dumbo.pobox.com
CHANGES:
Meng Weng Wong
Singapore
EMail: mengwong+spf@pobox.com
^^^^^^^^^^^^^^^^^^^^^^-changed
NEW: Meng Weng Wong Singapore EMail: mengwong+spf@pobox.com Reason: Meng Weng Wong's e-mail address was inappropriately changed. This change should be reverted. |
The SPF ProjectNews About Us DocumentationFAQ Support |