Hi John.
Thanks for contacting us. I am one of the council members, and this is
what I can answer without consulting the council:
John Glube wrote:
Can anyone from the Council tell us what is the present
status of the IESG evaluation of
draft-schlitt-spf-classic-00.txt?
We are generally aware of the IESG's comments on -spf-classic-00, and we
are preparing a -01 revision of the draft in which we are going to address
some of them. Sorry, I, personally, cannot give you a timeframe for that
right now.
In particular, I ask the following questions:
* Are the authors prepared to make the proposed change to
the final sentence in section 2.4?
The sentence in issue presently reads:
"Checking other identities against SPF records is NOT
RECOMMENDED because there are cases that are known to give
incorrect results."
The IESG suggested this sentence read:
"Checking other identities against SPF records is not
defined in this document."
Although the council has not made a formal decision on that (and perhaps
won't), I can predict with high confidence that this proposed change will
_not_ be approved the council.
Rationale: The current SPF Classic specification -- unfortunately, some
might say -- defines not just the SPF algorithm, but also how it is to be
applied to "v=spf1" records in particular. A large number of "v=spf1"
records have already been published, and making the above change would
imply allowing the semantics of those records to be changed by another
specification. This exact issue has been discussed in the past by the
council and at least three of five of the council members consider such an
implication to be absolutely prohibitive (and the majority of the project
community supports that decision). Also see our latest press release[1].
A way out of this might be to abstract the SPF algorithm from the
application of "v=spf1" record checking into a separate draft. I don't
know what implications that would have on the standardization process, but
I will incite discussion of this possibility.
* What other issues if any are outstanding before
draft-schlitt-spf-classic-00.txt can move forward for last
call and then adoption as an experimental proposal?
As I wrote above, we are currently preparing a -01 revision that will
solve most of the outstanding issues. As I haven't been in contact with
our draft editor lately, I cannot confidently and concludingly elaborate
on those changes at the moment. The first of several pre-releases of -01
is planned for this week-end.
Presuming this draft achieves experimental status, one other
question:
* Since draft schlitt-spf-classic-00.txt is an experimental
proposal, what steps if any is the SPF council going to take
to assess user feedback and testing results by the large
consumer ISPs in deciding how to move forward with a DNS
based proposal for e-mail authentication?
The spf-discuss mailing list is an open forum, and anyone who has to offer
constructive comments on the SPF specification (or related matters) is
most welcome to voice them here. Meng Weng Wong and several members of
the project community are in contact with large ISPs and are collecting
input from them; this has been happening semi-actively so far. The SPF
project has also been in loose contact with alternative e-mail sender
authentication projects, specifically including Yahoo's DomainKeys,
Identified Internet Mail (IIM), and Microsoft's Sender-ID.
Do you think there would be a need for any more pro-active efforts in this
direction?
Julian Mehnle,
SPF Council Member.
References:
1. http://spf.mehnle.net/Press_Release/2005-03-23