O Sender Policy Framework SPF

SPF is a simple way of tying information about the IP addresses that are allowed to send messages from a specific domain to a DNS text record. This is how your DNS server can tell the world that mail from your domain should come only from some specific addresses; other MTAs can then query your DNS record upon receiving messages and cross-reference that information with the headers of incoming messages apparently coming from your domain.

Let's see an example SPF record:

<Verbatim listing 18> $ dig -t txt gmail.com

; <<>\> DiG 9.3.2 <<>\> -t txt gmail.com ;; global options: printcmd ;; Got answer:

;; ->\>HEADER<<- opcode: QUERY, status: NOERROR, id: 21409

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4


;gmail.com. IN TXT


gmail.com. 300 IN TXT "v=spf1 ip4:

ip4: ip4: ip4: ?all" </Verbatim listing>

Querying the gmail.com domain, you can see that Google is indicating that only those IP classes are allowed (according to Google) to send messages from @gmail.com.

There are a few important points to consider when dealing with this technology. First of all, use it only for true positives (and whitelisting), meaning that if you find an SPF entry and the message matches positively, validating it and improving your scoring is safe.

However a missing SPF record or a negative lookup should never take on too much weight in your filtering decision because it's not a standard and hence fully adopted technology. SPF domains allow you to explicitly state with how much confidence the information you publish should be treated. The levels are PASS (always let the mail through), NEUTRAL (no policy is enforced), SOFTFAIL (open to interpretation), and FAIL (reject email).

SPF validates envelope headers only, and as seen, doesn't address spoofing the From header or anything in the body of the message, which usually tricks most people.

SPF is very easy to publish DNS-wise. Implementing it application-wise is a bit harder. There are two libraries (libspf and libspf2) and a dozen Perl applications, which allow easy integration in most MTAs, and SPF is explicitly supported by Spamassassin for score improving. As for filtering applications, a safe implementation involves adding a custom header containing the validation results.

Note that SPF breaks forwarding, since any forwarded message doesn't have its envelope sender rewritten with the forwarding server domain. This means that any forwarded message looks invalid to SPF-aware MTAs (if that domain is publishing a record). This is a serious problem that should be considered when implementing this technology. A proposed but rather unclean solution is the Sender Rewriting Scheme (SRS), which rewrites the Return-Path when forwarding.

Seeing a complete SPF implementation in the future that would require total adoption of SRS in any email forwarding mechanism is unlikely. This is another reason for trusting the mechanism only for true positives and whitelisting.

SPF is not a widely implemented technology but big providers (most notably AOL and Goggle's Gmail) are using it to increase the accuracy of anti-SPAM scores.

Was this article helpful?

0 0
The Ultimate Computer Repair Guide

The Ultimate Computer Repair Guide

Read how to maintain and repair any desktop and laptop computer. This Ebook has articles with photos and videos that show detailed step by step pc repair and maintenance procedures. There are many links to online videos that explain how you can build, maintain, speed up, clean, and repair your computer yourself. Put the money that you were going to pay the PC Tech in your own pocket.

Get My Free Ebook

Post a comment