There's been a lot of buzz lately about different techniques used in the fight against spam.  Techniques range from the most basic key word filtering through Bayesian AI on the client side to mail server and appliance side techniques including blacklists and many others.  On the infrastructure side (read DNS, protocols, etc…) there are techniques such as Penny Black, being pushed by Microsoft and SPF, currently in pilot at AOL, that have received loads of attention as well.  Of course there's also the legislative aspect (read CAN-SPAM). 

As you can see, these techniques are a dime a dozen.  Most only serve to hold back the tide while valuable resources such as bandwidth, CPU and disk space continue to get sucked up by bogus e-mail.  ZDNet.UK has done an EXCELLENT two part write up on SPF which I highly encourage you to read.  It covers both the logistics of setting up SPF, what it does and what it doesn't do.

So, what makes SPF different?  First, lets have a little primer so that the rest will become self evident. 

What is SPF?
Sender Policy Framework.  Currently in draft submission to the IETF.

Seriously, what is SPF?
Ok..seriously.  SPF is the application of a few well known, well documented technologies such s DNS (Domain Name Service), MTA (Mail Transfer Agents), MUA (Mail User Agents) and SMTP (Simple Mail Transfer Protocol), applied to a serious problem, SPAM.  While it doesn't address the root causes of spam, SPF makes significant inroads into protecting you from forged addresses.  It's main purpose in existing is really to prevent spammers from spoofing a from address, making you think that an e-mail came from a "trusted" source when it really came from some Viagra hawker.  If you want technical details go here, I won't bore you to tears.

Here's a quick example that took advantage of this vulnerability as well as some social engineering.  Remember a few months ago, when Chase account holders began receiving e-mails which looked like they came directly from Chase online banking division, yet requested account and PIN numbers.  There was also a case of Citibank customers being exploited in a similar way.  These were fraudulent e-mails that exploited a loophole in the SMTP protocol which allows your ISP's mail servers (where you receive your e-mail) to accept messages without checking to make sure that they did in fact originate from where they claim to have originated.

The reason that I say that this isn't the holy grail is because SPF will not prevent legitimate e-mails, from legitimate senders, from getting to you.  What it will do is prevent spammers from making up e-mail addresses that don't really exist and making them look like they came from a "trusted" sender.  This is a major source of spam and so anything that can be done to prevent it, should be done.

What do I need to do?
Nothing.  Pretty cool isn't it?.

Ok…Seriously…What can I do?
Send your ISP an e-mail and tell them that you think that this is a great freakin idea and that you pay then a hell of a lot of money and that it will make your life that much easier to tolerate.  Therefore, you won't bother them as much.

So how is it going to work? (Geek Alert!)
Well, your ISP has to get on board and make some changes to how their mail servers handle incoming mail as well as how their mail server DNS records are setup so that when you send an e-mail to someone who is SPF enabled, you won't get rejected.

Who is on board with SPF?
About 8000 SPF records are registered in DNS at this time.  AOL is among them and running a trial, for which they've had positive results.

As of March 2004, over 8,000 domains had published an SPF record. Included in there is AOL, a popular domain to fake among spammers. For SPF to be truly successful, it needs to be the rule rather than the exception, so widespread adoption is key. The advantages of SPF over other similar schemes include its minimal implementation cost.