How to (not) run your own email server

You have probably been reading in the news about a particular politician who ran a personal mail server out of their own home. This post is apolitical and won’t delve into the politics surrounding the issue, but it does present the opportunity for education in regards to running your own mail server, should you choose to do so.

I’m familiar with these matters having built and maintained internal mail servers for companies as small as two employees running out of a basement to publicly traded multinational software companies. For the purposes of this post I’m going to focus on Microsoft’s Exchange email server, but most of what I will discuss also applies to FOSS email server software as well.

This list of do’s and don’ts is obviously not exhaustive but my goal here is to provide a good overview that most business owners or any IT managers can read and would hopefully find useful.

First, don’t (unless you have a really good reason to)

If you don’t have a really good reason to run your own email server, don’t. It’s a lot of work, so if you don’t have to for either specific regulatory or security reasons your better off outsourcing your company’s email services to a cloud email hosting provider. The largest providers out there that offer this type of service are Google Apps for Work and Office 365. They have huge teams whose are responsible for maintaining email hosting infrastructure so that you don’t have to.

In addition to email hosting with your own custom domain name these two offerings also include online productivity suites and cloud storage. Both of the aforementioned solutions are also fairly inexpensive, starting at about $5/user/month. The selection of which one you would select is based on the preferences of the company. For younger companies Google Apps for Work may be preferable due to the small learning curve: most employees are probably already using Gmail for their home email already. However, if the benefits of an Exchange-like environment and the the inclusion of Microsoft Office desktop applications are desired, Office 365 is probably the solution for you.

The tradeoff when using a cloud hosted email solution is that you do not have as much control over your data stored in the cloud as if you were storing it in a server in your office or own datacenter. For example governmental agencies can go directly to the cloud hosted email provider with a subpoena and request your data and you wouldn’t even know it. Microsoft last week sued the government in protest of this policy, arguing that it is a violation of the 4th amendment. This may or may not present an issue for your organization.

When using a cloud hosted email solution, you are at the mercy of the provider to keep the service up and available. You are placing your trust that Google or Microsoft (or any other SaaS provider) will do their job, will backup your data, and will not experience business-interrupting downtime. That said, cloud email hosting providers typically do a pretty good job in this regard as the viability of their business is predicated upon the ability of other businesses and individuals to actually use their services. Speaking from personal experience having used Google App for Work for a couple of years service downtime has been close to zero. Other cloud services that are paired with email, such as online productivity suites, haven’t been as lucky though. I have personally experienced outages related to Google Drive and Docs in the past. That said, cloud outages for these types of applications are typically rare and providers are often transparent as to how reliable their service has been; here’s Google’s status page as an example.

There also may be regulatory requirements and the larger hosting providers are increasingly able to fulfill these. For example, with Google’s Postini acquisition a couple of years ago they are now able to offer a “Vault” product with their higher-priced tier (they only have two) companies are able to place legal holds on data for discovery requests. Cloud email hosting providers are also often complaint with the standards of security and regulatory standards bodies. Here’s information about Google’s compliance efforts.

Have I scared you away from hosting your own email server? If so, you have many options in addition to the ones already mentioned, including a service recently introduced by Amazon and others from companies such as Rackspace. Which one is best for your business is outside the scope of this article.

If not, continue reading.

You need to secure the communication into and out of your server, using a TLS* certificate

(*I’ll use the term TLS certificate when talking about certificates that have historically been called SSL certificates. However, SSL (v2 or v3) as a protocol is a deprecated, insecure protocol that is not and should not be used to secure internet communications. If you are running a public-facing server that uses secure connection methods such as HTTPS, you should make sure these are disabled and instead the TLS protocol (1.0–1.2) is used to secure traffic between servers and web browsers.)

When I started working in IT and dealing with server encryption certificates over 15 years ago, only a few companies sold them and they were really expensive. Securing a server farm could cost thousands of dollars a year. Today, in contrast, server encryption certificates are either very inexpensive or free. Accordingly, there is no excuse to at minimum encrypt the protocols used during mail sending and retrieval, namely HTTPS, SMTP, and POP/IMAP. This ensures that the communication between the device on which you are using the mail server, such as your laptop or phone, and the email server itself is encrypted in such a way that it would be very difficult or impossible to decrypt without the private key stored on the email server itself.

