In <009b01c4e2d5$7b1d3680$1a48573e(_at_)idimo2> "jpinkerton"
<johnp(_at_)idimo(_dot_)com> writes:
From: "wayne" <wayne(_at_)schlitt(_dot_)net>
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.
People are not going around citing flaws that have to do with DK or
IIM and saying it has to do with SPF. People *are* saying that
problems with SenderID are also SPF problems. This is because there
are people *promoting* SenderID as the the successor to SPF.
This has nothing to do with SPF being successful. This has to do with
deliberate actions by people to obscure the two.
For example, last week Meng gave a presentation to most of the largest
ISPs in Singapore and used the following presentation:
http://spf.pobox.com/slides/20041210-sg/presentation.pdf
On slides 48-50, SenderID is presented as a merger and heir of SPF and
CallerID.
Look at:
http://www.ftc.gov/bcp/workshops/e-authentication/presentations/11-9-04_katz_Microsoft.pdf
On page 4, SenderID is presented as a merger and heir of SPF and
CallerID.
If you listened to Harry's talk at the FTC summit, you would have
heard him describe how this is basically his stock presentation and
that he regularly tours the world, using it to promote SenderID.
Is it any wonder there is confusion in the market?
And you are saying we should just keep quiet?
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,
No. Confusion only exists because people are actively promoting that
confusion and the SPF community has done almost nothing to stop it.
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.
Yes, I know, the FTC is part of the US government, but even in Europe
where you live, what the FTC says carries weight among many important
organizations.
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.
What makes you think that publishing the opt-out record is going to
stop people from using the the v=spf1 record? It doesn't stop
Sendmail's SenderID milter, the SenderID implementation that is
available to the public.
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.
Wait. You *are* telling domain owners what to do. You are telling
them they have to opt-out. Why shouldn't you tell the "loyal MS
users" that, because the SenderID spec requires you to opt-out, that
the spec knowingly creates problems for them?
a. because I have never seen a detailed study of what goes wrong and when
and why.
Well, then you haven't been reading this mailing list very closely
then.
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.
No, you will not have to do that because those other systems do not
tell people to re-use data wasn't intended for those proposals and
doing so creates known problems.
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.
What "mailing list" problems? Do you even understand the problems
that SPF faces?
The verbatim forwarding and greeting card issues have had known
solutions since the oldest SPF spec that I have found (June 2003).
Better solutions have been proposed since then, including using an
exists:%{l}._spf.%{d} mechanism to help SES/SRS forwarding, using
receiver whitelists, rate-limiting exceptions, etc.
-wayne