Linux Email: Set up, maintain, and secure a small office email server

Most Internet Service Providers (ISPs) already give customers the ability to send and receive e-mail on their servers, so why would we want to own and manage it by ourselves? As you are after all reading this book, you may already have your reasons, but let us examine this question and some possible answers to it.

The most important reason for hosting and managing your own e-mail server is control. For many organizations, e-mail is an important part of the Information Technology infrastructure. Keeping control over your e-mail has many advantages.

More control requires more responsibility and more knowledge, and that is where this book comes in.

These hopefully compelling arguments aside, there are also downsides to hosting your own e-mail server. This is a task that requires a certain level of knowledge and commitment, and so should not be undertaken by everyone. With your own server, you are not only responsible for the service you provide to your users, but you also have a responsibility towards the whole Internet community. An ill-configured e-mail server can help worms and spam to spread, which is not only is a disservice to the community but can also get your server blacklisted. Even though a properly set up server can run for years without requiring much maintenance, you must keep yourself reasonably updated and be prepared to act upon new threats that may arise. This is not meant to scare you off, but just to make you think carefully before embarking on this project.

Your server needs to be available through a permanent Internet connection with a fixed IP address. In theory, it is possible to run an e-mail server with a non-fixed (dynamic) IP address but it will not be reliable when the IP address is changed, and you will risk losing messages. With a dynamic IP address, you will also face a bigger risk of being put on one of the blacklists for dynamic IP address ranges.

If you are serious about running an e-mail server, get a decent business-class Internet connection. These are relatively inexpensive these days, and investing in one will save a lot of trouble later on. E-mail traffic does not depend on high bandwidth, so the capacity of a simple DSL line should be more than adequate.

Even though you will need a fixed IP address, you do not necessarily need a public IP address dedicated to the mail server. If your company only has a few external IP addresses and uses private RFC 1918 addresses (192.168.x.y) on the inside with a Network Address Translation ( NAT) router, this is not a problem. The NAT router connects the private network to the rest of the world, and it is possible to set up the router to forward the ports required by the e-mail services to the internal e-mail server.

The next table shows which TCP ports are most likely to be used for this.

If employees want to access their messages from home or from the road, all that is required is to make sure that no firewall is blocking access to the required ports, and that the NAT router (if any) forwards these ports correctly. If users want to send messages via the e-mail server, some extra configuration will be necessary to allow the host to perform authentication to prevent unregistered users sending e-mail.

When choosing a computer to use as an e-mail server, a lot of people have misconceptions regarding the hardware required to perform this task well. The constantly increasing performance of computers seems to lead people into thinking that they really need the latest and most buzzword-compliant stuff, even if they only want to handle a few thousand messages per day.

Although a certain expertise is required to assess the hardware needs for an organization, common sense goes a long way. For a company with 100 users, a reasonably high upper limit for the number of messages per day would be 5,000. That would allow each user to send or receive 50 messages every day. Even if we say that each and every message is sent within the eight hours of the working day, on an average, the system will not have to cope with more than 10 messages per minute. It is reasonable that a modern computer can receive and act upon a single e-mail message, often only a few kilobytes in size, in less than six seconds.

This little back-of-the-envelope exercise is obviously very rough and does not, for example, take into account the fact that messages typically do not arrive uniformly distributed in time, but it is still a pretty good way of estimating.

Let us now take a deeper look into what to think about when choosing the server. For an e-mail server that does not perform any content scanning (viruses, spam, and so on), the performance is typically not bound by the CPU but by the I/O performance, specifically the seek time of the hard disk(s) and the quality and configuration of the I/O controller. Throwing more CPU horsepower at the problem will not help. Modern computers are relatively better equipped CPU wise than I/O wise, so investing in a multiple gigahertz multi-core CPU configuration is probably useless. For any reasonably modern 1 GHz-class PC, a handful of messages per second is no problem. That load equates to almost 20,000 messages every hour.

Adding content scanning will probably increase the CPU load quite a lot, and the I/O system will also require more power to keep up. Still, one or two messages per second should not place a noticeable load on the system.

