Sender Policy Framework: Encyclopedia II - Sender Policy Framework - Limitations and controversies

Sender Policy Framework - Limitations and controversies

SPF normally only validates the domain of the envelope sender (listed as "Return-Path: " in e-mail headers). Domains that share mail senders (e.g. with virtual hosting) can forge each others' domain, and mail forwarding systems may also allow other domains to forge domains. SPF does not validate that a given e-mail actually comes from the claimed user, because it operates at the network level.

SPF breaks inter-system SMTP forwarding (where an agent forwards e-mail to someone else without changing the "from" address). This is a problem for forwarding services (such as acm.org and pobox.com). One solution is for the SPF record to specify the forwarder as an allowed sender, but this is problematic because the sender has no idea in general what aliases the receiver might have configured. Ideally, a receiver should have identified, and whitelisted as needed, their SMTP forwarding aliases. However, this can be difficult when the receiver has forgotten about old aliases or is an ISP with no control over aliases configured by its users. In these cases, the receiver should never reject mail based only on SPF. A more general solution is to switch from forwarding (where the envelope sender is preserved) to remailing (where the envelope sender is changed). Remailing is easy to implement in most systems, but until implemented, mail may be incorrectly rejected by some receivers.

Steven M. Bellovin has written a long e-mail dated January 5, 2004, discussing some of his concerns with SPF. Some of these include:

• SPF uses of TXT records in DNS, which are supposed to be free-form text with no semantics attached. SPF proponents readily acknowledge that it would be better to have records specifically designated for SPF, but this choice was made to enable rapid implementation of SPF. In July 2005, IANA assigned the Resource Record type 99 to SPF. SPF publishers may publish both record types and SPF checkers may check for either types. It will likely take many years before all DNS software fully supports this new record.
• The SPF specification provides ways to avoid processing that a spammer could forge. For example, a spam engine could send e-mail with a local-seeming HELO, MAIL FROM, and From: entries, in which case SPF isn't to be used (however, public SMTP servers should reject anything that seems local).
• Various other (fixable) problems exist in the current specification. It could be argued that this specification was rushed to make it rapidly available.
• As of the time he wrote his message, there was no consensus that this is the right way to go. Some major e-mail service providers have not bought into this scheme. Unless and until they do, it doesn't help much, either for their customers (who make up a substantial proportion of the user population) or for everyone else (since their addresses could be forged). It's worth noting that since this concern was raised, AOL has embraced SPF. From Oct 1. Hotmail and MSN also published their own SPF records, and filter incoming mail using SPF.

Bellovin's strongest concerns involve the underlying assumptions of SPF (SPF's "semantic model"). When using SPF, the SPF DNS records determine how a sender is allowed to send. That means that the owner of the domain will control how senders are allowed to send. People who use "portable" e-mail addresses (such as e-mail addresses created by professional organizations) will be required to use the domain owner's SMTP sender, which may not currently even exist. Bellovin argues that SPF will tie many users more strongly to their ISPs and/or their employers. Organizations providing these "portable" addresses could, however, simply create their own SMTP servers, using appropriate mechanisms to authenticate their users. Such mechanisms include secured VPNs, SMTP with authentication, and POP before SMTP.

Bellovin notes that it would be more flexible to permit delegation of individual user names to particular sending machines. However, he also grants that it would probably not be affordable, specifically noting that it would probably require too much public key cryptography. Although he does not note it, there are many other complications to this more flexible approach. Supporting individual user delegation would require services to maintain each entry, as well as requiring domains to manage each user account. This would be an extraordinary undertaking for many large domains. In contrast, SPF requires adding only one line to a DNS entry; once created, it rarely changes. Also, SPF results can be cached for each domain, so SPF as specified is far more efficient in terms of network bandwidth.

Another limitation is that SPF does not mix well with other spam-prevention measures currently in use. Specifically, many ISPs limit their customers to using only their own SMTP servers. A professional working from home, attempting to send from his/her company e-mail address, will be rejected by SPF if forced to send through the ISP's SMTP server instead of the company's server.

In spite of its limitations, many people have decided that the pros of SPF outweigh its cons and have begun implementing SPF. Anti-spam products such as SpamAssassin version 3.0.0 implement SPF. Many mail transfer agents (MTAs) support SPF directly such as Santronics Wildcat! SMTP mail system, or have patches/plug-ins available that support SPF, including Postfix, Sendmail, Exim, and Qmail. Many prominent domains decided to post SPF data for their domains as of mid-2004, including AOL, EBay, Google, W3C, and Amazon.com.

Adapted from the Wikipedia article "Limitations and controversies", under the G.N U Free Docmentation License. Please also see http://en.wikipedia.org/wiki