Store and Forward Reliability
A little while ago (over a year now) we changed our ISP. The reasons for changing were huge – we’d been offered a deal that would see us move to fibre to the cabinet, our download speeds increase by seven times and our upload speed increase by some twenty times. The deal was for a business grade connection with telephone line included, for a small upgrade in cost to our current phone and Internet package.
The problem was we were with Demon Internet, who hosted our domain (DNS) and provided a store and forward email service on our domain. Hosting the domain elsewhere was easy enough, there are a couple of web sites that will do the DNS thing. The problem was setting up a store and forward service for the email. After a month or two of unreliable emails, we resolved it by buying a virtual private server (which happened to come with a very reliable DNS service too, but I think that’s covered in another article).
The original reason for getting the VPS was to maximise our web uptime – one of Demon Internet’s strength was that the service never turned off. We’d had a couple of teething problems with our new ISP, and while they’re resolved now, we did initially gain in reliability with our existing websites. Oh, and the VPS gave us another static IPv4 address to run an SSL service from, another side benefit.
It wasn’t until we put the store-and-forward configuration on there that we really noticed the difference.
What is Store-and-Forward
To understand what this does it helps to know a little about how email is routed round the internet. When an email is sent, the domain’s DNS configuration is checked for what is known as an MX record. MX is short for Mail Exchanger, and each domain usually has more than one listed. MX records are the IP addresses (or, optionally, hostname of the mail server) and each comes with a priority number. When attempting to deliver an email to someone in that domain, a connection is attempted to the lowest priority number MX record (or one of them, selected at random if there is more than one with the same priority), and if that connection fails, the next highest priority MX is attempted. If the sender cannot connect to any of the MX machines, it’ll try again later, and queue the mail for several hours if necessary before returning it to the sender as undeliverable.
Normally your Mail Server will accept email for your domains but reject stuff that it cannot deliver to its own mailboxes (if it delivered mail onwards, this is known as Relaying, which fosters spam and is not normally used today). Also your mail server normally accepts emails destined for addresses/users it knows about and the rest is rejected. If your mail server happens to be down, though, you still want your own services to accept your email. This is where store-and-forward comes into play. With a lower priority MX record pointed at a ‘backup’ mail server you can have your mail accepted and held until your main mail server comes back online.
This is a less than adequate solution – your store and forward system knows about the domains it is temporarily accepting mail for, but does not have user/email address details for your mailboxes. It blindly accepts mail for your domains. All it does it hold the email and attempt to forward it on to your primary domain’s MX when it becomes available.
It can do minor checks on the mail, for instance checking to see if the sender’s IP address is not blacklisted by one of the spam-catching organisations such as Spamcop or Spamhaus.
How Do We Configure Store-and-Forward
Installing the Email Packages
If you have a CentOS machine (mine is CentOS 7) you need to ensure you have the right packages installed. Start by un-installing Sendmail if it’s present (I couldn’t find a simple store-and-forward configuration that would work for this) and replacing it with Postfix, you need root privileges to use these commands (and all those that follow):
yum remove sendmail yum install postfix
Editing the Configuration File
Postfix is provided with a default configuration, that will work out of the box for many email scenarios. For store-and-forward, however, we have to make a few changes. Take a look in the postfix configuration directory, and edit the file main.cf, like this:
cd /etc/postfix vi main.cf
You don’t have to use vi, of course, you can use whatever editor you feel most comfortable using. Near the top of the file is a line defining inet_interfaces. I used this, which is probably the default configuration:
inet_interfaces = all
And immediately after it we get the chance to declare the internet protocol we want to use. I have IPv6 turned off on my VPS, as it’s not currently supported by my VPS hosting company. I therefore set the line that sets the inet_protocols to look like this:
inet_protocols = ipv4
You may need to set this to other values (possible values are shown in the default configuration file). Your eventual choices will probably be determined by what your ISP or server host allows.
The next check to make is with the mydestination value. I’m fortunate that my VPS isn’t in one of my Internet domains, so I left this as the default:
mydestination = $myhostname, localhost.$mydomain, localhost
If I’d been doing a store and forward for the domain that my server is in, I’d have to doctor this line to tell Postfix not to try and deliver mail addressed this way to local users.
Scroll or search through the file until you find the line that sets up the relay domains. I set mine up like this, you may want to use your own domains (the MX records for these domains do not point at your servers):
relay_domains = roxoff.net roxoff.org ... and others
This is just a simple list (separated by spaces) for each of the domains you want to hold mail for. Immediately after this, you should add a new line that defines the recipient restrictions. I use these, because it works for me, you may want to investigate this statement and tweak the rules it applies
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unauth_pipelining, reject_non_fqdn_sender, reject_rbl_client bl.spamcop.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client dnsbl.sorbs.net, reject_rbl_client cbl.abuseat.org
As you can see, I use four of the more popular real-time black-hole lists on the internet, this prevents quite a lot of spam getting through.
Edits to main.cf are now complete. Save the file and close the editor.
Checking Your Email Aliases
Before we turn on Postfix for the first time we want to make sure that any mail that the server generates gets through to warn us of any problems. Take a look at the file /etc/aliases. Right at the bottom of this file is a line that reads ‘# Person who should get root’s mail’. Edit that line and add your own email address after the ‘root: ‘.
If you’ve previously been running Sendmail on this server, you should note that Sendmail’s configuration by default will have been in /etc/mail – including the aliases file. If you had any other aliases in there that had any meaning, you might want to add them to your /etc/aliases file – although I’m not sure what good they would do if any of the names are in the domains you’re store-and-forwarding.
Update the aliases database by running:
Update the Firewall
Next, edit the firewall and ensure your server can accept connections on the SMTP port, usually 25, but you can configure it in main.cf, so if you’ve changed it (bad idea if you want to receive mail from servers you don’t know) you’ll need to add any other ports to your configuration. There are two firewall configuration tools you could use, either ‘system-config-firewall’ or ‘firewall-config’, depending on which packages are installed on your server.
There are many ways in which DNS can be defined. To ensure your store-and-forward can be contacted when your email server is down, edit your primary DNS configuration to add the backup mail host. The priority number must be higher than the primary mail server. A line next to your existing MX record will be sufficient, but if you’re using a name for the mail server, ensure that the name is also added as an A record in your DNS host list. The lines will look something like this:
MX 50 mailgate.yourdoma.in. MX 100 vps.otherdoma.in.
Note the presence of the fullstops at the end to prevent the DNS server adding the default domain. You might also find it helpful to add the backup MX record’s name to the /etc/hosts file on the server, that way it doesn’t have to make a DNS round trip to look the name up each time an email is received.
If your DNS records are hosted publicly, you may want to wait a few hours for the MX updates to propagate around the internet before you test this is all working. If you have the IP address right for your backup MX record, then you should not have to change your DNS settings again
Enabling the Services and Turning it All On
To test that it’s all working, turn on the postfix service on your store-and-forward server with:
service postfix start
Next, turn off the mail server on your main server – this is so that it cannot be contacted and the backup email server must be used.
Using a 3rd party email service such as Google, Yahoo, Yandex, etc. send a test email to your primary domain account. It will not be received on your main mail server as the service is off, but you should see arrive on your backup mail server. You can see it arrive by monitoring the logs.
Now restart your email service on your main server. Your backup mail server will (eventually) attempt to send the email to you. Once you have received this email, you know that your store and forward system is working smoothly.
You can enable the Postfix service so that it starts after a reboot with:
systemctl enable postfix