A traditional secondary mail server

It is not uncommon for a secondary mail server to do simple relaying, with no knowlege of how to deliver mail other than to send it to the primary mail server when the primary mail server becomes available again.

While this works, my experience has been that this is of marginal value, for the following reasons:

• Mail doesn't get to its ultimate destination until the primary mail server comes back up, which means that, in this respect, it isn't especially different from not having a secondary mail server at all. Having a secondary mail server in this sense does mean that you can have one machine that controls the warning and bounce timeouts for everyone sending you mail, but that's only of marginal value.
• This has very unfortunate properties with respect to spam. Spam is generally sent with an invalid return address, so the postmaster of the secondary mail server often ends up getting the bounces if a spammer tries to send mail to an address which no longer exists on the primary mail server. I've also seen problems with certain anti-spam measures being slightly different between sendmail and exim with a primary server running exim and a secondary running sendmail, which caused the postmaster of the secondary to get the spam.

Overview of GNU mail setup

For gnu.org, I set up something a bit more sophisticated. Here are some details:

• At GNU, the /etc/aliases file has historically been stored in /com/mailer/aliases, and has been used instead of .forward, as well as being used for aliases for mailing lists, bug tracking programs, etc. Small internal mailing lists are handled directly in the aliases file without the aid of external programs, sometimes using :include: files, sometimes not. Large externally visible lists are generally handled by pipes involving GNU mailman.
• Lots of GNU users have their mail forwarded to off-site machines. For example, the sysadmin types tend to run their own personal mail servers. Everyone except the FSF staff gets their internet connectivity from somewhere other than the FSF, and those organizations usually provide email boxes to their users as well, so many people find it easiest to just forward their GNU mail to their mailbox elsewhere.
• Setting up redundancy for things that need to be on a single filesystem is hard. Having redundant mail delivery where the mail server doesn't need to write to files is much easier to do right, if all you need to do is mirror files that change infrequently.
• For user mailboxes and archive files, the mail just gets punted to the primary mail server; for deliveries that just involve simple SMTP forwarding, the secondary does all the work without the primary ever touching the mail.
• Mail deliveries that involve pipes are simply punted to the primary. It's probably possible to have the secondary doing more processing, but getting that right is tricky, and having mail always get delivered reliably is more important than having mail not wait for the primary to come back up. (I've also tended to stay out of maintaining first the smartlist and later the mailman installation for GNU, and it occasionally breaks from time to time when people are trying to do an upgrade, even without the complexity introduced by a secondary mail server.)
• GNU happens to support ~/.procmailrc, but we have things configured so that people who have a ~/.procmailrc simply have their mail punted to the primary by the secondary, rather than trying to screw up something more complex.

It's important to write the aliases file to be sensitive to the way things can be expressed in smtp aliases. For example, if you write this:

trolls: adb, nemo, pk, zarkon, /com/archive/trolls

then the secondary will have no way to tell the primary mail server to deliver a message to only /com/archive/trolls, so it will just punt the entire delivery process to the primary. However, if you write:

trolls: adb, nemo, pk, zarkon, trolls-archive
trolls-archive: /com/archive/trolls

then the secondary can potentially deliver the message to adb, nemo, pk, and zarkon (assuming the availability of aliases elsewhere that tell it how to deliver to these people), and it can send a copy of the message to the primary, asking the primary to deliver it to trolls-archive.

Implementation details

• A patch to exim (which needs to be installed only on the secondary, although having it on the primary should do no harm) adds a flag called transport_pfr; pfr is the acronymn used in the exim source code for pipe/file/autoreply deliveries. Ordinarily, if you have a transport = line in a director section, that transport is used for everything handled by that director; with this patch, if you also have a line that says transport_pfr = true in the config for the directory, the transport is only used if something the director wanted to send to requires the use of a pipe/file/autoreply.
• Shell code called by cron hourly on the primary pushes all the files needed by the secondary. (This does not push the exim.conf, but it pushes nearly everything else.)
• The secondary mail server needs an exim.conf file something like the one referenced by this link.

Failure Modes

The obvious failure mode is that if data doesn't get propogated to the secondary mail server, mail delivery happens incorrectly.

This has the effect that if, say, you're pushing the data hourly, and someone creates a new alias, and mail happens to go through the secondary mail server, the mail will bounce because the alias isn't there. This also has the effect that if updates stop happening for some reason, the newer alias data won't be on the secondary, and since the secondary normally won't get used unless the primary is down, you may not notice until the primary happens to break.

It's important to keep these problems in mind and plan how to minimize the risks when deploying a scheme like this.