Serving Email Part 4: The Email Server(s)

Message Transfer Agent

This is part four of a six part series. In this part we will cover the Email Server(s).

This series:

Part 1: The Pieces of the Puzzle
Part 2: Subdomains and DNS
Part 3: Encryption and SSL Certificates
Part 4: The Email Server(s) <- You are here
Part 5: Autoconfiguration
Part 6: Debugging Email Servers

In this post: I discuss the criteria for choosing your email server(s) and then link to the Wikipedia email server comparison table, where you can find email servers that match your criteria.

There may be up to three different email server programs, possibly on separate servers, or they may all be combined in one software. They are:

The Message Transfer Agent (MTA), also called the Outgoing Server.
The Incoming Server.
The WebMail Server (optional)

This diagram is the most complex part of the post - don't let it scare you:

Things to note about the diagram:

I made the SMTP/IMAP/POP3 arrows unidirectional to indicate which way the emails flow, even though there is bidirectional flow of information (for example to authenticate, or to delete emails).
Each of the components in the Local Server can be separated out onto a different machine, despite being shown on one machine here.
In concept, the MTA is relatively simple: it will check an incoming email's address against its user-base and either put it in Email Storage, or look for an appropriate MTA to pass it on to. All communication is via SMTP.
The Email Storage is shared between the Incoming Server (MTA) and the Outgoing Server, so they must use the same format and synchronize properly, whether that storage is file(s) or a database or something else.
The Incoming Server never actively sends email, it waits for a client to retrieve it via IMAP and/or POP3.
Most WebMail Servers work just like an IMAP-based Email Client Software, except that the user accesses it through HTTP(S) and Browser Software.
This diagram leaves out the authentication database - user/password information. The Incoming Server and Outgoing Server should also share this information.

I put the criteria roughly in the order I think of as most relevant and important, not the order they appear in the Wikipedia comparison.

Panel

If you have a panel, like Plesk or cPanel, then I recommend using their defaults: their choice is usually pretty flexible and you will get better support. Personally I have Plesk on Linux and use the defaults: Postfix for outgoing, Courier for incoming, and Horde for WebMail.

The Operating System: Linux, Windows, or MacOS

Not much to say, really: you probably already have your operating system. Linux is free. Windows will cost. Linux has the largest market share for Email Servers. MacOS the smallest. Almost all that support MacOS support Linux, too, since they're both Unix derivatives and Linux has the larger market.

Server Types

Outgoing Server: SMTP - sends and receives Email from remote servers.
Incoming Server: IMAP, POP3 - retrieve the email on the server for a client. IMAP keeps the email on the server. POP3 deletes it from the server after retrieval - the client must store it.
WebMail - Access via a web browser.
ActiveSync - this is a Microsoft protocol for synchronizing emails, contacts, calendars, tasks and notes. Supporting these is beyond the scope of this series, but may be something you want to consider.

WebMail is the simplest to separate out: there are specialized WebMail server programs that do nothing else and only need IMAP and SMTP access to work. I would not make it a criteria that WebMail be integrated with my other servers. Note also that the Wikipedia comparison list excludes WebMail only servers.

Your incoming and outgoing server can be independent, but if they are, you will still need them to access common storage and want them to access a common set of usernames/passwords, so in that case, pay attention to the storage and the authentication storage options: filesystem, database, LDAP, other.

Earlier people used to always retrieve their email and delete it from the server - space on the server was expensive and you had one computer. That is the POP3 model. Nowadays, server space is cheap and people want to read their email on their mobile, their tablet and their laptop, so the email needs to be on the server to be accessible. This is the IMAP model. For general customers I recommend supporting both - there are some old-school folk still around. If you have to drop one, drop POP3. Separate IMAP and POP3 servers are not practical.

Secure Connection

