-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
as a member of the sitting council, I'd like to share my views on how the
project fared in the past 13 months since the first council was elected.
I'll go from my previous election platform[1] and examine if we achieved
the goals I set there:
| "Solve forgery soon, and spam eventually."
Well... ;-)
| Finish the SPFv1 AKA SPF Classic specification in a sensible, most
| consistent and backwards compatible way, mostly in the spirit of
| Wayne's draft. Submit the final spec to the IETF.
The spec has not yet been published as an RFC, and depending on whether my
IESG appeal will be escalated to the IAB (see one of my next mails for my
position on that), this may take some more time. However, I think the
community's and Wayne's work on the spec has been immensely successful.
We have produced one of the most comprehensive and considerate
specifications for something of the complexity of SPF that I have ever
seen (which may not mean much, but since SPF isn't rocket science...).
The community-based input and review approach has also worked very well,
although sometimes there was more discussion required to resolve certain
issues than might have been appropriate, but I guess that's how
democracies go.
In hindsight, I think it might have been possible to side-step the IETF
clashes with the Sender-ID specs and get SPFv1 published as a Proposed
Standard instead of an Experimental RFC _without_ giving up our position
of recommending against the re-use of v=spf1 records for PRA checking.
But that would have required a significantly more solid knowledge of what
had happened behind the scenes during and shortly after the MARID disaster
and about the various actors' positions and agendas (no, this doesn't
specifically mean Meng, although I wouldn't exclude him either), which was
obviously difficult to obtain. There were attempts[2] to come to an
amicable agreement with Microsoft, but they failed due to lack of
communication between us and them, ultimately mostly due to a blatant lack
of interest on Microsoft's side in such an agreement, I think.
| Explain to the public that SPF Classic is not Sender-ID/PRA. Make no
| substantial concessions to Microsoft or other political stakeholders
| against technical reason. Nevertheless do clever PR.
At least passively we have never failed this goal. We have managed to stay
firm on our position to let our design decisions on the spec be guided by
technical reason only, which I see very positively. It might have been
possible to work more actively on public relations, but the other work on
the spec etc. was deemed more important at the time, and since most of the
project participants are volunteers and do all the work in their free
time, probably not much more time could have been spent on PR. I think it
might have been useful to start a "Spread SPF!" campaign similar to the
one the Mozilla Firefox folks did.
| Advocate SPF Classic to ESPs and implementors as a solution to the
| envelope sender forgery problem. Develop and advocate SES, SRS, et al
| as equivalent alternative solutions to the forwarding problem (let the
| market decide).
I think Meng contributed a lot to the project by taking advantage of his
high profile as the inventor of SPF and attending lots of conferences,
advocating SPF and Sender-ID to ESPs (although I think his emphasis was
probably more on Sender-ID than on SPF, which was of course due to him in
turn wanting to take advantage of the high profile of Microsoft). Meng
was in the best position to do that work, however it might have also been
possible to incite a grassroots campaign to get ESPs to support SPF.
On the SES and SRS fronts, not much happened, which is of course barely
surprising given that the SES project apparently died in mid-2004 and the
SRS project had working implementations developed already. For either to
succeed on a larger scale, it would have been necessary to achieve better
integration in existing mail software packages and OS distributions. (To
be fair, the same applies to SPF.) Instead, the SPF project went the path
of least resistance and tried to define away the forwarding problem by
saying that receivers should simply white-list their forwarders.
Personally, I do agree with that approach, but it seems we overlooked that
such end-user-side forwarder white-listing requires implementation in mail
software packages, too.
Anyway, the market did decide, and as a result SPF was less successful than
it could have been.
| Make plans on what to do next. SPFv1.5? SPFv2? End-to-end crypto
| such as S/MIME? Domain-based reputation systems (cf. SpamCop?)?
Since it took us so long to get anywhere with the spec after we finished it
in June 2005 (it could have been through the IESG review and RFC Editor
queue in October or so, I think), we didn't manage to make plans on what
to do next. I expected that we would have done more on at least the
domain-based reputation front, but it simply didn't happen.
| If, after 9 months, the project appears to be continuing beyond the
| first year so that a new council will have to be elected, draft a new
| charter and establish proper election procedures.
This has been achieved, although definitely too late. The community, which
has kept an acceptable level of coherence, decided that the project needs
to go on and that the setup of the council was mostly a good thing that
should be retained for at least a year. No charter has been drafted (due
to the standardization of the spec still not having come to a close and no
plans having been made for the future), but since a lot of infrastructure
(the old and new website, instruments for effective decision making, etc.)
has been built, I think the project is in a good position to set new goals
and achieve both new and old ones in the coming year.
I'd love to read your comments on all this.
Julian.
References:
1.
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200411/0582.html
2.
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200506/0731.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDxG/GwL7PKlBZWjsRAnVHAJ9Fb7NyDfV2RKbqkMQgjfMxzN9mHACg1o2T
7EKAwbyWlSheDoQY69+rhCM=
=8grA
-----END PGP SIGNATURE-----
-------
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