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.
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?
There's a solution we invented down here in Texas involving guns, tars and feathers and truckloads of dynamite. However, physical proximity to the spammer is required, and your market may vary. PM me for details.
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
I had that problem and fixed it by adding sendmail rules to check the host that sent the mail to my MX.
Check here for the script and my general spam article is here.
They mostly seem to be going for the lowest MX on the list, so simply:
The critical thing is that you need to be certain that this tertiary MX is only up when your primary MX is also up. No legitimate mail software will use an MX with a priority of 100 when it can connect to an MX with a priority of 1, so you can be certain that anything the 3rd MX gets is spam. If they're on different boxes, however, a simultaneous outage of the first 2 could cause you to accept then dump legitimate messages.
.sig: file not found
Let's say you have some scheduled downtime of your main server. Let's imagine that the downtime lasts more than four hours. Do you want all the senders to get delay notifications?
What if the downtime is worse, due to a total disk failure, for example. It could easily take more than a day to get back online. Many sender systems won't keep trying for more than 24 hours. Wouldn't it be nice if you could have all incoming mail saved locally? Then you could store it as long as you deem appropriate, rather than depending on the sending sites to do so.