Bouncing Spam Considered Harmful
Mail is just about the hardest service to administer. Compared to web sites, databases, firewalls – just about any other service – mail is more complicated and more critical. Except the few people who use the mail servers they authored, I think few of us actually understanding all the intricacies of the settings we’re using. All of us, however, have experienced the user response when one thing gets messed up.
Given this reality, it is not surprising that mail administrators rarely want to change their mail settings. If it is working, great. Please don’t ask me to tweak it unless that tweak is really important. Even adding one small change can throw things into an incomprehensible mess of bouncing mail and upset users.
So, this is not a rant. Instead it’s a thoughtful and hopefully persuasive argument why, if you are a mail administrator, you may want to make a really important change to the way your mail server is configured. Or, if you are not a mail administrator, why you may want to forward a link to this blog entry to your mail administrator.
The main argument is simple. Mail administrators should:
- delete all mail that you think contains a virus (virus false positives are practically unheard of);
- bounce (actually - refuse delivery - it is up to the sending mail server to generate a bounce or not) mail that does not conform to mail protocol standards, cannot be delivered (user does not exist), or violates one of your policies (e.g. user quotas);
- deliver all other mail to the intended recipient. Including mail that you think you are totally certain is spam.
Given the current day and age, you really really really should make an effort to warn your users if a message they are receiving may be spam, either by adding “SPAM*” to the subject line or another appropriate header to the message so they can choose to filter them out. This is Good and makes users happy.
Fortunately, most mail administrators do all of this. For all of you: my hat is off. Thanks for making the Internet a nice place to be.
Unfortunately, there are a number of mail administrators who have their mail servers configured to bounce messages back or drop them completely without feedback if they think they contain spam. Or worse, block all mail from a server that they think is a spammer.
This is a really really really bad idea.
Consider: if the message is from a spammer – bouncing generates yet more useless traffic clogging the Internet. Beside, that bounce will almost certainly generate a bounce back to you since the from address is almost always forged.
If the message is legit - then it shouldn’t be bounced!!
Some might argue the collateral damage position, which is: We need to let you know if you are using an Internet Service Provider that supports spammers. Your message isn’t spam, but it was sent from an evil ISP that has other clients that are spammers. You should pressure your ISP to stop supporting spammers which is the only way to rid the Internet of spamming companies.
There are several problems with this argument:
- Is this your job? The year isn’t 1982 when email was a fun expirement. It’s 2006. People rely on email in ways that we, as mail administrators, can only guess. Really rely on it. Yes, we should be educating our users against relying on a technology that, when you understand how it works, should scare the daylights out of you. But there are better ways of doing that. Our job is to make sure that as close to 100% of messages sent our way get delivered to the proper user. Not lecture our users or any one else for that matter about who they should use as an ISP. Bouncing or dropping a message to essentially make a point is juvenile given the stakes.
- It won’t work. There are a gazillion companies setup to send spam or poised to take over when there’s an opening. Telling a user who just learned how to send their first email message that they need to get a new ISP is just not a good strategy.
Another common argument is the system resources argument. We can’t possible deliver all spam without overwhelming our servers! We’re doing this to save our infrastructure!
If you are quietly sending all mail that you think is spam to /dev/null, then this argument makes sense. Of course, if this is true, then we really need to talk.
On the other hand, if you are bouncing suspected spam to the original sender, then you are really substituting one system resource for another. You are generating a new email message, which most certainly will bounce right back to you. Even if this is less expensive for your server, consider the traffic you generate for the rest of us. Also consider that: hard drives are cheap and without a lot of creativity you can auto delete messages from people’s spam folders that are older than x days.
If you are convinced (and I hope you are), please consider these policies:
- Use your MTA to ensure proper mail protocol compliance. Period. Many MTA’s have very easy to use methods for auto rejecting mail that matches one or several black hole lists or mail that matches certain keywords. Don’t use these tests. If you currently use them, disable them. Your MTA’s job is to delivery mail, not make judgement calls. Your MTA may have mechanisms for making sure the server sending mail follows proper protocols (e.g. properly identifies itself with a fully qualified domain name in the HELO hand shake, etc.). This is Good. Bounce mail that doesn’t follow proper protocol. No arguments here. Just don’t make your MTA bounce mail based on tests that can potentially produce false positives.
- Use a spam program to rank messages based on spam liklihood. You can use Spamassassin or Dspam or whatever you like. These programs use very complex and tested methods for evaluating the liklihood that a message is spam and then give it a ranking that your end users can use to filter out likely spam (but all mail is delivered). This way, if your spam program gets it wrong, they have the opportunity to either teach your spam filter how to get it right, or simply filter messages from a regular user to their inbox before the spam filter takes it out. This approach gives your users the power to control the spam filtering.
If the technical arguments aren’t convincing (or even if they are) you may also be interested in some very important political arguments why configuring your server this way is vitally important for the future of the Internet, particularly the future of the Internet as an open mass communications medium.