In <x47jnw64k0(_dot_)fsf(_at_)footbone(_dot_)midwestcs(_dot_)com> wayne
<wayne(_at_)schlitt(_dot_)net> writes:
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.
Quite a few people have taken the time to respond to this subject,
which I appreciate. Before I address some of the issues raised, I
would like to make two points:
First, the reason why I post this to both SPF-council and SPF-discuss
instead of just sending it off as an agenda item to Chuck Mead (the
chair of the SPF council) is because I knew people would have strong
opinions that they would want to discuss.
Secondly, the reason why I intend to bring this to a vote is because I
said I would bring it to a vote. If it gets voted down, fine, we move
on, if it gets approved, fine, we move on.
I encourage people to (re-)read the "SPF Community Position" that is
being discussed. See:
http://www.openspf.org/OpenSPF_community_position_v102.html
Meng asked: "what's the strategic objective of having a position on
sender id at this point?"
That is a good question to ask. I think it is, in part, answered in
the position statement when it says:
Many SPF developers and users consider that Microsoft's SenderID
proposal is technically unsound and undermines the progress already
begun by SPF. [...]
In particular, there is confusion in the market about the relationship
between SPF and SenderID. This reduces the value of the SPF brand
name as an independant anti-forgery system. Problems associated with
SenderID have and will continue to tarnish the SPF name as long as we
allow this market confusion to continue. When (if?) SenderID fails in
the market, it is likely to cause further damage to SPF.
This reason is closely related to a question William brought up in
this discussion:
: [...] [The] SPF Community needs
: to take clear stand if it wants to have SPF considered "essential part
: of SenderID" or if we prefer to have SPF considered separate email
: security system [...] and then we should make it clear that
: in our view SenderID refers only to Microsoft PRA algorithm.
I have been assuming that SenderID refers only to the Microsoft PRA
algorithm.
There have been several comments about "Why should we publish a
position on SenderID and not SES/DK/CSV/whatever?"
I think the primary reason why we have published a position on
SenderID is because we were asked to.
Remember, the reason why this web page was created, and why it was
created in such a rush, was because Craig Spiezler of Microsoft gave
Meng an ultimatum that the SPF website had to have SenderID content or
the links from the truste.org website to SPF would be removed. See:
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200411/0135.html
Meng created SenderID content, and yet all links to SPF have been
removed from the truste.org website anyway. See:
http://www.truste.org/authentication
http://truste.org/about/sender_id_industry_letter.php#signator
Note that *every* one else gets links, but not SPF and that is because
of Microsoft's demands.
There have been a couple of comments that imply this SenderID position
statement is a result of the dislike of Microsoft.
I disagree. This has to do with the technical and licensing problems
of the PRA. The very first sentence of this position statement says:
The developers and users of the Sender Policy Framework ("SPF")
welcome proposals that will truly help clean up the current
problems with email forgery.
With only one or two minor exceptions, I can show the facts that back
up every statement in this docuement. The other contributers can
likely show the facts backing up those. I believe this position
statement has very few opinions.
As I've said, I see this vote as a way of putting this issue to rest,
and that was one of the primary reasons for creating the council.
Is SPF just an "essential part of SenderID"? If so, the council
should vote down this SPF position statement and rebuke the claim that
it is the "SPF community Postion on SenderID". If SPF is not a part
of SenderID, then I think the council should make this clear, and part
of making that clear would be to confirm this position statement.
-wayne