If your mail server goes down, what happens to your emails? In this article, I run through the scenario and talk about the solutions, or the non-solutions, that you might like to consider in terms of safeguarding the loss of any of your clients's emails, as well as the how-to of implementing them.
If your primary mail server happens to go offline, 2 things happen, assuming you have 1 cpanel server to cope with all your web services (http, pop, smtp, imap, ftp, ssh, etcetera ...). The first thing is that your own clients are unable to reach the server to relay or retrieve their emails, the second, of course, is that outside email servers are unable to relay email to your server either.
If your email server is offline for only a short while, the chances are that any email not sent immediately by outside email servers will be held by them until such time that emails can sent to your server. Email servers are designed to retry the relay of emails up to a point, usually 7 days, at which time they will return the email to sender and alert them that the email has not been sent. They will also in the mean time alert the sender to the delay of the email, it being frozen in the email queue.
If you email server is down for longer than the retry timeout of the sender's email server then the worst that can happen is that the sender will have to relay the email again, and of course your client be without the ability to send or receive emails. Which of course isn't satisfactory.
There are probably 2 clear solutions with regards to improving redundancy and up-time of email services:
The first is to run backup MX services. You can add as many of these as you like, in a pecking order of importance, so that sending email servers will attempt to relay an email destined for your email inbox to any of those servers, and each server in turn will pass the email down the chain, till it reaches the final destination. This means that the chances of any email being refused or returned to sender are less. I mean, what are the chances of all 2, 3, or even 4 MX servers being offline at the same time.
On the flipside of this are two issues. One, that it doesn't fix the issue of client's not being able to send and receive emails; and two, that although it allows you to receive emails from any outside source, if you also receive a lot of SPAM and/or face dictionary attacks, you will find a scenario where the queues of your MX servers will just get filled up with email to a point of bursting, as the relevent recipient email validation checks cannot necessarily be performed properly. SPAM relayers have a tendency to target the lower priority mail servers simply because they tend to be less looked after and provide less anti-spam protection, most, if not all, of which is focused on the primary mail server.
The second solution is to setup a backup mail server. That's to say an entirely different and secondary server that will be run in tandem with your primary server and both of which should be synced frequently to keep client's mailboxes up-to-date. In essence you would set the client's email software to access either the master or slave email server both to send or receive emails, and in this way they would only notice the lack of email service when both mail servers go down, and what are the chances of that?
The downside of this approach is that currently you either have to script the process to recreate all account actions on the secondary server, or you have to manually make the changes yourself, and when you have to do this for hundreds of clients it becomes impractical. A simple change of email account password could then cause problems when your client tries to access emails on the server with the outdated password.
Ok, so you have decided you want to run a seconday MX or a backup mail server, so how do you go about setting them up?
Well setting up a seondary MX server is simple. Once you have the second, third, fourth or more cpanel servers set up, all you need to do is go in and edit the /etc/secondarymx file, and include all the domains that you wish to allow that mail server to relay. If this file doesn't exist then create it, and add the respective domains. After this is done, edit the domain zone to reflect the changes and set up a CRON script to rsync the /etc/localdomains file from the primary server to the /etc/secondarymx file of the backup mail servers.
rsync -e ssh -avz root@primaryserver:/etc/localdomains /tmp/secondarymx
cat /etc/secondarymx >>/tmp/secondarymx
cat /tmp/secondarymx |sort |uniq >/tmp/secondarymx.new
mv /tmp/secondarymx.new /etc/secondarymx
rm /tmp/secondarymx
If you are running more than one primary mail server you may want to look at the idea of using a MySQL database and some php or other webservices to distribute the secondarymx domain information.
If you are running this Exim Dictionary Attack ACL for CPanel from ConfigServer on your primary mail server then you will need to whitelist the IPs of the secondary MX servers, to avoid them being automatically blocked.
You will also want to look at and consider the options regarding sender and recipient verification, as well as the processing of frozen and bounced emails, so that rather than clogging up your email queue and taking up resources and potentially killing the server, they are deleted after a short period of time. You can do this with a combination of WHM options and looking directly at the exim config file.
Also, as I said before spammers will target lower priority MX servers because they are less protected. My answer to this would be to avoid having too many MX servers, so that you can focus on them properly, and that you install, run and manage properly anti-spam software such as SpamAssassin and MailScanner on each and every one of the mail servers.
Planning and creating the backup mail server solution with clustered servers in tandem running CPanel server is much tricker, or should i say, more complex, though certainly not impossible. The best solution is 2 or more cpanel servers mirrored in realtime, with failover, something which is beyond this article to discuss setting up, but something that I might cover in another article dedicate solely to that another time.
If you need basic backup for email delivery, then the secondary MX option is a no brainer. It is important though to implement as much anti-spam and virus option on the secondary servers as you do on the primary. The great advantage of this option though, is that you can get up and running very quickly.