A closer look at SPF

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 closer look at this process.

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 :

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

Daniel Rubio is the principal consultant at Osmosis Latina, a firm specializing in enterprise software development, training, and consulting based in Mexico.