----- Original Message -----
From: "wayne" <wayne(_at_)schlitt(_dot_)net>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Wednesday, December 15, 2004 6:32 PM
Subject: Re: [spf-discuss] Re: spf-statement-on-SenderID
In <066f01c4e124$768d71f0$874b573e(_at_)idimo2> "jpinkerton"
<johnp(_at_)idimo(_dot_)com>
writes:
Hear, hear ! I've been saying this for ages - stop dealing with a
problem
that is not ours - it's Sender-ID's problem.
When SenderID is being marketed as the successor to SPF and when the
problems with SenderID are used to discredit SPF, then it becomes our
problem.
I don't dispute your facts, but I disagree with the methods of dealing with
them.
I believe we have to take the lead and allow all other mail-authorisation
solutions to stand or fall on their own merits. Because SPF is successful,
there will always be detractors, who will always use whatever "facts" they
can conjure up to try to demote SPF. The fact remains that SPF is the only
mail authorisation protocol with any serious amount of deployment and
statistics. Lots of people deny that, but they can't alter the fact by their
denial.
I see us with two choices here. Either we progress with our heads up and
don't denigrade the "opposition" (in spite of what they and their supporters
might say about SPF) - or we run around trying to contradict and correct
all these mistaken and sometimes malicious statements about SPF.
From my perspective, I suggest wee should take a leaf out of the book of one
of the biggest corporations in the world, and just ignore the flak and get
on with the work. The world is not listening to the chair of the FTC, or
the proponents of other, un-tested technologies, they are looking for a
solution to a problem, and SPF is the best there is.
It is also a favourite tactic amongst the opposition, to cast doubt and
confusion amongst the proponents of the leaders in a field. Don't even let
them begin to think they are succeeding - ignore such statements and move
forward.
For example, at the FTC email authentication summit, in the beginning,
one of the FTC folks (the commissioner?) said that he thought SenderID
had pretty much taken over SPF and so SPF didn't need to be
considered. (My memory is somewhat foggy, and no transcripts have
been published yet, so I can't give an exact quote. It was something
pretty close to this idea though.)
As another example from the FTC summit, see this:
Page 4: "SPF vs Cryptographic Encryption"
Drawbacks to SPF: Weaknesses in the Purported Sender Algorthims
This is exactly what I'm talking about with confusion in the market
between SenderID and SPF and how, in front of the FTC, SPF got
tarnished with SenderID problems.
http://www.ftc.gov/bcp/workshops/e-authentication/presentations/11-9-04_brow
n_ColdSpark.pdf
The confusion only exists because SPF is not progressing fast enough, which,
in turn, is because there is a tendency to try to correct all these mistaken
statements, instead of getting the next million records published and
becoming the de-facto standard it deserves to be.
Every time you stop to correct someone who is not actually trying to
implement SPF records or milters, the "opposition" is "winning".
In your world people might listen to the FTC, etc. but in the real world few
people have heard of it and even fewer care what it says. They only want a
solution to spoofing.
See http://spf.idimo.com/other_protocols.html
I very much dislike your opt-out solution to the problems that the PRA
causes as expressed on that web page. Instead of warning domain
owners that they need to opt out of SenderID, you should be warning
users of SenderID about the limits the PRA and how there are known
cases where SPF will work but SenderID won't.
I'm sorry you don't like it, but it's a statement of fact - that is the only
way to stop PRA checks on spfv=1. I am not about to tell domain owners what
they should or should not do - there are millions of loyal MS users out
there and they might want to use Sender-ID. I am *certainly* not about to
start describing what the flaws in PRA are -
a. because I have never seen a detailed study of what goes wrong and when
and why.
and
b. because that would mean I would also have to publish why DK, CSV, SRS,
SES, et al are not working well in all situations.
The website is about SPF. The "other protocols" page is there for
information only on how SPF interacts with these other protocols, *not*
about how those other protocols work (or not).
Once again - I would ask that all the time spent chasing mistaken statements
by people who are not actually trying to use SPF in the real world is now
put to better use in solving mail-list, forwarding and greeting cards
issues.
Slainte,
JohnP.
johnp(_at_)idimo(_dot_)com
ICQ 313355492