Sender Policy Framework (SPF) News
----------------------------------
by Wayne Schlitt, June 24, 2005
Greetings!
The IETF has accepted the SPF specification for RFC status!
A little over a month ago, we restarted this spf-announce mailing list
with a few updates of what had happened in the last year. Since
then, we have been hard at work on several things, and the first to
bear fruit is the SPF specification.
This SPF specification aims to clearly define the semantics of SPF,
based on the older SPF specifications from late 2003 and early 2004,
taking into account the state of SPF implementations and making
adjustments that have been requested by the IETF. This latest SPF
specification has undergone considerable review, not only by the SPF
community, but also by various IETF groups.
On June 6th, we submitted the completed draft for consideration by the
IETF, and today, the IETF has voted to accept the SPF specification as an
"Experimental" RFC[1]. The SPF specification still needs to go through the
RFC Editor, and this can take weeks or even months to complete.
(There are currently around 300 draft RFCs in the editor queue.)
We had asked for consideration as a "Standards Track" RFC rather than
"Experimental", but the IETF has informed us that they would only
consider "Experimental" status[2]. This was not a big surprise, but we
were surprised at some of the other actions that they took.
The IETF has decided that the SPF specification can not be made into
an RFC until the Sender ID specification is also ready. This appears
to be in order to be 'fair' to Microsoft[3]. Moreover, the IETF has
declared that the last 1.5 years of SPF deployment will not count
toward the two year requirement for experimental testing that they
have set. Again, this is to be 'fair' to Microsoft since their
testing has barely begun.
The Sender ID specifications call for the reuse of SPF version 1
records in incompatible ways in conflict with the SPF specification.[4]
We have made our objections clear to the IETF, but so far, the IETF
appears to be ready to bless this abuse of SPF records.[5] We will
continue to work to try and make SPF as reliable as possible.
[1] https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12662&rfc_flag=0
[2] http://thread.gmane.org/gmane.mail.spam.spf.council/312
[3] http://thread.gmane.org/gmane.mail.spam.spf.council/314
[4] http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-02.html#anchor6
[5] http://thread.gmane.org/gmane.mail.spam.spf.council/333
----------
To unsubscribe from this list, or change the email address where you receive messages,
please go to http://v2.listbox.com/member/?listname=spf-announce@v2.listbox.com
----------------------------------
by Wayne Schlitt, June 24, 2005
Greetings!
The IETF has accepted the SPF specification for RFC status!
A little over a month ago, we restarted this spf-announce mailing list
with a few updates of what had happened in the last year. Since
then, we have been hard at work on several things, and the first to
bear fruit is the SPF specification.
This SPF specification aims to clearly define the semantics of SPF,
based on the older SPF specifications from late 2003 and early 2004,
taking into account the state of SPF implementations and making
adjustments that have been requested by the IETF. This latest SPF
specification has undergone considerable review, not only by the SPF
community, but also by various IETF groups.
On June 6th, we submitted the completed draft for consideration by the
IETF, and today, the IETF has voted to accept the SPF specification as an
"Experimental" RFC[1]. The SPF specification still needs to go through the
RFC Editor, and this can take weeks or even months to complete.
(There are currently around 300 draft RFCs in the editor queue.)
We had asked for consideration as a "Standards Track" RFC rather than
"Experimental", but the IETF has informed us that they would only
consider "Experimental" status[2]. This was not a big surprise, but we
were surprised at some of the other actions that they took.
The IETF has decided that the SPF specification can not be made into
an RFC until the Sender ID specification is also ready. This appears
to be in order to be 'fair' to Microsoft[3]. Moreover, the IETF has
declared that the last 1.5 years of SPF deployment will not count
toward the two year requirement for experimental testing that they
have set. Again, this is to be 'fair' to Microsoft since their
testing has barely begun.
The Sender ID specifications call for the reuse of SPF version 1
records in incompatible ways in conflict with the SPF specification.[4]
We have made our objections clear to the IETF, but so far, the IETF
appears to be ready to bless this abuse of SPF records.[5] We will
continue to work to try and make SPF as reliable as possible.
[1] https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12662&rfc_flag=0
[2] http://thread.gmane.org/gmane.mail.spam.spf.council/312
[3] http://thread.gmane.org/gmane.mail.spam.spf.council/314
[4] http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-02.html#anchor6
[5] http://thread.gmane.org/gmane.mail.spam.spf.council/333
----------
To unsubscribe from this list, or change the email address where you receive messages,
please go to http://v2.listbox.com/member/?listname=spf-announce@v2.listbox.com