Unless you're doing an in-house mail system in a local network, secure connections are an absolute must, both for outgoing and incoming. The SSL feature is straightforward: it means the supported protocols appear on their alternate SSL ports, often signified by appending an "S" to the protocol name (SMTPS on port 587, IMAPS on port 993, POP3S on port 995). The "Opportunistic TLS" options (also called STARTTLS), SMTP over TLS and POP over TLS mean that a plain text connection is made over the old lower port number, and then the connection is upgraded to a secure connection. Some people prefer the former, so that no meta-data can be caught by eavesdroppers. Some prefer the latter, so that fewer ports are used. Most servers I've seen support both, letting the client decide.

Internal workings of a physical lock and key

Authentication

Authentication means asking for username/password, and is an absolute must. Whether or not encrypted passwords are supported doesn't seem to be in the Wikipedia comparison, probably because with an encrypted connection, password encryption is now unimportant.

SMTP Authentication is in the list: there are servers that allow sending of emails without asking for a username and password at all, even though that is very likely to get your server blacklisted these days.

If you're using separate ingoing and outgoing servers, be sure they can use the same authentication database (Filesystem/Database/LDAP).

I would ignore "POP before SMTP" - it is almost never used anymore. I would also ignore APOP, a specialized form of encrypted authentication for POP3 that is not relevant for most with the rise of MAPI.

Storage: Database, File System, Other

The storage system for incoming and outgoing must be compatible. A given if you're only using one program for both, but needs to be checked if you're splitting it up.

This may also be relevant to your backup system or to your personal preferences: some old school programmers may like to see actual files they can edit with a text editor; a database specialist might like to be able to mangle things with SQL.

Mature / Active Development

New software tends to be buggy, so mature is good. It's not on the comparison list, so I would google the software that makes it to the final rounds. I would only go "bleeding edge" with email that I don't care about.

I think that IPv6 support is a good indicator of how actively the project is being developed. Support of IPv6 is usually not important yet, but it will be, and so a software that does support it is forward looking. I would, again, google to verify in the final rounds.

Antispam Features

I could do a whole series on antispam features. That said, for small operations I don't think they're a killer criterion - I receive spam, my email client mostly sorts it into the spam bin. It's not been a problem for me so far. If you're customers are not tech-savvy, you may want one with integrated antivirus.

Other Criteria

IMAP - IDLE - real time update to email clients, without continually refreshing. Maybe relevant if you have client software that supports this and people want it.
NNTP - Network News Protocol - for news readers. I've never actually used this, but if you do, go for it.
Sieve is a filtering language. Examples of use: auto-rejecting too large emails, pre-sorting spam, pre-sorting of email into other groups. I think this has lost a lot of importance, especially with the other antispam options.
Upgrade Path - there are tools that can do IMAP backup and restore, so I wouldn't worry about that too much. If you're doing ActiveSync/WebDAV, that's a different can of worms.

Compare the Servers

Click here: The Wikipedia Comparison of Mail Servers

Take your time and compare.

Most of them are free, so if you're having trouble deciding, you can do a temporary install to test it out.

man installing a permanent powered home device

Installation

If you're running one of the panels, then it's probably already installed, and you only need to activate it. Your panel will have documentation.
If you're under Linux, many of these are available in the distribution channel - e.g. my synaptic package manager lists these packages from the comparison list: Citadel, Courier, Cyrus, Dovecot, Exim, OpenSMTPD, Postfix, qmail, sendmail.
For other everything else: find their website and follow their instructions.

Do not forget the SSL Certificate!

Your package will generally have instructions on how to set the certificate to be used. Just don't forget it, otherwise your users will get nasty messages and may not be able to use your server at all.

Special note for Plesk users: Plesk will automatically use the default certificate for the email server. Plesk has documentation on how to bypass this if you need to.

In Closing

We're almost there! You should have a working email server now. All that's left is to set it up so that email clients can find the proper settings more easily - which is a lot more complicated than it should be, in my opinion.

Thank you for reading my blog post!