Posts tagged ‘SPF’

SPF Usefulness

The SANS ISC Handler Diary is asking for your experiences with SPF. Its funny timing because i just configured SPF for my domains last night. I’d been using SPF records previously, but when I left PowWeb for Dreamhost (which changed my authoritative DNS server) I didn’t set up SPF again.

I’m using Google as the mail server for my personal domains. Configuring SPF for google is pretty easy. Just create a txt record for v=spf1 include:_spf.google.com ~all. Like most SPF implementations, they recommend you use “~all” which tells the remote server the list of authoritative servers is merely information and not to reject mail based on this alone. I kind of wonder what use that is. But it seems to take more guts to use a “-all”.

To me, SPF is not exceptionally useful. It just seems like the only thing you can do to prevent yourself from being Joe Jobbed. Sadly through the years remote mail servers are more likely to allow backscatter than use SPF.
At the same time, its never shot me in the foot. ~all instead of -all is probably to thank. I have seen Hotmail headers that indicated that if I was using -all they would have blocked me. They just had a screwed up implementation that couldn’t handle “include” statements in SPF records. SPF is not well liked by *nix folk. It breaks .forward. It breakes mailing lists that send as the message poster.

Iconix Phishing Protection

A couple days ago I received email from Paypal titled “New PayPal Plug-In – Shop anywhere online.” That struck me as kind of suspicious so I looked at the mail headers. The headers showed the message did originate with Paypal’s servers, and more importantly it contained a domain key (DKIM). According to Wikipedia, “DomainKeys is an e-mail authentication system designed to verify the DNS domain of an e-mail sender and the message integrity” through the use of a cryptographic hash.
If I had to dive into the headers to determine the message validity, how would the normal user do? Are there mail clients that would have automatically verified DomainKeys and SPF for me?
A quick Google found a product called Iconix. Iconix works with Outlook, Outlook Express and a bunch of webmail providers (No Thunderbird support) to take the guesswork out of which messages are real.
Once installed, Iconix looks at SPF/SenderID and DomainKeys to determine message authenticity. Next it looks at message identification- this is a list of companies that have paid Iconix and registered with them. If both are verified, then the message’s “display From” will be altered to present a logo of the sending organizations choosing. This allows recipients to tell at a glance that the message is from who it says it is.
Iconix at first appeared to be a great solution. Its been reviewed in several trade publications. I didn’t immediately find anyone disparaging them online. Iconix is installed software. As such you do wonder a bit about privacy and security implications. Their FAQ does say that the sender’s email address is sent to Iconix.
The problem is that they only provide this service for the companies that have signed up. I would expect that they could validate the DomainKeys or SPF for anyone using those email technologies. While this product does solve my original question, “how can ma and pa kettle obtain a reasonable level of trust in email”, it only does so for companies that have paid Iconix. That is an extensive list, and it provides better assurance that SPF and DomainKeys alone could.
While Iconix is not available for Thunderbird, there are other solutions that plugin to Thunderbird for SPF and DomainKey validation.
- update – 6/11 – fixed above where I refered to Firefox when I meant Thunderbird. Firefox can be used just like IE in conjunction with Iconix at many webmail providers.

Google CAPTCHA breakage leads to increase in spam

MessageLabs Intelligence report for February 2008 reports that ” 4.6% of all spam originates from the major web mail-based services and the proportion of spam from Google increased two-fold from 1.3% in January to 2.6% in February.”
They speculate that this increase in Google spam occurred because hackers have recently compromise Google’s CAPTCHA. A CAPTCHA is used to prevent automated account registrations by spam bots. Yahoo and Hotmail’s CAPTCHA method was previously compromised.
Mail from the major webmail services (Google, Yahoo, and Hotmail) are from legitimate servers, and domain key signed or have a SPF record. A spam filter then can only act on the content of the message and not the reputation of the sender.
Spammers are in it for the money and they aren’t going to slow their attack. Webmail providers need to continue to work to be good Internet citizens and prevent their servers from being part of the problem.

Backscatter

One of our users is a victim of backscatter and has been reporting them to the abuse mailbox at work.
Backscatter is the unsolicited mail that occurs when a spammer sends out email as you and poorly configured email server return all manner of notices to you. Its funny to watch the Barracuda spam firewall spamming the employee with the message Undeliverable: **Message you sent blocked by our bulk email filter** and an RFC rejection. Along with that is the usual ‘out of office’ and non-deliverable reports.
I figured there really isn’t much we can do. I decided that maybe its time to adjust the SPF record and change it from a ~all to a -all setting. Surprise, Surprise, I found that there was not a SPF record for the domain in question. I’m not sure if I dropped the ball on that or if our external DNS provider did something crazy again. At any rate, that is getting fixed but given how few people use the SPF record, I dont think it will be a lot of help.

PowWeb adds SPF to mail servers

I was pretty happy today to see that my webhost has added SPF to their spam fighting techniques. This needs to see more widespread adoption.
Right now if someone sends out 10 million spams from my domain to 5 million servers on the internet, roughly 80% of the spam will be to a bad address. An NDR would be generated and sent to me. Its a rather effective denial of service attack, assuming you can insulate your self from identification as the attacker. If those servers implemented SPF they would see that the message isn’t from a valid sender for my domain, and hopefully drop it. Instead many senders send an NDR without enough of the original message, so it doesn’t get caught by my spam filters. Not sure if I’ve explained that well or not, its pretty late. It is too easy to get your mail servers DoSed indirectly by some spammer.

More SenderID Bashing

Looks like another company wants to generate some good PR buzz by bashing Microsoft and bashing SenderID. This is just like my article from last fall. A company has breathlessly reported that spammers are using SenderID. Its not that bad.
MXLogic’s press release is parroted by techwebnews (parent of SecurityPipleline). They say that spammers use SPF to get an air of legitimacy to their email. I would argue that any spam filter that determines legitimacy by the presence of an SPF record is flawed. Its like the old spam assassin problem. SA automatically whitelisted anyone who signed their mail with a digital signature. Does that indicate a problem with the digital signature? No its indicates a bad implementation.
SPF is about reputation and accreditation. A domain owner publishes who is allowed to send mail from that domain. Everyone else is considered questionable. That cuts down on spam and viruses using common domain names or your own company domain name. So the spammer registers throwaway domains and creates an SPF record. You still have your other spam filters. You still have the ability to blacklist.
Meng Wong provides an illustration.

Exchange 2003 SP2 and SenderID

Exchange 2003 SP2 includes support for SenderID. I wonder if this will kickstart the usage of senderID and/or SPF. I currently SPF on my personal domains.

eWeek Article misinforms readers on Yahoo Domain Keys

“Scammers Exploit DomainKeys Anti-phishing Weapon.” So screams the headline in a recent eWeek article.
Oh boy. Here we go again. Another uninformed article from a tech writer who couldn’t learn from the response to the uninformed articles about spammers abusing SPF. These articles are really dangerous. They lack any understanding about what SPF and Yahoo! Domain! Keys! actually are intended to accomplish. The articles are read by decision makers and implementers who haven’t taken the time to read up on these new technologies and they take the article at face value.
eWeek has an area for comments on its articles. One insightful comments is purportedly by Dave Anderson CEO Sendmail. He says “Authentication does not prevent fraud. It does not prevent spam. It does prevent impersonation. None of the proponents has ever suggested otherwise. Once we have email authentication we know who is sending emails and can take many actions to prevent abuse.”
It isn’t a shock to anyone but these tech writers that an open standard which can be used by anyone, is used by a spammer. Merely having a SPF record or a Domain Key should not grant passage to a message. Instead it verifies the source of the message.
The article mentions spammers using domain keys with a yahoo account. Great! If every spammer did that, when you saw a yahoo return address, you would be guaranteed the spam came through the Yahoo system and you know who to complain to.
The closing paragraph of the article is the most interesting. And most likely the most factually incorrect part of the article. “They [phishers] then send out normal phishing messages that take the recipient to an attacker-controlled page located on the bank’s server. These attacks are insidious because the victim is visiting a legitimate site, security experts warn.” According to this the phisher already has hacked the banks server. If this is the case, game over. Phishing is unnecessary, they are inside the banks server. Most likely the author was trying to say the phishing site often uses images from the legitimate server to maintain the same look and feel.
The thing that galls me most about this horrible article is that I learned about it through a SANS newsletter. They passed the URL on and quoted the article without comment. Its as if they were endorsing this article.

Trouble for Microsoft SenderID

The Apache Group and Debian developers have marshaled the anti-Microsoft forces and convinced the IETF to scuttle the proposed SenderID standard. They do this claiming that it is anathema to have a “standard” be encumbered by patent. Somehow I think that this would not have been this first time that a standard would have surrounding patents. Further I would postulate that if this were not Microsoft that narry a word would have been said about it.
The Register article on this has a link to a discussion list archive.
It will be interesting to see what the next step is. Some see SPF separating itself from Microsoft and being implemented as a standard while Microsoft SenderID is available to the MS customerbase.
Not sure why the Slashdot and Register articles are so celebratory. A potential weapon in the war on spam was just handed a defeat. I guess some people will hate anything coming out of Redmond.
Looks like we’ll all be implementing Yahoo! Domain! Keys! soon. :(

Infoworld’s antiSPF article

There is an article over at infoworld, , about a ciphertrust study of SPF.
Ciphertrust reports that only 5% of mail is using SPF and of those using it with correct syntax an even number of spammers and legit sites are using it.
Infoworld breathlessly reports this in a manner that would indicate that even before the standard is ratified it has been circumvented by the spammers. Those that continue reading down the page find this really isn’t true.
SPF is not intended to end the problem of spam. It is intended to end the problem of mail spoofing. (Sidenote: microsoft’s implementation SenderID apparently only checks the visible header, not the envelope header, so this apparently wouldn’t solve the problem of the forged envelope from resulting in employees getting virus notices from other companies for messages they didn’t even send.) Spammers registering their domain names with SPF doesn’t allow them to continue to spoof valid addresses.
The real problem with SPF is the lack of implementation by major players. Even commonly phished credit card companies and banks haven’t jumped on board. The article points out only 31 of the Fortune 1000 have SPF records.