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/.
Talkback
One great AntiSPAM Software allready supporting SPF and CallerID you find at http://www.nospamproxy.de
As I understand it, SPF will stop anyone from sending mail via an ISP which does not host their domain.
This means customers will be required to host their domain with the same provider as their dial-up connection, since the constraint on open relay means email senders always need to send smtp via the SMTP server at the ISP they dial in to.
This will be an issue for many small businesses which use dialup/adsl, do not run an email server to do dns lookups and send direct, and use a separate web hosting provider, which by necessity must host their domain, but doesn't provide smtp or dialup/adsl.
So this will have 2 effects
1. reduction in customer choice - you cannot pick a different web host from your connectivity isp
2. hosting only providers will no longer be able to operate unless they add smtp servers which can authenticate relaying senders.
No doubt ISPs love this, as it ties customers into buying more services from them, and big businesses are unaffected as they run their own smtp server. How many small businesses are represented in the group devising the standard? Those ISPs with significant small business customer-bases will probably have to provide a SPF-optout service to keep their customers (which the spammers will use).
In any case, spam friendly ISPs in less-well-regulated countries, and worms which use brute force attacks and dns lookup to get a legitimate sender address for a compromised PC used as a relay will soon render SPF ineffective, and spammers are very quick to exploit any loophole.
I doubt therefore whether SPF will have more than a fleeting impact.