When There's No Point To A Secondary MX

    (Excerpted from part of http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt)

    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 are two distinct
    disadvantages 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.

    The second disadvantage is that recipient, sender, header and body
    checks, and any other content checks (e.g.: anti-virus filters) at
    your mail server, on email relayed from the secondary MX, *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 this
    point you become part of the Internet's problem: A back-scatter
    generator.

    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 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.  E.g. (simplified):

				   lan/wan
	Internet --- primary MX -----------+
		      gateway              | lan
					   +----- internal mail
					   |         server
	Internet --- secondary MX ---------+
		      gateway      lan/wan

    Or perhaps:

		     Internet --- primary MX and mail server ---- lan
					      ^
					      |
					      |
	Internet --- secondary MX ------------+
				      wan