Re: Re: SPF implementations

Dennis Willson wrote:
Fixed top-posting.
> Frank Ellermann wrote:
>
> > Dennis Willson wrote:
> >
> >
> > > Isn't using SPF on the "From" address an acceptable use of
> > > SPF?
> >
> >
> > It's NOT RECOMMENDED in the spec., because it won't work in
> > many cases.  E.g. this reply should have From: nobody(_at_)xyzzy,
> > and you'd get a FAIL if you test it, because my sender policy
> > doesn't cover the IPs of this mailing list.
> >
> > If you take the Return-Path (v2.listbox) you'd get a PASS.
> >
> > Sender-ID would pick the Sender instead of the From, that
> > happens to be the same as the Return-Path for this mailing
> > list, and therefore it should also work.
> >
> > The serious trouble starts if From, Sender, and Return-Path
> > are all different.  Or if From and Return-Path are different,
> > and there is no Sender.  If you then pick whatever you like
> > and test it against v=spf1 you'd get wrong results.  Often
> > it will _apparently_ work - you'd catch that PayPal phish -
> > but not generally, you'd delete legit mails together with
> > the phishing crap => NOT RECOMMENDED.
> >
> >                          Bye, Frank
> 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? I get a lot of email where the <return-path> and the 
> from addresses are different, not Spam, real email my users and I want. 
> If I flagged when the <return-path> and from addresses are different a 
> good percentage would be marked and users quickly ignore (and complain 
> about) that flag (I tried it already).
> While I can justify and live with the forwarding issue everyone is 
> always arguing about, this issue looks like a show stopper to me.
> Can someone explain why this isn't a big hole? Why I shouldn't just stop 
> using SPF because it obviously (to me) does not have the ability to do 
> as advertised (stop domain spoofing)?
SPF is a step.  It is not a panacea.  The advantage of SPF looking at 
Mail From in the envelope is that forgery can be detected before the 
message is sent.  This is a huge potential for resource savings, 
bandwidth, CPU, and memory.
SPF does what it does.  Trying to make it do something else is risky and 
NOT RECOMMENDED.  That doesn't mean that SPF has no value.
It can stop domain spoofing in the envelope.  If you want to use SPF in 
the body of the message, go see Microsoft and SenderID.  I expect you'll 
end up throwing up your hands because of the complexity and the error rate.
You might also investigate Domain Keys Identified Mail (DKIM), but they 
are just getting designed.
There is no one solution.

Here's a thought, you might keep a list of commonly forged domains (e.g. 
paypal.com, ebay.com, aol.com, etc.) and look for that domain in the 
body.  If you find it, check the Return Path/Mail From.  If they didn't 
Pass an SPF check from the parent domain, then flag it.
That might give you few enough flags that your users wouldn't complain.

You might also do the opposite.  Look for SPF Pass from Ebay, Paypal, 
AOL, etc. and flag those messages good.
Forgery isn't solved by any means.

Scott K