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.
- Subsidiary MX hosts which are under the same administrative control as the destination host.
- 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?
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.
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?
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.)
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.
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.
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!)