Tech Ads
Back to Article List
Originally published September 2004 [ Publisher Link ]
SPF - Sender Policy Framework for Email
Several mechanisms have emerged which attempt to thwart the proliferation of an ever increasing volume of spam. The SPF ("Sender Policy Framework") is a framework designed prior to the SenderID initiative, which is being considered as a standard for email authentication by major players like Sendmail, Microsoft and the IETF, among others. But the Apache Software Foundation and the Debian Project have both chosen not to implement SenderID because of its restrictive IP licensing. In this article we will take a close look at SPF: how it works and how it is deployed.
The exchange for processing an email takes place between two SMTP servers, where the originating party acts as a broker for sending a message which is later processed for delivery by the receiving server. However, this process assumes the originating party is worthy of trust. To this end, several mechanisms have been implemented on receiving SMTP servers to identify spammers, such as blacklists and content filters. Unfortunately, these have proved insufficient in the ever complex fight against spam.
SPF and SenderID technology prevents spoofing, a process widely used by spammers which generates messages that appear to originate from third party domains. If you have received an email appearing to come from a well-known address, only to realize it's spam; or as an owner of a domain you have been contacted by irate users demanding to know why you are spamming them, then SPF will be a welcome boon to your email infrastructure.
In order to deploy SPF -- and most importantly -- for it to work appropriately, both the receiving party and domain owner need to make modifications to their servers, in the case of the receiving party on the SMTP server, and for those wishing to protect their domain from spoofing through a special DNS configuration. Let's take a look at this process graphically :
When an email arrives at a SMTP server without SPF, it is assumed that it's domain origin is actually valid, however, with a mail server configured to operate with SPF, it queries the DNS records for the domain contained in the email and in return receives a response which allows the receiving SMTP to determine if the incoming message is real or spoofed.
The SPF information on a DNS server is included as a text record, the actual line in the zone file might look like this :
mydomain.com. IN TXT "v=spf1 a include:myserver.com -all" |
The first three elements are typical of a DNS text record, it's the information contained between the quotes which represents the SPF rules for the domain.
The v=spf1 sequence identifies the text record as
SPF information, while the letter a indicates that the
published I.P address for this domain is a valid origin for an email
message.
The include:myserver.com fragment indicates that
email which appears to be sent from mydomain.com can also
originate from an SMTP server in the myserver.com domain.
Finally, the -all flag indicates that any mail which does not
originate from the aforementioned domains/I.P addresses is not considered
valid from the domain owners point of view.
This is a very simple example of setting up an SPF policy for your domain. It will, however, guarantee that no spammer can hijack your domain name for sending junk mail. You can find a comprehensive tool for generating more elaborate SPF records here.
Setting up a policy is only good if it's enforced, and the enforcement of an SPF policy is the work of a mail server. Currently there is active testing being done by Sendmail and other major vendors, and there is already an open-source SPF implementation for Sendmail . Although the configuration details would go beyond the scope of this article, the process/configuration is very similar in nature to a mail-servers lookup of black-lists. In SPF's case, however, the information is obtained from DNS records, which guarantees a secure and reliable source of information for the domain.
Although SPF requires close cooperation between domain owners and mail server administrators in order for it to achieve critical mass, it is a step in the right direction. Given its strong support from a variety of organizations, it is becoming an important weapon in the fight against spam, along with other tools like content filters and blacklists.