-- backupmx.txt, last change 2001-01-31 --

So you want to set up a backup mail server to add reliability? 
You need it because mail will get lost as soon as your primary mail
server is down?

Let me tell you a fact: you don't need it. 
Yes, i'm serious. I work at an ISP for more than three years, and
i've seen _far_ more trouble due to the existance of a backup 
mail server than due to it's nonexistance.


Myth 1: Ifall my mail server is down then messages will bounce!

  Think about it: The backup relay only protects against outages of
  the primary mail server.
  What happens in the far more likely case of a network outage 
  _somewhere_?
  Yes, the sending mail server has to retry sending. All mail servers
  do. They usually try to do that for about a week or so.
 

Myth 2: uucp needs a backup MX.
  (replace uucp by "any other strange mail transfer system not based
  on SMTP" as you please. Use "fido", "mausnet", ...)

  Get real. UUCP doesn't even know about MX records. UUCP isn't even
  used for email anymore. Y2K has passed!

  In any case: you don't need backup MX records for that, just the
  primary.


Myth 3: a backup mail server protects against misconfigurations.
  
  No. A misconfigured mail server will happily answer all requests
  with the wrong answers. The backup server will not even be asked.

  The only protection against misconfiguration is correct 
  configuration.


The facts:

Fact 1: backup mail relays are often misconfigured.
  
  In these days, where spam poses a serious problem for communication,
  most to all ISPs have closed their mail servers. Those servers need
  to be explicitly told that they shall relay for a certain host or
  domain. If they do not get told, or the administration forgets to 
  configure their servers, or screw up the configuration  (a typo
  is enough), then they will happily tell a sending server that
  they will not relay, and will cause that sending server to bounce
  the message.
  Which is exactly what you didn't want, right?

  By "often" i mean "often". It's not really a rare case.
  I'd never trust an ISP to get that right. We certainly screwed
  it up quite a lot of times: We've often failed to keep DNS MX records 
  and mail server configuration synchronized, and customers changed MX
  records without telling us. 
  I guess that our current configuration is wrong in about 2 to 5
  percent of the DNS zones.  (that was in 1999. In 2001 i believe
  it to be worse, int that at _least_ in 5 to 10 percent of the
  zones something is wrong)


Fact 2: backup mail server often try to deliver all queued messages at once.
  
  In case of a longer outage it may happen the backup relay will 
  try to deliver all messages at once, filling up the line and
  possibly causing new mail to be delivered later due to load
  limits on the primary mail server. 
  Sendmail tries to do this. It's a pain since in the next few hours
  after a network outage the line has more load then usual because
  people try to get their work done. 
  Misbehaving backup mail servers can easily render a small line
  completely useless. I've seen that happening.


Fact 3: Different policies cause message loss or grieve.

  Suppose your mail server has a spam policy, like not accepting
  mail originating from microsoft, uunet.net or hotmail. Or whatever.
  Do you think that your ISP has the same policy? Right, he hasn't.

  If the ISPs policy is more strict than yours then you end up
  losing mail which you normally would have accepted. No loss? It's
  spam anyway? No. ORBS, an often used open relay blocking system,
  is well known for not only catching spam.

  If, on the other hand, your ISPs policy is not as strict as yours
  then he will accept mail you would not have accepted. This way
  either you will get more mail than expected, because the spam
  filter is based on the IP address of the sending host, or the
  ISP will have to deal with bounces. (see fact 4)


Fact 4: Your ISPs postmaster is more careless than you.

  As a matter of fact he is likely to get "enough" email. Nobody
  who deals with hundreds of bounced mails will do that careful.
  Especially since most bounces are spam.


Fact 5: my mail server will be down for 10 days and i need a backup.

  Of course. In this case. For outages which may last 3 days or more
  (to retry for only 5 days is a not too uncommon configuration of
  mail server. The 2 days less is a safety margin).


Fact 6: my internet connection is often down, and i want to use
  ETRN / autoturn / serialmail on the backup relay.
  
  Ok. There's clearly a benefit in that case.
  But what about a reliable internet connection?
  And you don't need a backup MX in every case, but this depends
  on the technology in use (try qmail with serialmail).


Fact 7: Do you trust your backup relays?

  Do you _really_ want it's administration to be able to read all 
  your mails? To forge email?
  [Think about hackers, too]


Fact 8: Things change.
  
  From the ISP point of view: over the years we added a thousand
  or more domains and hosts to our "relaying allowed" database.
  We did that if a customer asked us about it.

  Well, i don't remember a _single_ case when the customer told
  us "delete that record, the domain left". Which is quite
  unfortunate. This is not too bad in most cases, as no MX
  records point to the machine anymore.

  On thing which we consider to not be _too_ funny is this:
  The (primary) mail server of a domain moves to somewhere
  outside of out network. Mails going through the backup
  relay then enter our network and leave it some time later,
  costing us money twice, and we can't even send a bill to anyone
  (we could, but that wouldn't be worth the pain, and there's an
  easier solution: Not doing backup relays anymore).