Re: Re: SPF implementations

Frank Ellermann wrote:
> Dennis Willson wrote:
>  
>
> > Well I must say that if all someone has to do is make the
> > <return-path> and the From addresses different to spoof my
> > (or an incoming) domain, then I don't see any usefulness in
> > SPF. What's the point if it's that easy to get around?
>
> See also the other replies.  Two points I can think of:
>
> - your original example was a PayPal phish.  PayPal has an
>   SPF sender policy, you'd get a PASS for legit PayPal mail.
>
>   So if you get anything else claiming to be somehow related
>   to PayPal, but it has no PASS, you'd check it carefully.
>   In all normal cases you either know why it has no PASS or
>   it's spoofed.
Actually it DID have a PASS. The <return-path> had a domain with a valid SPF record in it which PASSED. The From address was 
PayPal.com so the user sees the PayPal.com in their email clients from address but they don't see the <return-path> in their mail 
client.
Also PayPal has a softfail not a fail. I block on fail and look closely at anything else AND I mark SPF softfails. Pass used to mean 
not spoofed to me but as I have discovered, Pass doesn't mean anything and fail only means the person trying to spoof wasn't smart 
enough (yet) to put a valid (or neutral) SPF domain that includes the sending address as the <return-path> and then they are free to 
put anything in the from address so the person receiving the email will see any domain in the from address and it will have an SPF 
pass. However most end users don't know about SPF pass vs fail, they only know they got an email that says it's from PayPal.com (or 
whom ever).
It also means that someone can send an email spoofing my domain by putting their own domain in the <return-path> and my domain as 
the from, and users will think it came from me and it will go right through SPF even though I have a hard fail at the end of my SPF 
record.
Also I'm not saying that anyone elses solution is better, just that SPF doesn't seem to work well (and as the people wanting to 
spoof email learn about this, it won't work at all) with this hole, maybe nothing does at this point either. Just that going through 
all the steps to get something adapted that allows senders to go around it so simply doesn't seem worth it.
I didn't actually look too close at the other proposed solutions because SPF seemed so simple and didn't really need to change email 
protocol to work. The records are easy to put in DNS and there are a number of premade solutions on the mail server side. However 
I'm not seeing a solution for this issue which looks like it will totally render SPF useless (unless there's something I'm missing).
> - if your MX gets a mail claiming to be MAIL FROM me then
>   it's most probably my spammer (=> SPF FAIL), otherwise
>   if it's really me you'd get a SPF PASS (see above)
>
>   You can then not only reject the FAIL, you can be almost
>   sure that the sending IP is a zombie controlled by a
>   spammer.  Therefore you'd block it temporarily until you
>   are sure (= dubious IP shown by your ordinary blacklists)
>
>                          Bye, Frank
>
>
> -------
> Sender Policy Framework: http://spf.pobox.com/
> Archives at http://archives.listbox.com/spf-discuss/current/
> To unsubscribe, change your address, or temporarily deactivate your subscription, 
> please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com