Sender Policy Framework – Option to Battle SpamBy Blane Warrene
The Sender Policy Framework (spf) was developed by Meng Weng Wong as a fork of Hadmut Danisch’s RMX and Gordon Fecyk’s DMP – both former efforts to battle email spam based for the most part on domain forging.
Wong is the founder and CTO of pobox.com and in 2004 pobox.com and Microsoft jointly submitted a draft for RFC status to the Internet Engineering Task Force (IETF) for spf and Sender ID (developed by Microsoft). There was controversy around Microsoft’s Sender ID as they filed for patents on part of the process – which would potentially hinder it from becoming a global open standard. The IETF abandoned consideration of the joint proposal for RFC status in late 2004. Microsoft has since re-submitted a new draft of Sender ID to the IETF.
SPF for the time being is back on its own – and it is believed to be in use by more than one million domains.
It seeks to battle spam by rejecting emails where the domain (namely a domain(s) under your management) is forged. It is done through DNS by specifying in DNS zones the only authorized hosts that can send mail from your domain and reconciling them to a public IP address.
Thus, someone forges the domain name and it is rejected as it does not match any existing approved domains in DNS. Similar to pure spam tools, there is whitelisting for exceptions and some control over whether the mail discovered to be forged is bounced, tagged or allowed through. This latter option helps with implementation testing prior to any serious use in production.
There is some debate in regard to using spf if SMTP authentication (SASL) should be mandatory. I have setup systems that use POP before SMTP as well as SASL – and could not imagine not using any sort of outgoing restrictions – however – not every environment is ready for SMTP authentication. That part is up to the system administrator and users.
A very basic spf DNS record would look like this :
“v=spf1 a ~all”
This is spf at its elementary level for basic setups. This addition to your dns record states the domain myplace.com is the A record and also sends mail out from myplace.com. In this case the DNS zone did not have an MX record.
It does of course support standard scenarios, such as where MX records exist and a third-party may also send mail from your domain (i.e. a e-newsletter service like sparklist).
“v=spf1 mx include:sparklist.com ~all”
This entry states mail sent through the MX record of your domain as well as originating from sparklist.com (an email newsletter) is legitimate.
The record can continue to grow by adding additional hosts and MX records to account for all hosts that can send mail for a specific domain.
Adding an spf record to dns is straightforward. In BIND environments it is added into the zone file as:
myplace.com IN TEXT “v=spf1 mx include:sparklist.com ~all”
It is added to Windows DNS as an “other new record” and selected as a text record.
Before changing DNS though, you also have to ensure your MTA supports it. Of the three most popular open source MTAs, Postfix comes readily prepared for spf with an included plug-in called libspf2 ready to go. Sendmail is relatively straightforward to update for the process, with Qmail requiring easier than usual patching (surprise!).
For those using Exim – there is an spf how to also.