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
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
- 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.
- 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.
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
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
listname: person1, person2, person3, listname-archive
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
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.
- A patch to exim (which only needs to be
installed 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.
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.