Information Systems Services
Information Systems & Services (ISS) - mx backups
Information Systems & Services (ISS)
Spam - MX Backups
We have removed our dependency on external MX Backups.
We are in agreement with Jim Seymour's comments in his postfix anti-UCE cheat sheet
"When There's No Point To A Secondary MX This doesn't relate directly to anti-UCE measures, per se, but the question often comes up "How do I reject spam relayed via my secondary MX?" - when the secondary MX isn't one under the user's control. Admins often configure things to specify their ISP's mail server, or some other mail server not under their control, as their domain's secondary MX. One imagines the thinking is that this secondary MX will collect email destined for their domain if the primary MX is down or unreachable, and forward it on when the primary again becomes available. There's really no advantage to be gained by specifying such a host as a secondary MX, and, in fact, there is a distinct disadvantage to doing so. A backup MX that isn't under your control, where you can enforce the same anti-UCE restrictions as you do on your primary MX, only provides a way for spammers to get around your anti-UCE restrictions. And spammers *will* exploit it. Anti-UCE HELO and client checks can't be enforced at all on email relayed from such a secondary MX. Sender, header and body checks *will* result in rejects but, since the email has already been accepted on your domain's behalf by the secondary MX, it will be bounced by your secondary MX--probably to a spoofed, innocent 3rd party. (At which point, some argue, you become part of the problem, rather than part of the solution.) Most any modern MTA will queue email for delivery for 3-5 days anyway, so a backup MX that only ends-up delivering to your primary MX doesn't do anything actually useful for you. The only time a secondary MX makes sense is if it's a mail server under *your* control, where you can enforce anti-UCE rules consistent between it and your primary MX, it's on an independent network connection, and that can relay incoming email via an independent, usually private, connection."