My problem with the position statement is that it bundles a few things
together that should really be considered separate agenda items. The
important parts seem to be:
1. PRA license is not compatible with open source distribution
2. PRA is technically unsound (and has had limited testing)
3. SenderID calls for PRA to use v=spf1 which may lead to breakage
The question I would like the council members to consider and discuss is,
if we accept that PRA has problems, needs testing, etc. would we still want
to throw our hat in the ring and let SPF be part of SenderID?
Could most of the objections be solved by not recycling the v=spf1 records
(unless the owner opts in somehow)? That seemed to be the part that people
objected to most strenuously.
Is the PRA license enough of a show-stopper to make us want to pull out of
Sender-ID? Could we accomplish our goals by making it clear to people that
we don't approve of PRA's license, and if they want to implement SenderID
without having to deal with MS restricted license, they should just install
SPF classic and they can still put the "SenderID" logo on their home page?
What if it's true that PRA is technically unsound? Do we have hard data to
back that up? Is there an advantage to the SPF community in telling the
world how flawed PRA is? Do we really want the first order of business of
the SPF council to involve making technical comments on someone else's
draft that isn't really SPF's core?
Anyway, separating the draft into its essential component parts takes extra
time, but I think it would be worth it. There is a difference between
"things we mostly believe" and "things we want to put forth publicly and
throw our weight behind". In each case we should consider carefully if 1.
we believe the assertion, and 2. if it gives the SPF community any
advantage to advertise it.
There is a fourth point which is not mentioned directly but which I think
the council should consider and discuss:
4. SenderID is a joint effort/partnership that includes both PRA and SPF
Whatever our opinions on PRA, would we still welcome the opportunity to be
considered as a partner to MS? Meng has worked hard to make sure that SPF
classic is considered as an equal partner. It would be a good idea for
each council member to spend some time listening to Meng's reasons for
working with MS. Now is the time to decide if we want to torpedo those
efforts, or announce our support for SenderID but not PRA, or just focus on
the problem areas and leave the "SPF part of SenderID" issue alone for now.
Thanks for your time
--wayne <wayne(_at_)schlitt(_dot_)net> wrote:
[Note: this is cross-posted to both SPF-council and SPF-discuss]
For the next SPF council meeting, I request that the SPF communities'
position on SenderID be put on the agenda.
One of my candidate pledges said:
I strongly support the "SPF Community Position on SenderID" as written
on http://www.openspf.org/OpenSPF_community_position_v102.html and
have signed it. Since this document was (obviously) written before
the elections, one of my first tasks would be to bring this to an
official vote.
This pledge has now been signed by over 100 people and more people are
signing it daily. At this time, I intend to vote for adopting this
position as it stands.
I do not think that this "position statement" is perfect, far from it.
It suffers from too many suggestions and not enough editing, a
consequence of being an extreme rush job. It is really too long for a
good position statement, and too short for a whitepaper explaining the
position. It contains one or two items that I'm not certain are
absolutely true (but I also don't know are false).
However, I don't think we will ever get something that 100% of the
community will agree on. I think the perfect is the enemy of the good
and that this position statement is good enough.
I encourage people who think they can do better to draft something
they think is better and see if they can get enough support for their
version to be a viable option.
I encourage people who think that the current position statement is
bad enough that it should not be adopted to explain to me why, as a
representative of the SPF community, I should either not vote for it,
or I should vote against it.
-wayne
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
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
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>