It’s a shame that I have to mention this at all, but one has to as it was revealed that the individual referred to at the beginning of this article didn’t have a certificate in place for the first few months the server was in use. During that time, all traffic was sent and received to and from the server was in clear text, unencrypted, and could have been intercepted via a MitM attack.

It is a must that client-server traffic (i.e. between a phone and the email server over HTTPS) that passes over the open internet is encrypted. SMTP traffic between email servers should be as well as most email server software, when properly configured, support what is called SMTP over TLS. In addition to client-server traffic being encrypted, it also encrypts mail sent between email servers. Cloud hosting providers such as Google Apps for Work (i.e. Gmail) have supported this for a long time so if your mail server supports it as well email between your server and Google’s email servers will be encrypted.

Monitor your server, continuously

One of the primary reasons that a company would outsource their email capabilities to a firm such as Google or Microsoft is that running an email server is a 24/7/365 job. I’m not saying that you have to constantly be logged in and watching what’s going on it in real time, but that you always have to be aware of what’s working, or more importantly not working, on the server. If you outsource your email service, then this becomes someone else's problem, though you have to place your trust in them that they will do their job properly.

First, you need to monitor the health of the server such as available disk space, available memory, higher than normal CPU usage, and whether or not it is actually available and accessible. Second, you need to monitor the logs for errors or suspicious activity. In the context of an Exchange server on Windows, you’d want to monitor at minimum the Application, System, and Security event logs. When troubleshooting issues with mail delivery you will also be able to inspect the protocol (HTTP, SMTP, etc.) logs, though most will not need to monitor these regularly.

There are many services and software available that make it easy for you to monitor your email server, but the two that I have used most frequently is LogMeIn Central and SiteUptime.com. Another good (and, up to a point, free) software package is PRTG. However, this is not mean to be an exhaustive list and there are literally dozens of services and software packages that can allow you to monitor your email server. (Full disclosure, I worked at LogMeIn from 2007 until 2012 and I’m friendly with a lot of people that still work there, so I’m a bit biased.)

LogMeIn, while it can be used both for remote control, it is also has the ability to monitor server health metrics (i.e. CPU, memory, disk). You can create rules through the LogMeIn Central platform to monitor Windows event logs. When an alert is triggered an email is sent to whatever email address you desire, including those that go to SMS gateways (i.e. 9785551212@vtext.com sends a SMS message to the Verizon Wireless phone with the number 978–555–1212).

SiteUptime.com is used to ensure that services that should be externally available, such as HTTPS for client access and SMTP for sending to and receiving email from other servers, are available from one of many monitoring locations. If a service becomes unavailable, email or SMS alerts can be triggered notifying you that there is an issue.

The goal here is to know if there is something amiss with your server, either an issue with it’s reliability (as near 100% uptime is required these days due to the ubiquitous nature of email) and it’s integrity (in the context of security). If there is an issue you want to know and begin the repair efforts, before you get a phone call from the CEO saying that he can’t send email from his mobile phone.

Stay up to date with vendor updates that address vulnerabilities or bugs

Software is created by humans and therefore isn’t perfect, sometimes containing bugs and vulnerabilities. Bugs or security vulnerabilities will always exist until there is a time where a computer or AI has the ability to write flawless, perfect software. So, we’re going to have to continue to deal with them for a long time.

When bugs or vulnerabilities are found, either by the vendor itself or a third party, typically* an update is released by the vendor in a timely fashion that fixes the bug or removes the vulnerability. You should ensure that your email server has all available updates installed so that it is protected against hackers or other nefarious parties exploiting the vulnerabilities to break into your email server or otherwise access data that should be secured.

(* I use ‘typically’ here as it is commonly thought that there are bugs that are found by third parties and aren’t fixed as they are then sold for a profit to organizations that would find them useful. For example, a company may find a bug in Apple’s iOS and then sell the ability to exploit the vulnerability, to monitor or extract data from mobile phones running that operating system. This bug isn’t reported to the vendor so that it can be fixed; if it was then this ability would be diminished or eliminated.)

Backups, and backups of backups

