|
||
|
||
Sender Policy Framework (SPF) stops novice spammers but not the professionals, says Spammer-X, a retired spammer who has gone into a lot of the details in his book, “Inside the Spam Cartel”. The best way to beat SPF is to join it.
1. First, Joe Spammer rents a dedicated spam host in a spammer-friendly location, like China.
2. Next, he registers 100 domain names, and each domain is registered under a fake name and address.
3. Next, DNS entries for each of the hosts are set up, including a valid pointer record (PTR), an MX record and reverse DNS entries for each domain.
In other words, they do everything that legitimate domains should do when they set up a domain.
Next, a self-published SPF record is appended to each domain’s DNS entry, identifying the host as a valid, self-created SPF host that is responsible for any email coming from its domain. An example for superspammer.com might be the following:
v=spf1 mx ptr a:spammerplayground.superspammer.com -all
Reading this, we see that the permitted IPs that can send mail for this domain are any IP in the domain’s mx record (ie, get the mx record of the domain in the envelope sender), if the sender ends in superspammer.com, or if the IP of the A-record of spammerplayground.superspammer.com is sending mail.
With all of these set up, a spammer can send mail from any of these 100 domains and they will all happily pass SPF checks because the IPs are authorized to send mail. The basic theory behind this is that if you can’t beat them, join them.
I took the above example for Spammer-X’s book, but I added the -all to the end because he didn’t include it in his example. What if we did this:
v=spf1 mx ptr a:spammerplayground.superspammer.com ?all
This is yet another evasion technique: even if the mail is not authenticated it falls back to a Neutral. In other words, if the domain is spoofed, a spam filter should not treat is as such and should accept the mail anyways. After all, the guys at OpenSPF say that mail that returns Neutral should be treated the same as SPF None. As a spam fighter, it annoys me when domains do this (are you listening, Google?) because it effectively enables spoofers.
The flaw in this theory is that Spammer-X goes on to say that the majority of spam filters will treat the email with an SPF pass with a higher level of legitimacy and is therefore accountable for the email it sends. While this may be true for other spam filters, it certainly isn’t true for us. My own internal statistics suggest that SPF-authenticated mail is still marked as spam a little over 50% of the time. So, mail that is verified by SPF is by no means guaranteed to be valid.
Secondly, even if a domain with valid SPF checks were found to be sending spam, they could get blacklisted very quickly. Spam fighters could also use the SPF information to build spam rules in short order.
Spammer-X does have a point, however; a flaw in SPF is that there is no external 3rd party verification of SPF records—anyone can sign up for it. Verisign, for example, goes out and verifies websites to make sure that they are secure when they sign up for SSL. If you aren’t a good website, no “Verified by Verisign” for you. However, there is no equivalent “Signed by SPF” authority that makes sure that whoever signs up for it truly deserves to get it.
This has been a featured post from Terry Zink’s Anti-spam Blog where he has written a series of posts on Sender Authentication
Sponsored byVerisign
Sponsored byRadix
Sponsored byCSC
Sponsored byVerisign
Sponsored byWhoisXML API
Sponsored byDNIB.com
Sponsored byIPv4.Global
A World-Renowned Source for Internet Developments. Serving Since 2002.
Perhaps this will help people realize (or remember) that the intent of SPF isn’t necessarily to reduce spam, it is to help recipients verify that the mail is actually from the place that the message says it was sent from. So when I get mail from superspammer.com I know it came from superspammer.com and not from mybank.com (and, more usefully, vice versa).
SPF is hoping to reduce phishing more than it is spam.
SPF doesn’t stop spam or phishing. SPF can stop some spam as a side-effect, but savvy spammers know how to avoid it—ditto for phishing. SPF regulates use of a domain name in the “mail from” address, also known as the “return-path”. This is the address to which “bounce” messages are sent. You can send a relevant bounce message back to an SPF-verified address with assurance that you aren’t transmitting unwanted junk mail. Setting up SPF records for your own domain (without wishy-washy “maybe” elements denoted by question marks) can result in your mail servers being bombarded with fewer junk non-delivery notifications.
SPF isn’t all that relevant to phishing, because the “mail from” or “return-path” address isn’t normally seen by the recipient: they see the “From:” and “To:” header fields. DomainKeys/DKIM addresses this aspect of unauthorised use.
Mostly this demonstrates spammers are stupid, as most domains don’t use SPF, they could just send as any of those and save the cash.
You can’t use the SPF records published by spammers to build a blacklist, as you can’t trust data from spammers. They might list legitimate email servers in the record, like Gmail or AOL, or IP addresses of NAT devices and such like, thus causing unacceptable errors in such a blacklist.
Oh but you can, and very well too .. AFTER you crosscheck manually and see stuff like reverse dns pointing to the spammer domains, occasional whois or rwhois swips pointing to the spammer (or rather to whatever shell company he used to register the IP space), actual spam traffic coming from those IPs, and IPs blocked in the identified ranges because of spam from those domains ..
Actually Terry, we should all hope that the spammers use SPF.
SPF is only one piece of a complex puzzle. It provides a certain level of protection at the ehlo and it protects the RFC2822 Mail From.
The claim that some have made that this somehow “stops spam” is simply fantasy. If Mail Admins paid attention to SPF records it would help reduce backscatter (Joe Jobs) for domains publishing SPF records with a strong assertion (-all).
A strong assertion by a domain would also help protect against forgery of the Mail From. This of course raises issues regarding forwarding where the headers are not rewritten.
A domain which really wants to protect itself would also use DKIM signing in conjunction with publishing SPF.
The ultimate goal is to reduce the attack surface available to the abusers, it is not likely (without a total redo of an awful lot of RFCs) that the attack surface can be reduced to zero.
Your article is more “dog bites man” than “man bites dog”....not particularly news.
I’m actually aware of many of these points. This post is part of a larger series on sender authentication that I started writing on my blog about two months ago, the rest of the series is available here.
The series is intended to go through the basics of email headers and how sender authentication works, as well as how antispam companies can use techniques such as SenderID and SPF.