By far the most popular set of articles I have written is my Raspberry Pi Email Server tutorial. Clearly, there are plenty of people who don't like relying on freemail providers like Yahoo, Outlook and Gmail for a variety of privacy and security reasons. However, there is one major drawback of hosting your own email server: if your server is taken offline for maintenance, or your internet connection is interrupted, then incoming email can not be delivered and may bounce. This tutorial will describe how to set up another server to act as an MX backup. The backup server will be hosted on a separate internet connection with a different WAN IP address, and have a lower priority than your primary mail server in your Mail Exchanger (MX) DNS record. When your primary server is offline other MTAs will send email to the backup instead, and the backup will hold them until your primary mail server comes back online, and then deliver them. No more bounced emails. The biggest challenge when setting up a backup MX is convincing a friend or family member to allow you to run a RasPi or some other server on their network; the rest of the setup is a breeze compared to the full mail server installation described in the main tutorial, because fewer components are required (just Postfix). This guide is written for Debian and its derivatives (Raspbian, Ubuntu etc.) but since a basic postfix installation is more or less the same across different distributions you should be able to use it for any distro. My backup server runs openSUSE.

Postfix

Postfix is the MTA. It is responsible for accepting incoming mail from other servers on the internet, sending mail to other servers on the internet, and delivering mail to your local mailbox. For an MX backup, it's pretty much all you need.

Installation

First, install Postfix. For Debian derivatives:

sudo apt-get update

sudo apt-get install postfix

Or for openSUSE:

sudo zypper refresh

sudo zypper in postfix

You may see a configuration wizard asking you what kind of setup you require. Choose "internet site", and when asked for a domain name, enter backup.yourdomain.com where "yourdomain.com" is a domain you own. If you don't see this, don't worry - all the options can be changed in /etc/postfix/main.cf later.

Configuration

The majority of the Postfix configuration can be found in two files: /etc/postfix/master.cf and /etc/postfix/main.cf. The master.cf file defines all of the different processes, and the main.cf is a place to put other parameters. You shouldn't have to edit master.cf, since it already defines the processes we need.

Hostname

The first thing to do is open main.cf and make sure your hostname is correct. You should see:

myhostname = backup.yourdomain.com

This hostname is used by postfix when it connects to other servers on the internet, in the HELO command. If it isn't correct, edit it. The myorigin parameter should be set to the same domain name:

myorigin = $myhostname

myorigin is used as the domain part for locally posted mail (for example, if the fail2ban process sends an email from this host, the FROM email address will show fail2ban@backup.yourdomain.com). The next parameter to check is mydestination - this is a list of domains that the server is the final destination for. Your root domain should not appear in this list, or Postfix won't forward any mail to your primary mail server! However, you might find it handy to be able to send email to this host sometimes, so backup.yourdomain.com should be in the list. Here's what it should look like:

mydestination = backup.yourdomain.com, hostname.lan, localhost.lan, localhost

The middle two items in the list will be filled in based on the domain name of the local network (e.g. .local or .lan for most routers, or .home for BT home hubs) and the hostname of the server (e.g. raspberrypi).

Allow relaying for your domain

Finally, we need to add your root domain to the list of domains that this server will relay email for.

relay_domains = yourdomain.com

For the avoidance of doubt, you should leave relayhost blank, e.g:

relayhost=

This parameter is sometimes used to define a host that is used to forward all mail sent from the system (excluding local mail). For example, some people might have to set their ISP's email server as the relayhost for their primary server if the ISP blocks outgoing mail on port 25, or if they have a dynamic IP address and outgoing mail often ends up in spam folders because of poor IP reputation. You shouldn't need this for a backup MX - if port 25 is blocked you can just configure postfix to deliver to your primary server using a different port (e.g. 465), since the backup server will only ever have to send outgoing mail to your primary server. I don't think it would even be possible to set up a backup MX server that uses a relayhost, because the backup server would see delivery to the relayhost as successfully forwarding the email, regardless of whether the primary mail server is up or not.

Tell Postfix your WAN IP

If your server is behind a firewall and not connected directly to the internet, then it does not know its own WAN IP address. When your primary mailserver is offline, postfix will receive email for yourdomain.com and do an MX lookup to figure out where to send it. To prevent it from trying to send the email to itself, you need to specify the WAN IP address of the firewall:

proxy_interfaces = 1.2.3.4

If your backup MX is on a dynamic IP address, then you can use a hostname instead of an IP address:

proxy_interfaces = backup.yourdomain.com

If you miss this step, you'll see messages like this in your log file:

Dec 27 20:40:55 NUC postfix/smtp[7904]: CEAB4335: to=, relay=backup.samhobbs.co.uk[86.130.165.77]:25, delay=0.37, delays=0.1/0.06/0.21/0, dsn=4.4.6, status=deferred (mail for samhobbs.co.uk loops back to myself)

