Fallback MX Considered Harmful
==============================

The practice of listing the SMTP relay hosts of your ISP as "fallback
MX" is widespread and long standing, but I believe that for anyone
making serious use of Internet mail it is now outdated.

I define fallback MX as: listing in the MX records for a domain, at a
lower preference than the destination MX host, a host or hosts which do
no special routing of mail for that domain, and which are under
different administrative control than the destination MX host.

For example, here are some DNS records that illustrate the classic
fallback MX scenario::

    example.com.    10 mailhost.example.com.
                    20 relay.isp.example.net.

The following two cases do not fall under the above definition of
fallback MX, and are not discussed in this memo.

1. Subsidiary MX hosts which are under the same administrative control
   as the destination host.

2. Mail to destination hosts which are only intermittently connected to
   the Internet (e.g. a dialup PSTN or ISDN line).

Pros: what does fallback MX buy you?
------------------------------------

1. The traditional justification for fallback MX is so that if the
   destination MX host loses contact with the world for a period of
   time, there is only a single host (the fallback MX host) with mail
   queued for it when it returns, rather than the whole world hammering
   on its door.

   This may have been a good argument a few years ago when mail---and
   connectivity in general---were sidelines for most businesses, and
   could disappear for days at a time. But these days most people take
   mail a bit more seriously and down time can reasonably be expected
   not to last longer than a few hours.

   In the case of the occasional major disaster, when a site does go
   down for days, there's likely to be a need for emergency DNS
   reconfiguration anyway, so the MX records can be twiddled at this
   point.

2. There may be strange situations when, although the destination MX
   host is up and running, delivery to it is not possible, but delivery
   to the fallback MX host is possible.

   For example, in the bad old days of NSFnet, hosts that were on or
   behind NSFnet couldn't reach hosts of PIPEX customers who hadn't
   successfully applied for "permission to connect", but they could
   reach the PIPEX mail relays. (PIPEX was a UK ISP in the early 1990s.)
   This reason has gone away, of course, and these days I can't see
   anything to be gained at the IP level from a fallback MX in the same
   AS as you. I believe (and hope) that global IP connectivity is here
   to stay. (AS = autonomous system, a collection of hosts that share
   the same IP routing policy. Generally, you will be in the AS of your
   ISP.)

   Higher up the protocol stack, I have seen one or two cases where
   broken implementations of the SMTP protocol made direct communication
   impossible, but a forgiving relay could accept and send on the
   message.  This is unlikely to be a problem if you're running a decent
   SMTP server.

Cons: what are the dangers of fallback MX?
------------------------------------------

1. **The fallback MX host may mangle or even reject the message.**

   If I am running a mail server which implements 8BITMIME, and can
   thereby handle 8bit data in a predictable manner, I don't want my
   mail to pass through a server that doesn't do 8BITMIME. For example,
   if the original sending host is running a recent version of sendmail,
   and the fallback MX host doesn't support 8BITMIME, sendmail will
   encode the message using MIME's quoted-printable encoding before
   sending it to the fallback MX host.

   There are similar opportunities for harmful mangling throughout the
   RFC 822 and SMTP protocol layers. I have seen at least one report of
   an ISP's mail system erroneously rewriting header addresses in such a
   way as to make the mail unreplyable. (In this particular case, it
   sounds as though the ISP was acting as a mail drop for a dialup user,
   rather than fallback MX. However, it is highly likely that they would
   have performed the same bogus rewriting on any mail relayed in the
   latter capacity.)

2. **The fallback MX host may delay or even lose the message.**

   To put it another way, they damage the point to point elegance of the
   Internet mail model, moving it a step closer to the dreaded store and
   forward model espoused by such moribund systems as X.400 or UUCP.  I
   don't want my sensitive or important messages to spend time on more
   spool disks than they absolutely have to.

3. **They introduce non-determinism**

   These problems are exacerbated by only appearing intermittently.

In summary, I believe that on the modern Internet, if you're running a
decent mail system, and you care enough about mail to be worrying about
fallback MX, you're better off without it.

Toby Goodwin

History
-------

I wrote this piece some time around 1996 - its vintage is attested to by the
concept of NSFnet "permission to connect", and also the complete lack of any
mention of spam! I still completely endorse the opinions.

(I actually thought I'd lost this article for some time; certainly I was
unable to find it. But the wondrous `Wayback Machine`_ had kept a copy.
Thank you!)

.. _wayback machine: http://www.archive.org/