The original concept for Sender Permitted From (now Sender Policy Framework, see http://spf.pobox.com/) was to reduce joe-job attacks. You know, where someone else claims to be you, sends out a massive spam, and then you get to deal with all the complaints, bounces, counter-attacks from people who mistakenly think you actually did it, etc....
Insofar as this goes, that might be a decent goal. Of course, to be useful, everyone everywhere would have to implement the most stringent form of checking. It doesn't do you any good to publish SPF records and not have anyone else use them, or to not have them actually refuse to accept messages claiming to be from you but which do not originate from your designated mail servers.
Unfortunately, a lot of people seem to have latched onto this as the Final Ultimate Solution to the Spam Problem (FUSSP).
There are a lot of objections to SPF, some of which are semi-flippantly addressed at http://spf.pobox.com/objections.html.
If you are the sole owner of your own domain, and no one else is affected, then you can do whatever you want with it. But if there are other users affected, saying things like "just use a different provider", or "just tell the users to configure their client for port 587" are not particularly useful or practical. In many cases, there simply may not be any other options available.
Sites like AOL can use SPF with impunity because they want to force everyone who claims to be email@example.com to be using the AOL client or the AOL webmail system anyway. This is just another way to enforce that.
But there are too many mail forwarding services and access-only services to make this sort of thing practical on any kind of wide basis. Not only are you talking about changing the way that programs work, but fundamentally changing the way that users work -- always a losing proposition.
Some alternatives to SPF validate both the envelope sender address as well as the header "From:" field within the body of the message, which means that they also break most mailing lists, in addition to everything else. As bad as SPF is, at least it doesn't validate the header "From:" field, so it may break forwarding and aliases, at least it doesn't break proper mailing lists.
Now we hear that SPF and Microsoft's Caller-ID proposals are being merged (see http://spf.pobox.com/slides/thenewspf/). Of course, anyone can claim anything they want in the envelope, as well as in the headers. All Caller-ID does is verify that the "DAVE=" parameter in the envelope matches the "Resent-From:" header in the body -- how hard would that be for spammers to ensure?
If you don't understand the significance of this, read the "You Might Be an Anti-Spam Kook If..." page again.
Of course, modifying all MTAs to support the "DAVE=" feature in the envelope, and getting them to add the appropriate "Resent-From:" header in the body is a much bigger challenge.
Worst of all, SPF is implemented via the DNS. We know that the DNS is a simple UDP protocol, and does not have any inherent security. There are extensions to add security features to the DNS, but they are not widely supported within the implementations, or used in the field. These features are still under development, and while they have a bright future, they are not yet here.
Beyond the security issues of the DNS records themselves, we know that the vast majority of nameservers in the world are set up in highly insecure ways, some of which I highlighted in my invited talk Domain Name Server Comparison: BIND 8 vs. BIND 9 vs. djbdns vs. ??? which I presented at LISA 2002 and RIPE 44.
It would be trivially easy for spammers to poison the cache of nameservers around the world, so as to use SPF as a denial-of-service attack (claiming that the legitimate mail servers for a given domain were somewhere else than they really are), or to make you think that their machines are legitimate designated senders for all domains in existence.
In most cases, they could probably poison the caches of the nameservers for the domains that they are spoofing, so that you get the answer they want you to see, from the machines you should be seeing them from. They could almost certainly poison the caches of any target system that they wanted to send spam to, to make you think that they are legitimate.
To have any hope of this proposal working the way it was designed, you'd have to secure virtually all the nameservers around the world against cache pollution/poisoning.
Trying to add a security feature to one system via a mechanism that is itself inherently insecure and plagued by security problems, is a recipe for failure and disaster.
If you want to use SPF to help reduce to eliminate joe-job attacks, and all the potentially affected users understand all the risks and agree, then you've only got yourself to blame when it blows up in your face. But don't think that this is a panacea.
Indeed, don't think that this will do anything other than cause more harm than it could possibly solve. At least, not until they resolve some of the implementation issues and use more secure methods for reliably transmitting the information they want to publish.
UPDATE 2005-09-05: Early indications are that I was right -- SPF is not a panacea for spam, as many have mistakenly claimed. The Register has an interesting article at http://www.theregister.co.uk/2004/09/03/email_authentication_spam/ quoting a study from CipherTrust with statistics showing that more spam is sent using SPF than legitimate mail.
Now, when are we going to start seeing people talk about technological solutions to a sociological problem in a way that acknowledges the fact that everything in the security business is a balancing act, and that any proposed advance in one area needs to take into account collateral damage possibilities?