Last, but certainly not least, is that you need to backup your email server on a regular basis; usually once a day is sufficient. There are several reasons that you want to do this in addition to the obvious ones. However, the main reason is hardware or software failure, or ransomware. You need to backup your data because hardware and software used in an email server can and will fail at some point, sometimes resulting in downtime and worst case data loss.

You can help prevent these outages and losses from happening by using server-grade hardware that has redundant components (hard drives, power supplies, network interfaces, etc.) so that when failure does happen, you can replace the failed part without the failure resulting in downtime or data loss. You’ll also want to use anti-virus/anti-malware software, if possible, on the server and on any devices that connect to the server, primarily workstations (laptops & desktops).

In terms of creating backups, you can use a variety of different mediums such as external hard drives or tape cartridges as the backup location. There are also a variety of different software packages from Microsoft and other software companies that you can use, including the backup utility included with Windows Server.

The key here is that once the backups are made, you want to take the medium that you backed up to offline, such as removing the tape from the drive or unplugging the external hard drive. The reasoning for this is not due to hardware or software failure, per se, but due to the threats of ransomware. Ransomware is a variant of malware that will encrypt all data that it has access to, rendering it useless, and then demand payment for the key needed to decrypt it. This malicious software cannot encrypt data which it does not have access to, therefore it is important that the backup media be disconnected when not in use. There have been instances where malware has rendered backups unusable as they were in the same online state that the original data being backed up was.

Backups should also be stored offsite, not in a safe in your office and server room. You can perform a secondary backup to a cloud hosting service such as Amazon S3 or Microsoft Azure, though you want to make sure that the data you are backing up is encrypted before it is uploaded to a third-party storage location. There are many tools that you can use to accomplish this such as Cloudberry and Microsoft’s Azure Backup.

You also have the option of storing the backups that you run onsite to physical media such as disks or takes, offsite. There are services offered by firms such as Iron Mountain that will pick up your backup media at your office and store them in their secure facilities. The advantage of using a service like this is that there is a documented chain-of-custody, important if your company is regulated, and you have access to the backup medium 24/7/365. This is better than having an employee take the backups home as there is likely no documented chain-of-custody, you have to depend on the availability of the employee to get access to backups stored offsite, and there are embarrassing incidents where backups have been stolen from an employees car.

You need offsite backup because natural disasters such as fire and flooding, which we will go into more detail about in the next section, can and do happen. If your backups are only stored offsite and the building in which the server is hosted burns down, you’re left with nothing to recover with.

Hoping for the best, but planning for the worst

Backups are useless if there is a disaster unless you have somewhere to restore to. This is where cloud email providers provide an advantage: they take care of maintaining backups, replicating your data to multiple datacenters, and ensuring uptime through various methods of redundancy and resiliency so that you don’t have to worry about it.

If you run your own email servers you need to make sure that you have spare hardware and network connectivity available so that you have somewhere to restore your email data to. This can be achieved either by maintaining relationships with hardware vendors so that you can order and receive replacements within a day or two (or whatever timeframe your business finds it acceptable to be without email services) or if you have email servers ready on standby, perhaps at a branch office, that you can switch to fairly quickly.

What your company would do is all a matter of what is considered acceptable in terms of downtime when the cost is factored in. For smaller companies it may be acceptable to be without email for a couple of days in the event of a disaster, natural or otherwise, due to the high costs of maintaining duplicate infrastructure that is on standby but is otherwise underutilized or not utilized at all. For larger companies the argument can be made that it makes economic sense to have infrastructure on standby even if it is not used due to the loss of productivity should email not be available.

If your server is virtualized and is running on top of a hypervisor, as most are these days, then you have the option of replicating your entire mail server offsite and stored so that it can be started again within minutes. An example of this service is Microsoft’s Azure’s Recovery Services which allows you to replicate virtual machines hosted on Hyper-V into Azure’s IaaS service. In the event of a failure, you can simply start the replicated server and it will run in Azure’s infrastructure.

Whew, that was a lot of reading

Give yourself a gold star if you have made it this far. This is can be heavy stuff.

I hope you found this useful if your company is just starting out, considering going from on-premise to a cloud hosted email solution, or from cloud to on-premise.

There are a lot of things to consider. However, the information found above should be useful for those running their own email server or servers (on-premise). But you can and should learn from the mistakes of others.