One giant step towards ending spam

The downsides
SPF isn't without other issues, but these don't affect the majority of users, and they're relatively easily overcome. The most immediate problem is that genuine users won't be able to send mail directly from remote locations. For instance, a teleworker may wish to send work email from home, but through their ISP's SMTP server. If the company's SPF record stated that this wasn't acceptable, these genuine messages would then be rejected. However, this can be worked around quite simply. The user could connect to the office network via a virtual private network (VPN) and use the company's SMTP server to send mail, thus ensuring that it came from a machine permitted by the SPF record. If connecting to a VPN isn't possible, you could make a single SMTP server available for sending from outside your network. This would need to be secured using SSL or SASL to prevent it being abused, with genuine users given credentials to log onto the server.

SPF also breaks mail forwarding, as used by some mail providers or by users who create a '.forward' file on Unix systems to send mail from one account onto another. The problem is that the forwarded mail isn't coming from the originating domain -- that of the mail's sender -- so is quite legitimately rejected by an SPF check. A solution to this is the Sender Rewriting Scheme (SRS). This is a method of rewriting the headers on a message so that it passes SPF checking, but still carries the address of the original sender so that replies to the message can be sent. SRS also includes some extra security features to prevent it being abused. Most organisations don't need to worry about implementing SRS -- it's really only an issue for mail forwarding providers.

What else is needed?
SPF won't stop a spammer buying a domain, creating an SPF record for it, using it to send messages and then discarding it once it's blacklisted. To counter this, reputation management schemes can be set up. These can work by mail administrators reporting domains used to send spam manually, or by recording the number of messages sent by a particular domain, and how many of these were rejected by the recipient. How long a domain has been registered can also be used to judge it -- a domain that's only a few hours old is unlikely to want to send large numbers of messages if it's genuine, so messages from it can be throttled. But most importantly, if spammers are having to buy domains to use, it's affecting their business model, and it's also giving a paper trail back to their real identity via the registry used to create the domains.

As of March 2004, over 8,000 domains had published an SPF record. Included in there is AOL, a popular domain to fake among spammers. For SPF to be truly successful, it needs to be the rule rather than the exception, so widespread adoption is key. The advantages of SPF over other similar schemes include its minimal implementation cost. There's also nothing to be lost in running a trial implementation, and it can work in conjunction with existing anti-spam measures.

Click here for Part Two of this special, "How does Sender Permitted From work?"

For more information, see

http://spf.pobox.com/,http://spftools.infinitepenguins.com/ and www.libspf.org/.