SPF (Sender Policy Framework) was originally designed to prevent joe-jobs. In this mode, an MTA (Mail Transport Agent) uses SPF to verify the envelope sender (SMTP (Simple Mail Transport Protocol) MAIL FROM) address during SMTP time. But some people pointed out that SPF can also be used to verify headers to prevent phishing. When used to verify headers, the agent could be an MTA or an MUA (Mail User Agent), and slightly different rules apply: you have to consider Sender and Resent-From as well as just the “From:” header. Header verification is one of the central themes of the May 2004 merger between SPF and Microsoft CallerID For Email.
“SMTP+SPF: Sender Policy Framework [1]”
The other day Mark sent me email pointing me to the SPF (Sender Policy Framework) [2] site. Interesting idea, and one I've come across before and thought about, but didn't think it had enough of a following to warrant doing (although, given the contents of the DNS (Domain Name Service) zone files I have, it's odd that I haven't adopted this yet). But seeing how Microsoft has jumped on board …
Oddly enough, while reading an article about antispam measures [3] I had a sudden brainstorm about a way to make it more difficult for spammers to send mail out. It's a combination of two methods, one in current use, and one that just popped into my head.
The first method is to allow only email from designated MX (Mail eXchange) hosts. That's currently being done, and is a method that SPF was designed to help facilitate. The upshot of this is that a spammer can't just slap a machine on the Internet and spam from that—no, it has to come through a machine that is designated, via DNS, as an MX host. But there are two ways around that: going through the ISP (Internet Service Provider)s SMTP server (which the ISP monitors and they are usually aware of heavy use and can cut off the offending customer) and by registering a domain and setting the IP (Internet Protocol) address they get as an MX for that domain.
And it's the second idea that counters that problem. Each DNS record has a “time-to-live” value—how long that record is considered “valid.” Simply reject any connection from an MX host who's MX record's time-to-live is less than, say, a week (actually, I would check all MX records and reject it if any are less than a week).
If I get spam from a domain, one quick check of the MX records and I can stop receiving spam from that domain for a week. Not much in the scope of things, but easily doable and scriptable even. But enough servers do that, and the spammer has to wait a week to send email. It's not enough to change IP addresses—that's easy enough. But the MX records have to change and propagation takes at least a week …
One way around that is to register as many MX records for a given domain as possible, but if you also dump the connection if there are more than say, a dozen MX records (AOL (America On-Line) [4] gets by with 4, so does MSN (Microsoft Network) [5]; IBM [6] on the other hand, uses 11). Another way is to register a whole bunch of domains. Possible, but that does tend to cut into the profits a bit …
And really, that's the only way to make spam go away, but making it too expensive to send.
Well, I went through some of my email today, applying the rules mentioned above to them, and while all the spam emails would have been stopped, I also recieved two false positives—one from a mailing list I'm on, and one for the guy I work for.
Looks like there are still some issues to work out here …
[3] http://www.techdirt.com/articles/20040603/072222_F.shtml