[TAG] Backup MXes considered harmful

[Rick Moen]

----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Mon, 31 Oct 2005 09:00:24 -0800
From: Rick Moen <rick at linuxmafia.com>
To: TAG <tag at lists.linuxgazette.net>
To: Michael Siladi <msiladi at ix.netcom.com>
Cc: Tony Cratz <cratz at hematite.com>,
	Deirdre Saoirse Moen <deirdre at deirdre.net>
Subject: Re: Fwd: Mail delivery failed: returning message to sender

Quoting Michael Siladi (msiladi at ix.netcom.com), writing to Tony Cratz:

> Email to "@westercon60.org" addresses are bouncing.

Specifically, relaying to the westercon60.org domain was refused by mail
exchanger choam.starbug.org .  The latter domain appears to be
administered by Bhroam Mann, Starbug Fanclub, 3168 New Jersey Ave, 
San Jose, CA.  Tel. (408) 369-8581, hawkwind at RAHUL.NET.

Your copy of Eudora for Win32 passed your outbound mail to a mail
exchanger for Earthlink / Netcom, hostname
smtpauth04.mail.atl.earthlink.net.  That mail host then attempted to
redelivery.  The first step is to look up the destination domain's mail
exchangers (MXes).  We can simulate that step using the "dig" command:

  bash-2.05b$ dig -t mx westercon60.org +short
  10 wwind.hematite.com.
  20 choam.starbug.org.
  20 blackstone.dgoldman.com.

The "20" shown for the second and third MX indicates that they are lower
priority than Tony's wwind.hematite.com host.  That means that they will
be used only as backups in case the primary MX cannot be reached.  These
are referred to generically as "backup MXes".  They spool up all such
in-transit mail during primary-MX downtime, and then later redeliver it
to the primary MX as the final destination.

I personally gave up on the idea of backup MXes several years ago, and
this incident illustrates one of two reasons why:  Inevitably, you find
out, at the worst possible time (say, while your primary MX is suffering
downtime) that the backup MX has been configured by its admin to refuse
or mishandle your mail.  You complain, the other guy mumbles a bit and
(with luck) fixes something (while you cool your heels and lose mail),
and the cycle repeats.

You might wonder:  What degree of protection do backup MXes provide?  It
must be intended as a valuable fallback, right?  The answer is, yes, _a_
fallback, but not a valuable one:  In the absence of backup MXes, if
your primary MX is offline but your DNS is still functional, then mail 
deliveries from various places will keep retrying for four days before 
bounces start.  Thus, you have four days to bring your primary MX or a
replacement machine back online somewhere in the world.  Tony or any
other sysadmin can do that in four _hours_.  Four _days_ is an incredibly 
luxurious -- nay, excessive -- safety margin.  Why risk backup MXes
flaking out at times when you most need them, when you have so little
use for their supposed advantages?

The Rubicon for me was when my own primary MX was offline for half an
hour during rebuild, and I found that the two backup MXes operated for
my benefit by alleged friends enthusiastically carped that diem by
rejecting by refusing to "relay" (i.e., accept for redelivery) several
thousand of my my mails.  "Iacta alea est, dammit", I muttered, and 
expunged those MX RRs from my domain permanently and with extreme
prejudice:  "Ceterum censeo, MX delenda est."

In short, my own strong preference is _no_ backup MXes, but multiply
redundant DNS nameservice.  And that would be how I would solve this
problem.


BTW:  The _other_ problem with backup MXes relates to spammers:  The
spammers discovered a few years back that they could infiltrate more
spam into people's mail-handling systems if they _deliberately_ dropped
off spam at people's highest-numbered (lowest priority) MXes, because
lesser-used MXes most often have lax anti-spam regimes, and because
those MXes will then perform on the spammer's behalf the hard work
of hammering the spam into the primary.


----- End forwarded message -----