/me steps back a bit......
----- Original Message -----
From: "wayne" <wayne(_at_)schlitt(_dot_)net>
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.
You'll need to take that up with Meng then - won't you??????
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.
Of course he is!!! He works for MS, not SPF!!!!!
Is it any wonder there is confusion in the market?
No wonder at all - this is dog eat dog time and you'd better wise up to the
realities of the game you're in.
And you are saying we should just keep quiet?
No - I didn't suggest that - I've published my version of the reaction, but
I am *not* about to waste man-hours running around trying to correct all the
mistakes - deliberate or otherwise - which are floating around the ether
about Sender-ID (or any other technology) - What about CSV and HELO
checking - that was a non-event too, wasn't it?
Okay - I'm on a raw nerve and I acknowledge that this is a hot topic.
However - you cite "people". Who? I suggest that it is only people within
the e-mail technologies and standards worlds who are reading anything
confusing - not the general public (including Mr S.Y.S. Admin, of the world
of middle to small sized hosting solutions.)
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.
Well it's time the SPF council did something about that - starting with
fixing Meng's stance.
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.
Not really - you only think it does ;-)
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.
It's not - but it's the only option available. I have been saying from the
beginning that the SPF records are "out there" and will be used and abused
at will. There is *nothing* we can do about that except promote the correct
use, and some methods to prevent misuse - which is what I have done.
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?
Not true - there is *no* injunction to "do" something - the wording was
chosen to avoid that.
" We encourage all existing SPF (v=spf1) record publishers to note this
situation and take appropriate action, depending on whether they are
expecting their outgoing mail to be checked by receivers using Sender-ID or
not. "
That's not telling anyone what to do other than to be aware of the
situation.
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.
Quote the mail(s) that gives the full reasons of why and when PRA doesn't
work when checking spfv=1 ???? There's been a lot of rhetoric, but little
hard fact.
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.
See comment below
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.
There appears to be a little self-contradiction here. You suggest that I
don't have to comment on other technologies because they aren't associated
with SPF and don't use SPF records, but you want me to comment on the
"add-on's" that have to be used to fix the various issues faced by last-hop
authentication.
I am *only* commenting on SPF. Any reference to other protocols is a
courtesy and allows comment on the possibilities of infractions on SPF and
it's records. The rest of the technologies will have to do their own
publicity. ;-)
Slainte,
JohnP.
johnp(_at_)idimo(_dot_)com
ICQ 313355492