spf-discuss
[Top] [All Lists]

Re: Agenda item: SenderID Position Statement

2004-12-07 08:01:21

On Sun, 5 Dec 2004, Greg Connor wrote:

I appreciate your taking the time to discuss and gather input.

The same and also I would like to note that many of us are happy to have
on our side people like you and Meng who are very diplomatic in your 
positions and statements, such skills are important and often results in 
greater cooperation among larger audience. But unfortunetly diplomacy 
does not always work is not necessarily the right step when dealing with 
Micorsoft and when we want to produce reliable technology.

In this regard I'd also like to remind that we did try to work with Microsoft
before under supervision of IETF (i.e. MARID WG). Microsoft did not address
any of the technical issues with SenderID that had been brought up nor
did it change the license eventhough we gave them several opportunities
(they missed several deadlines and we were willing to let it all go), in 
the end IETF decided that because of Microsoft CallerID algorithm (with 
its corresponding technical problems) and Microsoft unwillingness to 
compromise on the license, that it would not be possible for MARID
to get its job done and produce standard that would have support of
the internet community.

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 do not believe this statement is overly long, it does somewhat mixes
political and technical reasons why SPF Community does not like Sender ID
in its current form, but it would not be appropriate to change it now
that it has so many people who have signed under it, nor would better
separation of political and technical reasons really change the issues
expressed by that document.

I would also remind that SPF Council (as it was called for based on
the results of my poll) should not really be making up policy on its own, 
rather it should be acting is similar way to chairs in IETF WG and
ratifying positions that have consensus of the community and in this
case the consensus seems to exist as shown by large number of people
in SPF Community that supported this statement.

I would much rather see two or three very short resolutions adopted, 
I do not believe it would be enough in this case.

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)
 
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"? 

"Many developers" were the words used because we did not have official SPF 
Community at the time and statement was thus made as coming from "SPF 
developers and users" (most of thee SPF library developers did sign this
statement).

How do we objectively measure confusion in the market? 
How do we measure the tarnish upon SPF's good name? 

I think you got the answer earlier today. People are now coming to SPF list
and beginning to blame us for the problems they see that are associated 
with SenderID. And this is just a start and still at the time when 
SenderID is not used at all (even by Microsoft.

Does Microsoft have a proven track record of marketing products that 
fail spectacularly?
It absolutly does!!!!

Microsoft undeniably should get A+ for its marketing, but it would get
somewhere like C- for its technology - many many times they released
something that does not work and has serious security reasons (in fact
if not for them spam zombies would not be such as serious issue), several
times they have come to standards organization and wanted to change 
something and that change caused what was previously good technology
to have technical issues - this has happened both with IETF and with W3.

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.

It is difficult to make such predictions either way, which is exactly what
you said. As such we have to rely on other points regarding relationship
of SPF and SenderID and those are not favorable to SenderID.

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.

We have spent time with Meng and asked him and we never got the answer.
It appears to me both Meng and you (and I've always seem to have exactly 
same view as Meng does eventhough almost everyone else on this list have 
shown a different positions on one issue or the other) are way too
diplomatic to ever say "NO" to Microsoft and are willing to do anything
to be part of their team.

And while I do recognize value of teamwork, in this case I do not believe
that choice of partner would be equally beneficial to both sides. In that 
regard I would like to remind people of the strategy Microsoft usually 
takes when it begins to work as part of "the team" on some standard:
 http://en.wikipedia.org/wiki/Embrace%2C_extend_and_extinguish

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.

SenderID is already mentioned in press and everywhere else as being 
"Microsoft SenderID", I believe Microsoft will continue to market it
as such (they do not even provide link to SPF!) and in that regard it
is unclear how continuing to be "partner" with them is beneficial to
SPF Community especially when we see SenderID as being a problem rather
then solution.

It's also possible to post our problems with PRA without taking any 
position at all on SenderID.  Something to think about anyway.

We've had been on that road before for last 6 months in MARID and other
places and this has not resulted in any change to SenderID and in fact
the result is worth then when we started as now they want to reuse SPF v1
records without getting prior consent of the SPF record publishers for
using it in different way then what was originally intended. 

Clearly we need to take a stand and explain what SPF v1 records are 
supposed to be used for and why using it in Microsof way is not the 
a good idea. 

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.  :)

I'm not surprised to hear that you (like Meng) would have signed it :)
 
Understood.  Consider the option of taking aim at PRA and not SenderID 
perhaps?

This directly relates to if we consider PRA = SenderID. If this is so, 
then it does not really matter and SenderID is better known name and
it would be clear to others what we're talking about. Other then that
that statement already mentions PRA number of times.
 
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.

I completely agree. Please go through archive and you'll clearly see that 
friction within this group started because of continuing promotion of 
SenderID and PRA by Meng and his disregard for the view expressed here
in regards to PRA algorithm and in regards to SPF becoming part of SenderID.
This has resulted in the situation that group leader was no longer seen
as been able to properly represent view of SPF Community and decide on
the issues important to us and as a result a more balanced leadership 
group was selected.

-- 
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net