By Stas Bekman.
Published: May 15th 2006
Sender Policy Framework tries to prevent the sender address
forgery, after all we have all received spam that was somehow sent
from our own address - the reason spammers use this approach is
that usually local addresses and addresses of our friends are whitelisted (i.e. unconditionally
accepted) by the receiving party, so if spammers figure out who
our friends are they forge the envelope's
address to use that information. And voilą they get their SPAM
mail through under radars.
The solution proposed by SPF is to have each valid email sender register the IPs of the machines they send email from (usually there is just a handful of those), using extended DNS records. So if someone is claiming to send an email from a given domain and a lookup of those records doesn't match the IP address of the sender, you know that the email is forged.
The main problem is that there aren't many SPF records out there, so most of your lookups will come up with no information you could use to check the incoming message. And there is a lot of invalid/misconfigured SPF records out there.
But even if everybody were to publish SPF records, and the forgery issue is resolved, it doesn't help prevent spam coming from non-forged envelopes. In fact many spammers started publishing SPF records for their spamming machines, so if you ever thought to use SPF to filter SPAM, you will have to rethink your strategy since it doesn't work.
Since SPF helps avoiding forgery it should be used in conjunction with other techniques which provide other ways to detect and reject spam.
Here are some vendors supporting this technique (including open-source solutions):
and extensions (http://new.openspf.org/Implementations)
Please notify me if you know of others.
And here are some pointers for additional information on the subject:
Forwarder SPF Global Whitelist (http://trusted-forwarder.org/)
SPF, MTAs and