----- Original Message -----
From: "wayne" <wayne(_at_)schlitt(_dot_)net>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Monday, December 06, 2004 11:35 PM
Subject: Re: [spf-discuss] Agenda item: SenderID Position Statement
In <002701c4db76$fb76d770$a149573e(_at_)idimo2> "jpinkerton"
<johnp(_at_)idimo(_dot_)com>
writes:
From: "wayne" <wayne(_at_)schlitt(_dot_)net>
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.
I dunno. Certainly Sendmail's whitepaper didn't treat all
technologies equally, nor did they shy away from pointing out faults.
Same goes for Meng's whitepaper (although it certainly covers many
more proposals). I don't think that is the point of such statements.
Fair comment, but if we are going to be leaders in this field, let us be the
ones to set the standard of such documents. There is no reason to not write
something up regarding the other usages of SPF records and keep it
even-handed and friendly to all other anti-spam technologies
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.
Yes, SenderID and the PRA are inseparable. The question is: Is SPF
and SenderID inseparable? I don't think that is splitting hairs at
all.
Absolutely - maybe I mis-understood your comment. I agree that Sender-ID
and PRA are stuck together forever, but I believe SPF and Sender-ID no
longer have any connection.
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:
[...]
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.
I don't know how you thing I'm looking at this with any fear. MS
asked for SenderID content from us, and they got it.
Maybe not fear, but I mean - stop looking at what everyone else is doing.
Let's lead from the front, which is the position we are in at the moment.
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.
I tell ya what. How about this for a deal.
You go through and list everything that you think needs to be backed
up by facts, and get James' ok, and I'll write footnotes backing up
those claims. It just has to be clear that the footnotes were *not*
what people signed off on, they are just additional explanation.
I did think of doing that, but it wouldn't make me sign the document.
Maybe I'll spend a bit of time writing a draft of our general position,
which could include any usages of the records, and of spf checks in
association with other technologies (as in the IBM offering), and be
updated as things progress.
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".
I think you need to go back and read the archives. The relationship
between SenderID and SPF was certainly the trigger for creating the
council. I think that if SenderID wasn't being promoted as the heir
of SPF, with SPF being just an "essential part of SenderID", I very
much doubt there would be a council today.
It was certainly one of the main triggers because of the internal friction
that had arisen as a result. But it has become - in my mind anyway - a much
lower priority. Better the council moves forward on more positive stuff -
imho.
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:-
Well, the council has not yet discussed having an official SPF
website, nor have any of the many SPF websites given permission for
the SPF council to have any control over their content. Until that
happens, the council can not even consider deleting this document.
True, but I hereby give the council permission to put content on any of the
spf websites that I control. I have spare domain names and can easily
create a new website, if that's what's needed.
The council gets its justification for speaking for the SPF community
by virtue of getting a significant number of members of the community
to vote for it.
Also true
The SenderID position statement gets its justification for speaking
for the SPF community by virtue of getting a significant number of
members to sign it.
Possibly true, but I feel that there has been a certian undercurent of
"maybe I shouldn't have signed that" in some peoples postings since.
Right now, it appears that the SenderID position statement has at
least as much community support as the SPF council. By having the
council accept the position statement we are being more inclusive of
the entire SPF community.
About the same numbers - but somewhat different people :-/
Now, for those that think that a better document can or should be
written, please write one. I see absolutely no reason why this is the
only document written by members of this community that the council
should ever officially accept.
This is a community of volunteers that accomplishes something when
people do something. People got together and created the SenderID
position statement. That is a good thing. If you think other things
should be done, please do it.
That is very true - and I am extremely grateful to all the volunteers for
doing all the stuff, even if I don't always agree.
Slainte,
JohnP.
johnp(_at_)idimo(_dot_)com
ICQ 313355492