When ghosts spam

It's reported that as much as 97 per cent of email consists of spam, viruses, phishing or similar "malicious" content. That seems a lot.

One of the reasons the figure is so high is that the vast majority of spam is sent to addresses that just don't exist, have never existed, and will never exist.

In addition to harvesting addresses from websites, a lot of email addresses are just made up - perhaps sensible dictionary attacks using mailboxes such as "info@" or "sales@". But often seemingly random names or a real email address with some letters missing or added are used.

We can account for this through resale of corrupted email lists, spammers inflating the size of their distribution lists to get a better sale price, or, perhaps most likely, just plain stupidity on the spammer's part.

It is this email that now accounts for the bulk of spam - for most domains, especially those with few real email addresses, most spam will be sent to non-existent recipients.

The second point is that spam is usually sent from a real email address and chances are, that, eventually, it will be one of your users'.

But what about all those messages sent to non-existent email boxes? Well, it's more than likely that some mail relay will start to send non-deliverable reports (NDRs) to you. If you're a system administrator, they are probably one of the biggest sources of email problems.

Users find them confusing, and this is increased by the non-standard way email systems generate non delivery reports. Some include the full message, others just the subject.

At least these give the user a chance to see that the message was just spam. But often the non-delivery report is stripped of all useful information: "the message you sent to fred@example.com could not be delivered".

People find these disturbing, raising fears that their identity is being stolen. My own system does a pretty good job of filtering out these spurious non-delivery reports, but it's not always easy.

You can't just blacklist the sender of these because they're not really spam, just a side effect of that email system's configuration. If you blacklist the systems that send the NDRs, you blacklist them from sending real emails.

There are some anti-spam systems that simply make the problem worse. I recently came across one that implemented keyword blocking. But whenever it saw a keyword it didn't like, it sent out an email, containing the "offensive" word in the subject line. But not just to the sender. It opened up the email, and sent the same offensive keyword to every address the email had been cc'd to.

What stupidity - and what a great way to do a reputational attack on the organisation running the system. Simply send an email containing an offensive word to the system, fake the from address, and stuff the "cc:" list with the addresses of all the people that you think would take offence. And let the system send it out. While most systems aren't quite that bad, they can do better.

A simple mechanism that has been around for a while now, so long, in fact, that it's even supported in Microsoft Exchange, is the "Sender Policy Framework" or SPF. This is a DNS extension that does for sender addresses what MX records do for recipient addresses. The MX record tells you where the email should be sent.

The SPF record tells you where the email should come from. Using SPF is a two-step process. First the domain owner has to publish an SPF record - currently, only around 10 per cent of domains have one.

The second step is for the email receiver to take note of any published SPF records. You may not want to block email that doesn't come from where the SPF record says it should, but you could at least refrain from allowing your anti-spam system to send an NDR to that address.

So, if you get a spam email from one of my domains, check my SPF record, and don't send me an email telling me that my message entitled "82 per cent off in April" couldn't be delivered. It will stop me getting annoyed.

Ian Castle, CISSP, is a senior consultant at information security consultancy ECSC.

Copyright © SC Magazine, US edition

securityspamwhen