For the last year, ISPs have finally begun cooperating (and spending money) to fight the spam problem.
One of the solutions being bandied about is SPF (Sender Policy Framework), and if the IETF has its way, it appears SPF will be the winner.
Plenty has been written about the dangers of SPF, but the most dangerous part in my opinion is never mentioned: a false sense of security combined with the inability to scale “in“.
Usually when us software types talk about how an architecture/system scales, we are talking about the ability to add more and more users/processes/transactions to a system with no upper limit. With web applications, this typically involves the ability for an application to be cluster aware, with the ability to add more and more servers and still have them cooperate.
This is what we call scaling out.
HTTP has proven itself to be highly scalable. Just look at google running over 100,000 servers.
SMTP (the email transport protocol) has also proven itself to be highly scalable.
However, over the last 3 years, large ISPs have effectively been reducing the number of SMTP servers.
When I say servers, I don't mean physical machines, I mean SMTP domains.
For example, the email for my ISP is sent from east.smtp.cox.net. There may be 100 servers at that address, but there is still only 1 SMTP domain.
Why is this important?
First you need to understand how SPF works.
When a mail server receiving a message from a cox.net email address, it has no way of knowing whether the email actually came from a cox server.
SPF is an attempt to fix this.
Once SPF is implemented, the receiving server will look up cox.net's DNS record to find an SPF entry, which should list east.smtp.cox.net.
If it does, the email is let through, if not, it will be regarded as forged.
Earlier I mentioned ISPs are effectively eliminating SMTP servers.
This is because most major providers are blocking outbound port 25, the port on which SMTP travels.
In their defense, it is effective at eliminating a major source of spam and viruses, but it is harmful to the internet as a whole.
Consider this:
I could (but don't) use the @johnsample.com domain for sending and receiving email, the SMTP address would be something like mail.johnsample.com. However, I would never be able to use it, because my ISP blocks outbound communication between my mail client and the remote mail server. I CAN use cox's server to send johnsample.com email, and once SPF is implemented, create an SPF record for johnsample.com that reads east.smtp.cox.net.
Mail servers could receive my email and do a successful lookup on the sending server, and everything is hunky dory, right?
Nope.
There are millions of people who are allowed to send throught that server, and any one of them could forge my domain.
In fact, the forgery would even be more believable because it was given the SPF stamp of approval, the false sense of security.
This isn't a big deal for my little site, but there a thousands of people who run home based businesses who would run the risk of being believably impersonated.
SPF relies on a low domain to smtp server ratio.
If there was 1 smtp domain for every mail domain, SPF would be more useful, but with the number of useful SMTP servers only going down, and number of sites going up, SPF will only become a worse solution as each years passes.
So, now I'm Joe Spammer, and I happen to have a cox ISP account. All I have to do to guarantee a pass through spam filters is search DNS records for any SMTP server I have access to.
My guess is there would be at least a thousand doamins to pick from. Years worth of forgeable addresses.