Use Maildir format for locally delivered mail

The final change to make is just personal preference. The following parameter will store mail delivered locally in Maildir format in the user's home folder (by default, postfix stores mailboxes in /var/mail):

home_mailbox = Maildir/

The following command will create the Maildir structure in your home directory, and set private file permissions so that only you can read the messages. Do this for any system users on the backup server that you expect to receive email:

mkdir -p ~/Maildir/{cur,new,tmp}
chmod 700 Maildir

Spam Control

Spam control is especially important for MX backups, because spammers will often deliberately connect to hosts with lower priorities in the MX record in the hope that they have more relaxed configurations.

Restriction lists

One method of controlling spam is the use of restriction lists. If you did the raspberry pi email server tutorial, you will be familiar with these. You can leave most of them at their default (empty) values, e.g:

smtpd_client_restrictions = 
smtpd_sender_restrictions = 

However, you can still cut down on spam by requiring clients to use a valid HELO hostname when they connect. The following parameters require the client to HELO before it can start sending messages, and check that the hostname is a fully qualified domain name for a real domain that has a DNS A or MX record.

smtpd_helo_required = yes

smtpd_helo_restrictions =
        permit_mynetworks,
        reject_invalid_helo_hostname,
        reject_non_fqdn_helo_hostname,
        reject_unknown_helo_hostname

Since version 2.10, postfix has had a separate list for relay restrictions to reduce the risk of accidentally creating a permissive restriction list ( previously, relay and spam blocking policies were combined under smtpd_recipient_restrictions). If the empty recipient restrictions list looks strange to you, it's probably because the rules have been moved to the relay restrictions:

smtpd_recipient_restrictions = 

smtpd_relay_restrictions =
        permit_mynetworks,
        reject_unauth_destination

Helo restrictions on the primary server

If you used my raspberry pi email server tutorial to set up your primary server, you probably have something like this in your helo restrictions:

smtpd_helo_required = yes

smtpd_helo_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_invalid_helo_hostname,
        reject_non_fqdn_helo_hostname,
        reject_unknown_helo_hostname,
        check_helo_access hash:/etc/postfix/helo_access

And in /etc/postfix/helo_access:

yourdomain.com          REJECT          Get lost - you're lying about who you are

The problem with this is that by default yourdomain.com will match subdomains like backup.yourdomain.com too, because of this line in the default postfix configuration:

parent_domain_matches_subdomains = debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients,relay_domains,smtpd_access_maps

You can change this behaviour so that parent domains will only match subdomains if they are preceeded with a period ( .yourdomain.com) by explicitly setting this parameter to empty in main.cf on the primary server, or by removing smtpd_access_maps from the list. I chose to clear the list completely:

parent_domain_matches_subdomains =

Require valid users

As things stand, any email submitted to your backup server addressed to a domain in relay_domains will be accepted, and the backup server will attempt to deliver it to the primary server. This is open to abuse by bots that send email to many addresses at once that may not exist (foo@yourdomain.com) causing the mail queue on the backup MX to fill up, and resources to be wasted on both your backup and primary mail servers as repeated connection attempts are made. The solution to the problem is to provide the backup with a list of valid users on the main server, so that it can reject email to addresses that don't exist. This parameter specifies the file to use:

relay_recipient_maps = hash:/etc/postfix/relay_recipients

You can then create the file:

sudo nano /etc/postfix/relay_recipients

... and populate it like this with any addresses you want to enable forwarding for:

you@yourdomain.com OK
root@yourdomain.com OK
webmaster@yourdomain.com OK
postmaster@yourdomain.com OK

Then use the postmap command to create a database out of the file:

sudo postmap /etc/postfix/relay_recipients

...which will create /etc/postfix/relay_recipients.db. If you make further changes to the file, you must postmap it again. Now Postfix will only relay mail for those addresses, and reject email for users that do not exist on the primary server.

Spamassassin on the MX backup

In the current configuration, the main server has to process every incoming message using spamassassin, which is quite a CPU intensive activity. If your MX backup is a lower powered machine, this may be what you want, but it may also be advantageous to filter emails before relaying them from the backup server, to take some load off your primary server. It should be possible to process the email with spamassassin, and drop it if the spam score exceeds a threshold. I haven't figured out how to set this up yet, but I'm planning on adding instructions in the future.

TLS

This section is about enabling transport encryption, for both incoming messages and outgoing messages to your primary email server. These two parameters require TLS for outgoing messages, and write information about encryption to the mail log (or journal, if you're using systemd):

smtp_tls_security_level = encrypt
smtp_tls_loglevel = 1

These two parameters enable TLS for incoming messages and write similar log messages:

smtpd_use_tls = yes
smtpd_tls_loglevel = 1

With this configuration TLS is not required for incoming messages, just enabled. Outgoing mesages must be sent with TLS. You must also make sure that these four parameters point to valid certificates & key files:

smtp_tls_cert_file = /etc/ssl/certs/backup.yourdomain.com.crt
smtp_tls_key_file = /etc/ssl/private/backup.yourdomain.com.key
smtpd_tls_cert_file = /etc/ssl/certs/backup.yourdomain.com.crt
smtpd_tls_key_file = /etc/ssl/private/backup.yourdomain.com.key

If you don't have a certificate, check out my CAcert tutorial for a free certificate, and optionally use my tutorial explaining the additional steps to set up a commercial certificate if you pay to get one signed by a different certificate authority.

DNS records for yourdomain.com

An MX record is a list of one or more hosts able to receive email for a domain, where each item in the list has a priority. MTAs are supposed to fetch the list, and work down until they find a host that they can connect to, starting with the host with the highest priority (lowest number). This means that if you add backup.yourdomain.com to the MX record for yourdomain.com with a lower priority than your primary mail server, other mail servers will use it when your primary mail server is offline. Your backup server will also need a DNS A record to map backup.yourdomain.com to its WAN IP address. If you want the backup to be the final destination for email addressed to foo@backup.yourdomain.com as well as relaying mail to foo@yourdomain.com, you should create an MX record for backup.yourdomain.com too. Here's my setup (with namecheap): The dig command can be used to retrieve DNS records, e.g. to fetch an MX record:

sam@NUC:~$ dig samhobbs.co.uk MX

; <<>> DiG 9.9.6-P1 <<>> samhobbs.co.uk MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37440
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;samhobbs.co.uk.                        IN      MX

;; ANSWER SECTION:
samhobbs.co.uk.         600     IN      MX      20 backup.samhobbs.co.uk.
samhobbs.co.uk.         600     IN      MX      10 samhobbs.co.uk.

;; ADDITIONAL SECTION:
samhobbs.co.uk.         600     IN      A       195.166.151.235
backup.samhobbs.co.uk.  64      IN      A       109.150.240.159

;; Query time: 18 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Sat Jan 23 23:55:47 GMT 2016
;; MSG SIZE  rcvd: 114

For more information about DNS records, see my DNS tutorial. If you need to set up dynamic DNS for your backup server, you can use my ddclient tutorial to set it up without relying on the router of whoever has kindly let you host your backup server on their network.

Choice of Nameservers

It's important that your two email servers get their DNS information from the same place, or email could be accepted by your MX backup and rejected by the primary server, clogging up the mail queue on the backup and wasting the resources on both machines. I discovered this myself when I checked the queue on the backup to find about 5 spam emails that had got past the HELO checks on the backup, only to be rejected by the same HELO restrictions on the main server because the domain did not exist. How is this possible? Well, there's a certain amount of lag in the DNS system due to the time it takes for new records to propagate through from the root servers to whichever server you are querying. As for why a domain would exist on one server and not on another, spammers sometimes register new domains to send spam, which could then be removed shortly afterwards. When I had the problem, my main server was using openDNS and my backup was using BT's DNS servers. The solution is to change the DNS servers used by either the entirety of both networks (by changing setting in the router admin panel), or by changing it in your server configuration. Here are the IP addresses for two popular choices: openDNS:

208.67.222.222
208.67.220.220

Google public DNS:

8.8.8.8
8.8.4.4

If you want to change the DNS settings for the server only, and you configured a static IP address in /etc/network/interfaces you can specify nameservers with the dns-nameservers parameter like this:

auto eth0
iface eth0 inet static
        address 192.168.1.2
        netmask 255.255.255.0
        network 192.168.1.0
        gateway 192.168.1.1
        broadcast 192.168.1.255
        dns-nameservers localhost

If you're on openSUSE, you can change your nameservers in YaST (Network Devices -> Network Settings -> Hostname/DNS - > Name Servers and Domain Search List)

Port forwarding

The only port forward necessary for the backup MX to function is port 25. Remember to make sure your server has a static LAN IP address on your host's network. You may also want to forward port 22 for SSH so you can log in remotely. Remember to disable password logins in favour of publickey authentication to protect your friend's network.

Testing

Before starting the tests, restart Postfix to make sure all changes have taken effect:

sudo service postfix restart

Or with systemd:

sudo systemctl postfix restart

You may also have to tell postfix to start automatically when the system boots:

sudo systemctl enable postfix

Now log in to your primary mail server, and run this command to watch the mail logs in real time:

tail -f /var/log/mail.log

Or for systems with binary logging:

sudo journalctl -f -u postfix

Also open a second window, log in to your backup server, and run the same command. This will allow you to follow an email through its whole journey.

Test relaying by sending an email to the backup server

The telnet session is the same as the tests we used in the full email server tutorial:

telnet backup.yourdomain.com 25
Trying 1.2.3.4...
Connected to backup.yourdomain.com.
Escape character is '^]'.
220 backup.yourdomain.com ESMTP Postfix (Debian/GNU)
ehlo yourdomain.com
250-backup.yourdomain.com
250-PIPELINING
250-SIZE
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
mail from: you@yourdomain.com        
250 2.1.0 Ok
rcpt to: you@yourdomain.com
250 2.1.5 Ok
data
354 End data with .
Subject: email relayed through MX backup
This is a test email
.
250 2.0.0 Ok: queued as A639C3EE6D
quit 
221 2.0.0 Bye

You should see the message be sent from your MX backup to the main server. The TLS loglevel settings we changed mean you should see a message in the logs about TLS being used for the connection between the backup and the primary server.

Test TLS is working for incoming mail submitted to the backup

We can use openssl s_client to check that TLS is working for incoming mail on the backup, and that the certificate is valid. For commercially signed certificates, the cert should already be in your trusted root store, so you can do this:

openssl s_client -starttls smtp -connect backup.yourdomain.com:25 -CApath /etc/ssl/certs 

If you use CAcert and you haven't imported the root certificate yet, you might get output like this:

sam@T440s:~$ openssl s_client -starttls smtp -connect backup.samhobbs.co.uk:25 -CApath /etc/ssl/certs -quiet
depth=0 CN = backup.samhobbs.co.uk
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = backup.samhobbs.co.uk
verify error:num=21:unable to verify the first certificate
verify return:1
250 DSN
quit
221 2.0.0 Bye

If you don't want to add the CAcert root to the machine permanently you can download it to your home directory and use it just to test, like this:

curl -O --insecure https://www.cacert.org/certs/root.crt

Which downloads it to ~/root.crt, and you can then ask openssl to check the certificate from the network against the CAcert root cert:

sam@T440s:~$ openssl s_client -starttls smtp -connect backup.samhobbs.co.uk:25 -CAfile ~/root.crt -quiet
depth=1 O = Root CA, OU = http://www.cacert.org, CN = CA Cert Signing Authority, emailAddress = support@cacert.org
verify return:1
depth=0 CN = backup.samhobbs.co.uk
verify return:1
250 DSN
quit
221 2.0.0 Bye

"Live" test

If everything has worked so far, it's time to do a live test. On the main server, stop Postfix:

sudo service postfix stop

or with systemd:

sudo systemctl postfix stop

Then send an email to your primary email address from a freemail account. If you log in to the backup server, you should be able to see the message waiting in the queue with the postqueue command:

sam@NUC:~$ sudo postqueue -p
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------                            
09712A82       3717 Sun Jan 24 18:32:35  you@outlook.com                               
                                (mail for yourdomain.com loops back to myself)               
                                         you@yourdomain.com                                  
                                                                                             
-- 4 Kbytes in 1 Request.

or you can use the following command, which does the same thing:

mailq

If you want to read a message from the queue, you can use the postcat command, specifying the unique ID of the message you would like to read, e.g.

sudo postcat -q 09712A82

Now you can bring Postfix back up on the primary server:

sudo service postfix start

or with systemd:

sudo systemctl postfix start

You can now either wait for postfix to attempt a redelivery, or manually flush the queue on the backup server with this command:

sudo postqueue -f

...which will force the backup to attempt delivery now, and the email should come through on the primary server. If you want to delete all email from the queue, you can use the following command:

sudo postsuper -d ALL

Mutt

Mutt is a commandline email client that is perfect for checking email sent to foo@backup.yourdomain.com using SSH if you don't want to do a full Dovecot installation like on the primary mail server.

Installation

To install mutt on debian derivatives:

sudo apt-get update
sudo apt-get install mutt

Or for openSUSE:

sudo zypper refresh
sudo zypper in mutt

Configuration

Per-user configuration for Mutt is stored in ~/.muttrc. If the file doesn't exist, create it. The following parameters can be used to configure Mutt for use with the Maildir format we asked Postfix to use earlier (by default Mutt expects Mbox):

set mbox_type=Maildir                                                                        
set folder="~/Maildir"                                                                       
set mask="!^\\.[^.]"                                                                         
set mbox="~/Maildir"                                                                         
set record="+.Sent"                                                                          
set postponed="+.Drafts"                                                                     
set spoolfile="~/Maildir"

To launch mutt, simply type:

mutt

The interface is fairly self-explanatory, you can navigate through the messages in the inbox using the arrow keys, press enter to view the message, and when you're done press q to quit.

Useful links

• list of Postfix configuration parameters