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:

Overview of GNU mail setup

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

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:

listname: person1, person2, person3, /com/archive/listname

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

listname: person1, person2, person3, listname-archive
listname-archive: /com/archive/listname

then the secondary can potentially deliver the message to person1, person2, and person3 (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 listname-archive.

Implementation details

Below are the details of the implementation. A few details of what was actually running on the GNU mail servers have been removed from these copies that aren't needed to describe how the overall secondary mail concept works.

Failure Modes

The obvious failure mode is that if data doesn't get propagated 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.