Mastering the Abuse Process: Dealing With Spam

If there is one thing as a system administrator that takes up the majority of my time, it is dealing with spam. Spam, unwanted or unsolicited email, has been around as long as email itself, and the manhours spent by countless system and network administrators attempting to mitigate it on their networks has been staggering. Oftentimes, those running web hosting environments may find themselves more susceptible to spam. I am going to share some tips and tricks I have found. This post will cover both controlling spam coming into your server, and spam generated on your server.

Surprisingly, one of the most effective tools admins have in the fight against spam are simple lists. These lists are called RBLs (Real-time Blackhole Lists). Although they are mere lists, what makes them so effective are the administrators of these lists. Essentially, an RBL is a list of hosts that the list administrators believe are sending large amounts of spam. They confirm this in a myriad of ways, but the most common one is the honeypot, where they setup an unlisted email inbox and wait for unsolicited spam to come into it. Many mail servers support the ability of adding the RBL addresses to your configuration to automatically block known spammers. The two most common RBLs you can use are and Adding these to your mail configuration should cut down on a large number of spam emails you receive.

At this point, you’re probably wondering what happens if your server ends up on one of these lists. Generally, the cause can be attributed to three different causes:

  1. A compromised email account. Keep those passwords strong!
  2. A script on your webserver that has the capability to send mail
  3. A strange configuration problem on the mail server itself

In most of these cases, you will want to investigate the mail log of your server. An important thing to note here is that every piece of mail that goes in or out of your server is tagged with an ID of some sort. RBL providers have to limit the information they provide to protect their honeypots, but they will usually show the message ID so you can easily find it in your logs. If not, there is usually a timestamp and partial address that you can corroborate in your log.

Dealing with compromised web pages sending out spam can be a little trickier, because by default the amount of information you’ll get in the logs/headers won’t indicate where the script is running from. As of PHP 5.3.x, you can enable a setting in your php.ini that will ‘tag’ the headers of a mail message with the location of the script that used the Mail() function:

Once you have found and cleaned up the spam source, you can contact us and request a delisting. Note that failing to properly handle the issue when delisting will likely only get your server relisted and make it much harder to delist in the future. As always, if you have general managed services, you can ask for help and myself or another administrator would be glad to track down that nasty spam. Before I sign off, here is another useful link that can check your server’s IP to see if it pops up on any major RBLs: