Stopping Spammers Who Exploit Secondary MX?
drteknikal asks: "I'm the admin for a small law firm. We use our ISP as our secondary mx. We are receiving spam from our secondary mx even when our primary has been continually available. We suspect that spammers are routing to our secondary MX to bypass the DNS-based spam filtering on our primary. After examining some of the traffic, our ISP agrees. Neither of us sees an immediate solution, given the purpose and function of secondary MX. They already restrict relaying to hosts on their network. Has anyone else seen this? Does anyone have suggestions on how an ISP could secure their mail exchangers without interfering with the functionality required to function as secondary MX for an external domain?"
Is there any reason why the ISP can't set up some sort of SPAM filtering on their end?
Also, why not just set up the ISP's server as a backup server only? That way, you access your e-mail through the main server, which would make the mail go through your SPAM rules, right?
Karma: Chevy Kavalierma.
I have seen a bunch of my spam at work come in from the secondary MX. Until this moment I'd assumed it was due to our primary MX being down, or due to the spammer's mail client picking the "closer" MX (our MXs are widely spaced geographically and in IP space).
However, the solution seems simple enough IF you control the secondary MX - install the same level of anti-spamming on the secondary MX as you have on the primary MX.
Of course, if you don't control the secondary MX.....
www.eFax.com are spammers
One solution would be to let the backup forward the mails normally to the primary MX, but our ISP can't do this; once the mail is in the POP account, it's gone from the mail queue...
Karma: none (due to not believing in reincarnation)
I noticed the same thing. While both of the main servers had the same level of spam filtering, I found it odd that the secondary was seeing a lot more spam. So as an experiment I added a thrid MX, the first two are of priority 0 and 10. The third I made 100 (not that it really matters). On this third server I set up even stricter anti-spam rules. The amount of spam fell of very quickly after that. The spammers would go for the trap. I would say that over 90% of the e-mail to that server is spam. I have almost considered just making it a black hole. But it does see a little valid traffic, and there is a chance that both of our main servers could be offline at the same time.
Anmother trick that I'm starting to see pop up is control characters in the headers, so spamd/spamc get a screwed up byte count and allow the message through. I'm not running the latest version of SpamAssassin yet, though, so this may have been fixed already...
The core of your problem is the fact that your ISP is accepting SMTP traffic for you and does not support the same policies as your own mail server supports. If you want to get rid of the SPAM coming from your ISP, you need to be able to implement policies on the secondary MX server.
I would suggest one of the following:
- Collocation: Put one of your own servers at your ISP to which you have full control over
- In-house: Don't use your ISP as a secondary MX, set up a second server at your site instead (this still protects against primary server failure, but not against ISP connectivity problems)
- Paranoid: Implement the filters on mail coming in from the ISP. Depending on your filtering software, this might be a little more tricky but it will work.
With regard to the Paranoid option above, it should just be a matter of checking ALL of the Received headers instead of just the last one. Usually spammers can (and do) forge all of the Received headers except for the last one -- which they can't because your server adds it. In the case of mail received by your ISP, the last two Received headers are guaranteed to be valid.Checking all of the Received headers against the SPAM database would do the trick.
eg:
mail.myserver.net pri 10
mailbackup.myisp.com pri 20
mail.myserver.net pri 30
Works perfect for now. But some day the spammers will adopt to this too ....
RFC1925