--wayne <wayne(_at_)schlitt(_dot_)net> wrote:
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 appreciate your taking the time to discuss and gather input.
My preference would be to ask the council to vote down the position
statement as written, and work on a much shorter, concise statement. I
would much rather see two or three very short resolutions adopted, than to
have an "everything but the kitchen sink" version. (Check out John P's
version for an alternative, or at least a starting point)
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 is one of the aspects of the position statement that I found
troubling. How many developers is "many"? How do we objectively measure
confusion in the market? How do we measure the tarnish upon SPF's good
name? Does Microsoft have a proven track record of marketing products that
fail spectacularly?
The lack of real marketing research here is what concerns me. It's
entirely possible that SenderID will fail and that SPF will be viewed
unfavorably because of it, but it's also entirely possible that SenderID
will get lots of beneficial press and end up as a net gain for SPF even if
PRA fails to be adopted.
I suggest spending some time with Meng and asking him what he thinks of the
statement "there is confusion in the market about the relationship between
SPF and SenderID". After he gets done smiling and making steeples with his
fingers, he may say something enlightening. Who knows.
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.
This is an important question, and important distinction that deserves
careful thought. We could decide as a community to take a strong position
with regard to PRA (license and/or technical/pragmatic issues) and yet
still choose to remain "partners" with MS. Being a "partner" doesn't mean
we endorse everything they are doing.
It's also possible to post our problems with PRA without taking any
position at all on SenderID. Something to think about anyway.
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.
Understood. However, I encourage the council to also consider the
possibility of not publishing a position at this time.
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.
I notice that Sender Policy Framework is listed on the page (just not
linked) and that Meng Wong is listed as a signer.
Actually that "sender id industry letter" letter is pretty cool, and I
would probably sign it as well, if asked to. :)
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.
Understood. Consider the option of taking aim at PRA and not SenderID
perhaps?
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.
A "careful selection of facts" can show a bias. I am not quite so
interested in "facts" as I am in the conclusions (stated or implied). I
want to see a series of We Think, We Feel, and We Believe statements. In a
lot of ways that's going to be harder than picking facts but IMO it's
necessary to effective leadership.
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.
You definitely have your work cut out for you. Best of luck!
gregc
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>