lotus



previous page: Anti-SPAM Techniques: White Listing
  
page up: Anti-SPAM, Anti-Phishing and Anti-Viruses Techniques
  
next page: Anti-SPAM Techniques: Reputation Control

Anti-SPAM Techniques: Sender Policy Framework (SPF)




Description

This article is a part of the series on undesired email (spam, phishing, viruses, etc.). The material covers the Poisons and the Remedies.

By Stas Bekman.

Published: May 15th 2006

Anti-SPAM Techniques: Sender Policy Framework (SPF)

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 From 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.

Vendors

Here are some vendors supporting this technique (including open-source solutions):

Libraries, patches and extensions (http://new.openspf.org/Implementations)
for those who want to use SPF. It also provides a list of vendors supporting SPF.

libsrs2 (http://www.libsrs2.org/)
(OSS) is the next generation SRS library. It implements the Sender Rewriting Scheme, a part of the SPF/SRS protocol pair.

MailChannels's TrafficControl

Supports SPF (Commercial).

 

 

 

Please notify me if you know of others.

Related Links

And here are some pointers for additional information on the subject:

 

Historical SRS draft (http://www.xyzzy.claranet.de/home/test/draft-mengwong-sender-rewrite-01.txt)
By Meng Weng Wong (2003)

openspf.org (http://www.openspf.org/)
The SPF website includes documentation, code and support information.

Sender Rewriting Scheme
Is designed to make it possible for e-mail forwarders to be compatible with Sender Policy Framework.

The Trusted Forwarder SPF Global Whitelist (http://trusted-forwarder.org/)

SPF, MTAs and SRS (http://www.linuxjournal.com/article/7328)
An article by Meng Weng Wong.


 

 

Continue reading about other Remedies or jump to the email-related Poisons section.















TOP
previous page: Anti-SPAM Techniques: White Listing
  
page up: Anti-SPAM, Anti-Phishing and Anti-Viruses Techniques
  
next page: Anti-SPAM Techniques: Reputation Control