Spam and Viruses: Unholy Matrimony, Part 1 - Page 2

What about blocking only executable attachments, such as .exe, .pif, .bat, and so forth? Unfortunately, that just isn't good enough anymore. As the recent infestation of the deceptive, .zip-abusing Mimail worm proves, the bad guys don't stand still. It's an ever-escalating war, and it's impossible to tell what trick spammers will think of next.

And even if your gateway software is smart enough to recognize deceitfully-named attachments, such as .jpg.pif or .doc.exe, what about the myriad of undocumented Windows executables? That's right, there's a boatload of them that have accumulated over the years, and I doubt anyone knows what all of them are. (And of course, only spammers and black hats are interested in finding and exploiting them.)

So back to using FTP rather than email for file transfer — what if someone uploads a malicious file to your FTP server? The benefit of using FTP is that, unlike email, which is open to random pounding by total strangers, you'll know exactly who put what on your FTP server.

I know the thought of getting all your users to jump on the FTP bandwagon sounds rather challenging, especially early on, but in the long run it will mean a lot less work — and will be a lot less traumatic — than trying to police a network awash in unrestricted email.

Chuck HTML Mail

It's a shame how nice things get ruined. HTML-formatted messages can carry all sorts of nastiness, such as executables disguised as URLs, malicious javascripts, and even more dangerous VB scripts. All of these are adept at doing nasty things like phoning home upon receipt and again on read, connecting to nefarious Web sites, and tracking users with clandestine web bugs. In short, any dirty trick that can be executed on a web site can be duplicated in HTML-formatted mail.

Us cranky oldtimers like to gripe that "plain text was good enough for my granny, and it's good enough for me!" Well, I have mixed feelings. Yes, HTML messages waste bandwidth; and yes, they permit people to display their bad taste in color schemes; and yes, these messages look like crap in plain text. However, people do like pretty stationery and imagery, which means fancy-formatted mail is here to stay. Hopefully a new ornamental format will emerge at some point — one that is not exploitable.

In the meantime, I can't think of a single good technical reason to accept HTML-formatted mail. The risk is too great. Divert it to the same bitbucket stripped attachments are tossed into. Be sure to send a polite rejection message so the sender knows their mail did not get delivered. It's good to include a brief explanation and instructions on how to send plain text messages. Many users don't even know what mail formatting is; a little polite education goes a long way.

Alternatives to the Bitbucket

A blanket rejection of attachments and HTML messages is not always desirable. Messages from customers, mail from the dimwitted but important executive — there are many situations where sending a rejection notice is probably not a good idea. And technical staff (hey, that's us!) typically object strenuously to any kind of mail restrictions.

While there are numerous utilities for removing HTML code from messages at the server, and although we might be more comfortable with controlling events at the server level, the client side is equally important. There are many email clients, such as Eudora, Pegasus, Kmail, and Evolution, that have advanced message-management features and ways to foil malicious code. We will look at these in part 2.