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."