Last week one of our customers hired a new webmaster. The new webmaster noticed that one of the dedicated IP addresses assigned to his virtual private server was listed on ips.backscatterer.org.
Of course, the first thing you probably do when you find out that you are blacklisted is: panic!
The train of thoughts associated with this is probably close to this:
“Oh no, I have been blacklisted.”
“Someone must have sent spam from my website.”
“I didn’t send spam and none of my users would!”
“The spam was send without our approval.”
“Someone must have hacked the server.”
Well, in most cases there is still some truth about this. A lot of servers are poorly managed (if someone cares at all) and a lot of the spam that knocks on our doors comes from hijacked webservers.
Not in this case. The customer was apparently not aware that you can get blacklisted with ips.backscatterer.org for running an auto responder on just one of your email accounts.
The problem with this is that auto responders are very popular and widely used in corporate environments. If we follow Google’s KNOL, we might be convinced that they are cool. So since there are a lot of auto responders out there, backscatterer.org is quite busy in blacklisting a lot of IP ranges of service providers who allow their users to have auto responders. As I write this blog post, 154151 IP addresses have been blacklisted by their service. You might wonder why backscatterer.org blocks auto responders in the first place. Well, they try to explain it on their website and whilst they have a few good points, I will leave it up to you to make up your mind on whether auto responders are good for your domain’s users or not. Aside from their decision to block servers using auto responders, this is apparently a lucrative venture for the company behind backscatterer.org. Once blacklisted, you either need to wait 4 weeks to be de-listed or pay a charge of € 75 (a little bit above $100) for an expedited delisting. If you decide that you want to pay, you may wonder who you’re going to do business with. One of the people behind backscatterer.org identifies himself as Claus von Wolfhausen, an apparently highly controversial figure.
Anyway, my point is that our customer got blacklisted for allowing his users to use auto responders, but due to a panic attack, he thought his server was compromised. It’s never a good idea to act when you are panicking.
So our customer logged in to his server and found the /etc/relayhosts file. He found IP addresses from third party service providers in the file and came to the conclusion that a hacker must have added the IP addresses to the file so that he could relay messages through his VPS.
Whilst this might be a viable conclusion, our customer didn’t do further research to make his case. It was so easy though:
The relayhosts file’s IP addresses are automatically added by antirelayd, a cpanel dameon. It checks /var/log/maillog for pop3 or imap logins and keeps track of valid ones for use with smtp relaying.
POP before SMTP or SMTP after POP is a method of authorization that allows users to send e-mail from any location, as long as they can demonstrably also fetch their mail from the same place.
The IPs in the relayhosts file are automatically removed from the list after a while.
I looked up the suspicious IP addresses he had listed in /var/log/maillog and suggested that he might want to disable POP before SMTP after he gave his users enough time to make the required changes in their clients.
By the way, if you have come to this page because you were looking for a way to disable antirelayd, here we go:
You can either disable it in the Service Configuration section under Service Manager of WHM or by running the following command via shell:
/usr/local/cpanel/bin/tailwatchd --disable=Cpanel::TailWatch::Antirelayd
If you want to double check in shell that it has been disabled, try this:
cat /usr/local/cpanel/logs/tailwatchd_log|grep Antirelay
Watch out for a line that says:
Cpanel::TailWatch::Antirelayd was successfully disabled
Alternatively, you can check the status of the tailwachd process as follows:
/usr/local/cpanel/bin/tailwatchd --status