Image spam: the threat returns
Did it ever go away?
Off we trot to the Reg Library to select some popular whitepapers for review. This week we mainline on email security, or to be more precise, email insecurity.
We were unaware that using pictures to evade spam detectors had peaked in 2007 and then fell away as security software vendors upped their game. In 2009, Image spam is back with a vengeance, as the bad guys have deployed new methods to sidestep detection. In its latest guise, image spam can cause problems for outdated email defences, according to Messagelabs. This paper by two Messagelabs software engineers reveals that some spam-producing and sending software is able to modify each image so that no two images are ever exactly alike. And it points to the dangers of remote image spam – where the email contains a link to a remote URL.
By MessageLabs reckoning,34 per cent of unsolicited emails in May 2009 was remote image spam, and another seven per cent was traditional image spam where the images were embedded or attached. Remote image spam has “clearly become a key weapon for the world’s spamming industry.”
This well written, thoughtful paper contains the gentlest of pitches, which can be summarized as: "employ a company that is eternally vigilant and understands email".
MessageLabs is the email hosted security wing of Symantec. Its rival MX Logic is soon to occupy a similar role for McAfee, which is buying the company to bolster its hosted email filtering services.
In this paper, MX Logic goes in for some thought leadership. In essence, the content is a bunch of definitions about Web 2.0 vulnerabilities and a checklist of countermeasures. A useful primer, which is readable to business managers, without talking down to the techies.
It’s all very well handing over email filtering to the cloud, but what about the entire email infrastructure? This is something that Dell is keen to facilitate. The computer giant has a rapidly growing services business and is on the hunt for customers, particularly for its hosted Exchange business. Accordingly, the company has commissioned or sponsored Forrester Research for this thorough report, which teases out the conclusions from interviews with 53 end user companies and 21 vendors.
The paper presents a spreadsheet cost model to help you calculate your fully loaded on-premise email costs and compare it against cloud-based alternatives. The upshot, according to Forrester: Cloud-based email makes sense for companies or divisions as large as 15,000 users. Also, every company can benefit from occasional users or email filtering to a cloud-based provider.
The financial logic for mid-sized companies and smaller to adopt hosted email appears impeccable. But how many of us are ready to put our trust into a third party provider? This paper will help you decide if money can overcome fear. ®
Just disable HTML + images in your mail client. I use gmail which automatically blocks images.
You just click the ones you want to see unless you add the sender to the whitelist. Easy peazy. Why MS and Netscape ever thought that rendering html in emails would ever lead to something good is beyond me.
Another alternative solution to the spam question
The problem with solutions such as Symantec Message Labs or the alternatives is that everyone's definition of spam is subtly different. Which means that they never get it completely right.
My solution is to use email suppliers who understand the email process, and how to defeat spam. Suppliers such as Fastmail.fm or Lavabit.com. Because they make effective use of techniques such as grey listing, spam is rare anyway. Then use an email client with built in Bayesian filters, such as Pegasus Mail. The way you train the filter will ensure that spam removal is tailored to your own tastes, and not that of some large Merkin company.
Works very well for me.
For the MX systems I run for my clients, apart from those originators who are whitelisted we invariably reject-on-first-delivery-attempt.
The spambots rarely if ever make a second delivery-attempt.
Of course we also have a blackhole-MX set to a value around 80 - on the basis that anything which deliberately chooses that rather than the MX=10 option is clearly trying something naughty.
And we populate the transient deny-list for the proper-MX servers from the 'tried high-numbered MX' fail-list.
Ah, what fun.