spf-discuss
[Top] [All Lists]

Re: SPF implementations

2005-08-16 17:40:22
Dennis Willson wrote:
 
Actually it DID have a PASS. The <return-path> had a domain
with a valid SPF record in it which PASSED.

That's a nice example.  An SPF PASS can in fact be a spammer
(or in your case a phisher).  Let's say I'm that phisher, I
send you a MAIL FROM nobody(_at_)xyzzy, use whatever From I like
(for this example From: admin(_at_)paypal), and what you get is an
SPF PASS with From: admin(_at_)paypal(_dot_)  At first glance.

What you really got is a PASS for nobody(_at_)xyzzy, and if you
don't trust or know this guy it could be still a phisher.

My original example started with "if you get a SPF PASS for
a MAIL FROM paypal" etc., so far that was different, and in
fact you do trust paypal (unlike that obscure xyzzy guy ;-)

Then my example continued with "if you get something else
for Paypal check it", so far it's still correct.  But your
real problem was that you got an SPF PASS from an unknown
stranger, and that was a phisher:

Yes, SPF isn't designed as anti-phishing tool.  A PASS from
unknown strangers like nobody(_at_)xyzzy is (almost) worthless.
It's useful if it's from somebody you know.  You have to
combine it with "white lists" for known senders like Paypal.

If you can't do that SPF PASS is more or less a waste of
time from your POV.  SPF FAIL might be still a good thing:

If you get an SPF FAIL for nobody(_at_)xyzzy (or admin(_at_)paypal)
whether you know / trust them is beside the point, either
it is forged, reject it (my second example) and block the
sending IP, or it's a side-effect of your own forwarding -
in other words you screwed up and tested SPF behind your
borders, that won't work, white list the forwarder.

After you've fixed the latter problem each and every SPF
FAIL is forged - or the sender screwed up, but that's not
your problem, stupid senders deserve what they get for a
FAIL, SPF is a dangerous tool, it must be dangerous, it's
playing hardball with spammers.

Also PayPal has a softfail not a fail.

Okay, it also offers to play softball.  Except from tests
SOFTFAIL isn't very helpful, maybe you could use it somehow
in a scoring system, give it the same score as "viagra" in
the subject.

I block on fail

That's good.  Watch the sending IPs also for other mails,
in many (?) cases a "once a liar => always a liar" strategy
might help.  If a spammer is stupid enough to forge SPF FAIL
protected addresses, he might be also stupid enough to use
the same zombie IP for protected and unprotected addresses.

Pass used to mean not spoofed to me

That's bad, I thought we have that clear in the spec.  In
the "op" draft I have this statement:

5.  Security Considerations

   Please consult the security considerations in [I-D.gellens-submit-
   bis] and [I-D.schlitt-spf-classic].  A sender policy is only a claim
   by the domain owner, this can be a spammer or an attacker.
[...]

Pass doesn't mean anything

That's not the case, a PASS from unknown strangers doesn't mean
anything.  It's like "trust me".  AOL uses it for an "assume
innocent until proven guilty" approach,

fail only means the person trying to spoof wasn't smart

Yes.  Now while fighting spam that really helps, some of them
are not too bright, you can catch them with an SPF FAIL before
other traditional methods like blacklists or SURBL also do it.

It also means that someone can send an email spoofing my
domainby putting their own domain in the <return-path> and my
domain as the from, and users will think it came from me

Note that they cannot put your domain in their <return-path>
- or rather, of course they can, but it would FAIL if that's
your sender policy and the receiver checks it.

A really smart spammer (certainly not "my" spammer, sigh)
won't do that.  From there you can fix all the other holes:

Add meaning to PASS by combining it with a "white list".  If
a user has done this, each and every PASS for your domain is
a "known PASS", and that's a good thing.

I'm not saying that anyone elses solution is better, just
that SPF doesn't seem to work well

As an anti-phishing tool it's very weak, to put it mildly.
But still strong enough to build on it if you combine it
with a "white list".  A somewhat dubious way, but it could
work:  Combine SPF PASS from unknown strangers with a C/R
system (challenge/response) like TDMA (sp?)

One thing is sure, it was a PASS, the challenge won't hit an
innocent bystander.  Maybe it goes to the bit bucket of the
sender, maybe the sender was a spammer, but it really _was_
the sender, it wasn't forged.

In other words, I can't forge your domain, and vice versa,
that is better than before = without SPF.  [[ I really hope
that "my" spammer gets it asap, it's no rocket science ;-) ]]

                          Bye, Frank