On Fri, 24 Mar 2006, Julian Mehnle wrote:
I just talked to Meng, and he pointed out to me that the RFC Editor might
not strictly require the explicit approval of all document authors[1], so
we're now definitely going to proceed without Wayne.
Please do. Its unfortunate we can not contact Wayne (and I tried using
his whois-listed phone as well), hope nothing bad happened...
I'll complete the list of last-minute changes[2] and send it to Meng on
Sunday. If anyone wants anything on that list, raise your voice ASAP!
THIS IS OUR LAST CHANCE!
Modify proposed http://new.openspf.org/draft-schlitt-spf-classic_AUTH48_changes
in Section 7, see below for details
I also know that there were some ABNF grammar fixes, but when I went
looking for them in my spf-discuss archives earlier today I couldn't
find any specifics.
I still don't know what those ABNF grammar fixes are supposed to be. If I
don't find out _very_ soon, they will be left out.
Regarding over-restrictive domain specification the fixes are as follows:
toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum
; LDH rule (See [RFC3696])
Change to:
toplabel = alphanum [ *[ alphanum / "-" ] alphanum ] [ "." ]
; LDH rule (See [RFC3696])
(the changes effects are as follows:
1. Domain name can start and end with alpha or digit - but not "-"
2. Domain specification can optionally include "." at the end)
And change
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
to
name = alphanum *( ALPHA / DIGIT / "-" / "_" / "." )
(Also allows name to start with digit. Note that I'm not entirely sure,
but its possible that we should be a bit more restrictive and change
to disallow name from ending in "-" or "_")
And there was the SPF/TXT RR synchronicity issue, the proposed solution
of which I don't know, and which according to Wayne probably requires
approval from the IESG to be fixed.
See thread http://www.mhonarc.org/archive/html/spf-discuss/2006-01/msg00115.html
The issue is that DNS TXT And SPF records can get out of sync in the cache of
ISP's caching dns servers used by local users.
Ditto, mostly. This seems to be more important, though, so I'll try to
figure it out tomorrow and present my solution here for review.
The change necessary is probably as follows:
4.5. Selecting Records
...
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.
reduce this to:
4.5. Selecting Records
...
2. If any records of type SPF are in the set, then all records of
type TXT are discarded.
Frank and others, could you please help me trying to make the above
items more specific and recall the other items that were on Wayne's
list?
Other issues I see (most on use of header, headers, header fields):
--------------------------------------------------------------------------
| 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
^- this is actually ok but maybe a bit
confusing
as many understand headers to mean header
fields
| so, it SHOULD use the "Received-SPF" header defined here for each
^-- adding "field" here
| identity that was checked. This information is intended for the
| recipient. (Information intended for the sender is described in
| Section 6.2, Explanation.)
^-- move (...) within previous sentence
| The Received-SPF header is a trace field (see [RFC2822] Section
^-- removed it
| 3.6.7) and SHOULD be prepended to existing headers, above the
^- making singular
| Received: header that is generated by the SMTP receiver. It MUST
| appear above any other Received-SPF headers in the message. The
^-- I sense tense error: above any <singular noun>
| header has the format as follows:
| ^-- add field
| ...
|
| The header SHOULD include a "(...)" style <comment> after the
^-- adding field
| conveying supporting information for the result, such as <ip>,
| <sender>, and <domain>.
| ...
| SPF clients MUST make sure that the Received-SPF header does not
^-- adding field
| contain invalid characters, is not excessively long, and does not
| contain malicious data that has been provided by the sender
The new text I propose is as follows:
7. The Received-SPF Header Field
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 is a trace field (see [RFC2822] Section 3.6.7) and
SHOULD be prepended to existing header, above the Received: header
field that is generated by the SMTP receiver. It MUST appear above
other Received-SPF header fields in the message. The header field
has the following format:
header-field = "Received-SPF:" [CFWS] result FWS [comment FWS]
[ key-value-list ] CRLF
....
The header field SHOULD include a "(...)" style <comment> after the
result, conveying supporting information for the result, such as <ip>,
<sender>, and <domain>.
....
SPF clients MUST make sure that the Received-SPF header field does
not contain invalid characters, is not excessively long, and does
not contain malicious data that has been provided by the sender.
--------------------------------------------------------------------------
9.5. MTA Relays
...
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. ^-- guess what...
change to
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 message header.
Testing other than at the border is not recommended.
--------------------------------------------------------------------------
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 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.
change to:
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 the message 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.
More serious problems:
The title of that section is "SPF-Authorized E-Mail May Be UBE" however
what it does talk about is that email may contain other false identities.
Besides that it is quite possible for fully correct email with all
identities verified to be UBE! What needs to be done is write separate
section on "SPF authorized email maybe ube" and separate one on that
spf authorized email may have other false identities. New section however
is not a minor editorial change, so a simpler solution is to change title
of the section (don't forget to also do it in ToC) to be:
10.2. SPF-Authorized E-Mail May Contain Other False Identities
--------------------------------------------------------------------------
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.
change to:
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.
--------------------------------------------------------------------------
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.
change to
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: trace
fields and possibly returned to the client MTA in the form of an
SMTP rejection message. This information must be checked for invalid
characters and excessively long lines.
--------------------------------------------------------------------------
12.2. The Received-SPF Mail Header
optionally change title to:
12.3. The Received-SPF Mail Header Field
Note: changing title here also means changing ToC at the start of document
--------------------------------------------------------------------------
Appendix A. Collected ABNF
...
header = "Received-SPF:" [CFWS] result FWS [comment FWS]
[ key-value-list ] CRLF
to sync with change I proposed:
header-field = "Received-SPF:" [CFWS] result FWS [comment FWS]
[ key-value-list ] CRLF
--------------------------------------------------------------------------
That is it for now...
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com