----- Original Message -----
From: "wayne" <wayne(_at_)schlitt(_dot_)net>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Monday, December 06, 2004 2:39 AM
Subject: Re: [spf-discuss] Agenda item: SenderID Position Statement
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. [...]
I honestly don't think that is the answer to Meng's question. We don't
define "many" , "unsound" and "undemines". But then, I don't think we need
to define these terms, because Mengs question (which is exactly the same
question as I implicitly posed in my response) is probably answered best in
this way :-
Strategies have to consider the current position,*and* the real-world
situation in the foreseeable future. We are going to be working with all
anti-spam efforts, and the spf records are going to be used by all kinds of
people who will be experimenting and testing their own "flavour" of
authentication. Sender-ID is only one of many, and they all have their
problems to a greater or lesser extent, so there is no reason for us to
single out Sender-ID as one we have to have a "published" position on. CSV,
BATV, SRS, etc don't do that, why should we? It's an admission of
inferiority imho, and puts us on our back foot. We need to move forward
positively, with *all* other authentication/anti-spam technologies.
Look at it this way - if we published a position on CSV, the "public" would
automatically think that we are somehow associated with CSV. In other
words, as soon as you publish something, it will be mis-interpreted. Better
to put a nice and positive statement about how good spf is, and how we will
work with anyone interested in anti-spam measures.
So the strategic impact of a statement on Sender-ID is negative, imho, it
associates us more closely with one other technology than the others, and
that is bad, because we don't yet know which one is going to be successful
in the marketplace.
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.
As I said - we must associate with all other technologies equally, and it's
*really* important to *not* point out their faults. Having said that - I
like MarkK's idea of a document with all the technical info on "gotchas" in
using spf records, which would have to be written *very* even-handedly.
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.
Sender-ID and PRA are inseperable. It would be folly to try to split hairs
like this. This is a public statement and will be read out of context, so
it has to be strategically correct for SPF on it's own merits and without
further reading, because that is what will happen.
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.
Stop looking fearfully at the "opposition". Just accept the fact that MS
will do what they want and get on with SPF.
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.
But that's not what the public at large will read - there are no facts in
the document to back up these claims, so they will be seen as 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.
I sincerely hope not. I would be extremely disappointed if this issue was a
main reason for the council's existance. Hopefully the council will be able
to tackle much larger issues than this "non-event".
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.
In both cases described, I believe the council should delete this document
from existence because:-
It bad-mouths another technology without reference to facts.
It compares spf with only one of many other technologies.
It does not promote spf in a positive way.
It leads the public to think that there is a special association between spf
and Sender-ID.
I believe that the council should create an environment for the writing of a
simple document giving all known usages of spf records, with a simple,
factual statement of what happens when such usages are made. The wording
must *always* be positive, and it can become a standard page on spf
websites.
Let's remember something - spf works, we have a couple of problems to solve
and we're done here :-)
Slainte,
JohnP.
johnp(_at_)idimo(_dot_)com
ICQ 313355492