|
 |
By Brandioch Conner Here's the short answer on how you ("you" being the recipient) can stop spam: you can't. The real problem is the other email admins and ISP's do not see the need to correctly configure and maintain their own systems. Spam isn't a problem just because it means you get a lot of mail. Spam eats up bandwidth and there's an increasing probability that you'll delete a legitimate message while wading through the spam. I'm not even going to define what "spam" is because it means different things to different people and there's always an argument about "what if such and such and such happened, would it still be 'spam'?" Even if you only consider the machine sending it you still run into problems. Right now, I know of five different ways to send spam (listed in order of annoyance to me).
"Spam zombies" are bad, right? But how do you identify a spam zombie during the SMTP connection? You can't check the machine itself for infections. All you can check is the data that is published (or the absence thereof) and its actions. Here are some of the characteristics of a "spam zombie."
I'm sure everyone can see where this is going now. I work for a small insurance company and I've still had to make seven specific exceptions for clients who fit one or more the above cases. I'm sure it only gets worse as your company gets larger. And that isn't even counting the spammer's ability to adapt faster than many of the email admins. Spammers are one of the first groups to adopt SPF. I know the problems with SPF so don't bother with that. The point is that the spammers will adopt anything that they believe will get their spam through your defenses. Spam zombies would be almost completely wiped out if the ISP's would:
But that's not going to happen soon because it isn't financially reasonable for them to do so. For each person who used to send via port 25, the ISP's tech support people would have to deal with a support call from that person. Not to mention the additional training those support techs would need. Not to mention any infrastructure changes that they'd have to implement. Not to mention that some of them do not have the expertise necessary to do so. Long story short, it's not going to happen. Some will (Comcast does), many won't. Right now, I've dramatically reduced the spam we receive with a combination of tests based upon the above three criteria that cumulate in an unknown box being forced into greylisting. But this is only a temporary and very brittle fix. All it would take for the spam zombies to defeat it would be for them to re-send their spam after 1 hour. That should be a minor code change and it should be easy to push out to all the zombies. Like I said, the spammers are faster to adapt than a lot of the legitimate email admins. In preparation for that day, I'm collecting statistics on all our sent/received email. When worse comes to worst, I'll fall back to personal white/black lists. Yes, they suck. They suck badly. They require far too much manual labour to maintain or they are too easily defeated if scripted. The good news is that it looks like 80% (by item, not size) of our email is from/to the same servers, day after day. If you work for an Internet sales company, your numbers are probably a lot different. The bad news is that not all of that 80% is business related. Most of it seems to be personal messages. So the remaining 20% may be more important from a business aspect than the 80%. So the good news may not be that good. On the other hand, the Spamassassin tests are getting better every day. So even if I accept email from a spam zombie v2.0, there is still a very good chance that it will be correctly identified as spam. The downside is that once my system has accepted the email, I cannot risk deleting it before the user sees it, just in case my system is wrong. So the end user still has to wade through the spam. But the more accurate my system is, the more my users will come to accept its evaluation and so legitimate email may be deleted by them just because they didn't have time to verify it and took the machine's opinion as fact. Not to mention that a lot of the tests being run depend upon other people already receiving the spam and correctly identifying it and reporting it to the sites that my system will check. This is great as long as I'm last on the spammer's list, but when I'm first, the junk comes through.  
|
 |
|
|
|
|
| All times are recorded in UTC. Linux is a trademark of Linus Torvalds. Powered by Linux, Apache and PHP |
