Worst practices in antispam and antivirus defense

Learn about the worst practices in antispam and antivirus defense and how to stop doing them.

This Content Component encountered an error
by Joel Snyder

The world of antispam and antivirus has become so crowded that it's hard to tell what the best approach is for any company. However, there are some things that people are doing with spam and viruses that are obviously wrong. Let's go through the worst practices in the hopes that you won't get caught up in them -- or if you're doing them, that you'll stop.

#1 Worst practice: Accepting mail that you have no intention of delivering

This is not just a big deal -- it's the biggest deal -- and it's at the root of some of the worst practices on the Internet today. What's happening here is very simple. Somewhere at the edge of the enterprise is an SMTP MTA. Other mail systems, both spam and non-spam, connect to that SMTP MTA and try to send it mail. For each message, the sending SMTP system has to say, "This is for a particular user." The receiving SMTP MTA has three options at this point. It can say, "Yes, send me that message." It can say, "No, try again later and it might work." Or, it can say, "No, don't bother to try again because it will never work." In theory, you'd think, you'd only accept mail that you can deliver. If someone says, "This is for Jane Doe," and Jane doesn't work there anymore, you'd expect the SMTP MTA to say, "No, go away." But it doesn't always happen that way. Many companies are perfectly willing to accept mail even if they cannot deliver it.

Security School

Print this article

Webcast: Spam and Virus Mitigation Strategies

Take the accompanying quiz

Talk to the author and your peers in our discussion forum

Security School Home Page

This might happen for a couple of reasons. The oldest reason, and probably one of the most common, is that the receiving SMTP MTA doesn't know whether or not the mailbox is valid. It checks the domain name, but it doesn't actually know whether the user exists or not until later. Maybe it looks the user up in a database after it has accepted the message, or perhaps it simply hands the message off to another MTA.

The second reason why you might accept e-mail that your MTAs can't deliver is in a misguided attempt to deal with directory harvest attacks (DHAs). The theory behind a DHA is that the spammer tries every possible e-mail address, starting with a@yourco.com and ending with zzzzzzzzzz@yourco.com, in the hopes of identifying those that are legitimate. If you only accept mail for existing users, then you expose your e-mail directory to the spammer. They find out who can receive mail and, it is presumed, can more efficiently send you junk mail. To avoid the dreaded DHA, one school of thought is to simply accept all mail, whether or not the recipient is valid. This doesn't give the spammer any information, although it does tie up your MTA while it accepts mail for nonexistent users.

Both of these techniques, while reasonable in 1995, are simply horrible ideas in 2005. The problem is the messages that cannot be delivered. If you refuse a message or a recipient while it is coming over the wire, then handling the error condition of what to do with an undeliverable message is the other guy's problem. Once you've accepted the message, handling the error condition becomes your problem. What are you going to do with these undeliverable messages once you have them? Well, you have a couple of options. You are supposed to try to return them. The problem is that most of them are probably going to be spam. Spammers have two options when they send you mail. They can either use a valid or invalid return address. If they use an invalid one, then you have no way to return the mail and it sits on your MTA, clogging up the queues until your MTA determines that the message is unreturnable. You can't simply drop all messages that can't be delivered (although some misguided postmasters do just that), because then someone who makes a simple spelling error will never know that their message didn't go through.

It's even worse if the spammer puts in a valid address. You now send a bounce message to someone who didn't send the e-mail in the first place. In the quantities that spammers send their junk around, this amounts to a denial-of-service attack. There's even a name for it: a "Joe job" attack. The last time this happened to my company, we collected over a million bounced messages from MTAs that had accepted mail they couldn't deliver -- and then wanted to return it to us. That's a lot of really stupid MTAs.

Best practice #1: Deploy smarter MTAs

The way to solve this is to not accept mail you can't deliver. If you don't accept it, then the sending MTA has to deal with it -- not you. You don't become the instrument for someone else's denial-of-service attack, and you don't have to worry about filling up your queues with mail you can't deliver. If your border MTA isn't smart enough or capable enough to connect to your corporate directory and refuse undeliverable mail, it's time to replace that MTA.

Words To Know

Click on the word to read the definition.

As for protection against DHAs, accepting all mail is the wrong approach. A well-designed MTA can detect that a DHA is happening very easily. For example, it might get a message with 100 consecutive invalid recipients. From that point, it's easy -- simply refuse all recipients, valid and invalid, for an hour or so. Don't refuse them with a permanent error -- just say, "Try again later." If the message is from someone who has legitimate mail to send, they'll come back and try again later. If it's a spammer on a DHA, they're going to be gone until the next go 'round.

The benefits of refusing mail you can't or don't want to deliver are immense. Because you didn't accept the message, the sending MTA has the chance to send back an error message to the originator of the message. This gives you a chance to track errors and configuration problems, because legitimate mail will get a legitimate error code back to real senders. If you drop the mail into a black hole or some sort of quarantine with a million other messages, you'll never find subtle problems.

In fact, if you can get an antispam solution that runs at SMTP time, that's even better. Most antispam scanning engines run after the SMTP dialog is complete, when your mail server has already accepted responsibility for the message. A few bold products are completing the spam content scan during the SMTP dialog itself, while the message is being received but before the final "Yes, I will take responsibility for this message" response goes from your mail server to the SMTP sender. If you refuse mail you think is spam, you don't have to worry nearly as much about false positives. If I get back a message from my MTA saying that your MTA didn't accept it because it thought it was spam, then I can do something about it. If the receiving MTA thought it was spam and sent it to some dark occluded hole, there's no way to track it. I sent it; your mail system received it. Where did it go? Even with a good quarantine, it's easy to miss the one false positive in a thousand. Many antispam systems are attempting to do this with the most obvious cases of spam, using techniques such as blacklists, which simply refuse or greatly limit the amount of incoming mail from certain IP addresses.

Next page: #2 Worst practice

Next >>

This was first published in March 2005

Dig deeper on Security Resources

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close