What we have been discussing so far is just the e-mail server. All it does is receive messages and deliver them to other hosts or local mailboxes. When choosing a server, you should not forget that people are going to want to read their e-mail too. This service is provided by additional server software. Just like the message handling software, the key requirement is I/O and not CPU. The number of users of the system is by itself an irrelevant figure; what is important are the usage patterns. How often will the users poll their mailboxes? If 100 users poll their mailboxes once every five minutes, on average there will be one every three seconds. Checking if a mailbox has any new messages, takes a fraction of a second, so the burden will not be significant.

The final, and arguably the hardest thing to consider, is disk storage. Using the expected traffic numbers, we can make some rough estimates. Let us assume 80% of our messages are under 1 KB, 15% have document attachments of 200 KB with the remainder being videos and other large files of 1 MB. Therefore, using a 200 day working year, that equates to a storage requirement of approximately 80 GB per year. A typical 1 TB disk drive would have the capacity for more than 12 years messages assuming no messages are deleted.

These guidelines may appear vague and non specific, but it is impossible to give exact figures. The performance one would expect from a given piece of hardware depends on so many factors that trying to give anything but general guidelines would be misleading. Use common sense and simple back-of-the-envelope calculations; do not buy the fanciest server you can find unless you are sure you really need it, but also do not use any old abandoned desktop machine you can find. Even if the performance of the old desktop machine may suffice, the components may be old and the service agreement or warranty may be out of date.

Why are we discussing basic network communication protocols in this book? Are we not running advanced software? Indeed we are, but knowing one's way around the protocols cannot only assist debugging a possibly non-working system but also increases the understanding of a mail system's behavior. We will start with a rather non-technical overview of the protocols, after which we will focus on the protocol details.

220 mail.example.com ESMTP Postfix (2.12.6.2)
EHLO gw.example.net
250-mail.example.com
250-PIPELINING
250-SIZE
250-VRFY
250-ETRN
250 8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
MAIL FROM:<jack@example.net> SIZE=112
250 Ok
RCPT TO:<jill@example.com>
250 Ok
RCPT TO:<jack@example.com>
250 Ok
RCPT TO:<joe@example.com>
550 <joe@example.com>: Recipient address rejected: User unknown in local recipient table
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Test mail
To: <root@example.com>
Date: Sun, 15 May 2009 20:23:22 +0200 (CEST)
This is a test message.
.
250 Ok: queued as B059D3C2B
QUIT
221 Bye

The Domain Name System (DNS) plays an important role in e-mailing. The DNS is used by both, e-mail clients and e-mail servers. Even if you do not intend to maintain your own DNS server, a thorough understanding of DNS's role in e-mailing is a necessity for the mail server operator. This section assumes that the reader has basic knowledge of how DNS works in general.

Having a backup mail server that can receive messages if the primary server is unavailable sounds like a really good idea, but today's reliable Internet connections together with spam, worms, and other rubbish have for the most part made backup mail servers unnecessary and often even harmful. The rationale for having a backup server is that it can receive messages while your primary server is down, and then deliver them to the primary server when it is up again. However, the advantage of this is very small, as all SMTP servers are required to queue undeliverable messages for at least five days before they are returned to the sender. Granted, by having a backup server it is possible to store unavailable messages for longer time than five days. However, if the main SMTP server is unavailable for longer than five days at a stretch then there are probably bigger problems than a few lost messages.

Because a backup mail server typically does not have the same spam-thwarting configuration as the primary server, spammers often specifically target backup servers in order to bypass the stricter rules of the primary server.

Another strong reason to avoid backup mail servers is that they typically do not perform recipient validation. This means that they do not know which recipient addresses are valid for the domains they act as backup servers for. This requires a backup server to accept all messages for the backed-up domains and attempt to deliver them to the primary server. The primary server will reject invalid recipients, causing the backup server to bounce such message back to the sender. This is known as backscatter and is bad for two reasons:

A busy server that does not perform recipient validation and is hit heavily with spam may have thousands or tens of thousands of undeliverable messages residing in the queue.

In this chapter, we started by discussing why you should even consider hosting your own e-mail server. Then, we looked at some questions that need to be answered before starting work with the server—the kind of network connection, computer power and disk space requirements that are expected.

To manage an e-mail server successfully, an understanding of the network communication protocols used is important. We gave an overview of POP and IMAP, and delved more deeply into the most important of them all, SMTP.

Finally, we looked at the vital role that the DNS plays in routing messages to the correct server or a backup server if one is available.