January 3rd, 2014, 02:17 PM
Is there a way to find out the source of a comprised mail server?
For the past few months, we have been added & removed to email blacklists / spamlists. We had gone through the first few times and submitted manual removal requests, and everything was okay for a couple days / weeks, then we would randomly pop back up on spamlists (we use MXToolbox to scan).
We don't send any unsolicited email, and as of recently we haven't been using our emails at all because they often land in client's spam boxes, so it's very unreliable. We've just been using our gmail.
We have a dedicated server that has about 10 other sites (of ours) that we're sharing it with. They are not really active sites, possibly old WordPress installs or whatever. We only use the one main site, which is the one we're having email issues with.
I've contacted our host to inquire about what's going on, but they suggested we get something like SendGrid.com to send out our emails. That's all fine and well, however I believe there's a deeper problem considering that we're not sending any unsolicited emails and we're still being added to spamlists.
Is it possible that one of the sites that shares the dedi-server OR the main site in question has been compromised and is sending out mail on our behalf? And to follow on that, is there a way to track down where the source of this problem is originating so we could patch up the exploit?
I read the sticky, however I only know that our server is Linux and we have Direct Admin.
January 3rd, 2014, 10:50 PM
Mail Servers are usually blocked according to originating IP address, simply because that is about the only thing that cannot be spoofed. Spammers very seldom use the actual use their real domain name. If your server allows authenticated login (vs permitted IP address only), in all likely hood one or more of your accounts has been hacked, and a spammer is abusing your server.
Hacking accounts with weak passwords is not all that difficult. We do not even have a real SMTP server, and yet it sees all kinds of AUTH LOGIN attempts. TLS/SSL does not protect against this kind of activity. The only way I know of to protect against this is to monitor the log files for unusual activity and change the passwords on suspicious accounts.