The most common email protocol today is SMTP, which is an example of a push mail protocol—the sender initiates the data transfer. Typically, a user runs a mail client (also known as a mail user agent, or MUA) to send the mail to the SMTP server (which is also referred to as a mail transfer agent, or MTA). The SMTP server then delivers the message to other servers, which then send it on until it reaches its destination. This chain can run for an arbitrary length.

Traditionally, users have had login accounts on the mail server computer and have used mail readers on the computer itself. This configuration, though, requires either mail delivery using SMTP to users’ desktop computers or login accounts for all users on a central mail server. Both options are a bit awkward, so a second class of mail server protocols exists: pull mail protocols. These protocols enable the client to retrieve (pull) the mail from the server. If an SMTP server that’s the ultimate destination for a message runs a pull mail server, a user on a desktop computer can run a mail reader that supports the pull mail protocol to read mail directly from the desktop computer, as illustrated in Figure 13-1. Two pull mail protocols are common today: POP and IMAP. (The differences are described in more detail shortly.)

Figure 13-1. A pull mail server enables users to read mail using mail clients on their local computers

Of these two pull mail protocols POP is the simpler one. It provides a single storage area for each user’s messages; users then download the messages and immediately delete them from the server. (Mail readers typically delete the messages automatically.) Users can then create local folders on their desktop computers using the email clients and store their messages that way. IMAP, on the other hand, supports mail folders on the mail server computer, as well as more sophisticated options for retrieving parts of messages. IMAP, isn’t quite as well supported as POP, but its ability to store messages in folders on the server helps when users frequently use multiple computers.

As a practical matter, most networks now use POP, IMAP, or a similar protocol (such as Microsoft’s MAPI) for the final leg of email delivery. If you want to use Linux as a pull mail server, you certainly can; several POP and IMAP servers are available for Linux and are described in a later section. These servers can work with Linux, Windows, and other clients. If you’re not sure whether to use POP or IMAP, you can install and use servers for both protocols; however, each user should probably use just one protocol. Mixing them can cause confusion; for example, messages disappear from an IMAP inbox after a POP client has been used.

Quite a few SMTP servers are available for Linux; however, four servers are the most popular and readily available. These servers differ in their design philosophies, mail storage formats (mbox or maildir, described in more detail shortly), ease of configuration, popularity, and other features:

Throughout the 1990s, sendmail ran on a majority of the mail servers in existence, according to most studies of the issue. More recently, though, sendmail has declined in popularity, while others (Exim, Postfix, qmail, and others, including Windows mail servers) have risen in popularity. Despite this decline, sendmail remains a very popular (perhaps still the single most popular) mail server program on large mail server computers. For this reason, sendmail configuration is described later in this chapter. Because it’s becoming popular as the default server on many Linux distributions, this chapter also describes Postfix configuration. Although Exim and qmail are both perfectly good mail servers, they aren’t described in this chapter, in order to keep the chapter’s size manageable. If your Linux system is already running one of these servers, you can either try to find equivalent options to those described here or you can replace your current server with Postfix or sendmail. Most Linux distributions ship with at least two or three SMTP servers, or at least make them available in an online file repository. You can also check the mail servers’ web sites for links to versions for your distribution.

The preceding descriptions referred to the local mail storage formats supported by each server. The mbox format uses a single file, to which email messages are appended. Each user has a mailbox, typically somewhere in the /var directory tree, to which the server adds messages as they arrive. The maildir format, on the other hand, stores messages as individual files in a directory. Users’ incoming messages may be stored in subdirectories of users’ home directories. Each format has its adherents, but your primary consideration should be compatibility. Local mail clients and pull mail servers must be able to read messages in the appropriate format. Some programs are limited in their capabilities, which can dictate your choice of options for the SMTP server, or even completely rule out an SMTP server. If you’re building a mail system from scratch, you might want to assemble a list of software you want to use, based on features and recommendations from others, then pick the file format based on what your collection of software supports. If you wish to replace an existing SMTP server program, the simplest approach is to pick one that supports whatever format you’re currently using.

Just as with SMTP, several POP and IMAP servers are available for Linux. Some packages support only one protocol, but many support both. Many of the servers are limited to just one mailbox format, though, and some of the IMAP servers use their own format for folders other than the inbox. On the whole, you may need to hunt a bit to find the server that best suits your needs.

Most of these servers use normal Linux authentication mechanisms, such as Linux’s PAM (described in more detail in Appendix A), although some provide options for using or must use some other authentication mechanism. Broadly speaking, UW IMAP is usually the simplest server to configure, and it’s usually adequate for small sites, particularly if you want to use POP rather than IMAP. (IMAP use with UW IMAP may be complicated if users also have shell access, because the server hardcodes the location of IMAP folders in the user’s home directory, which can be awkward. This isn’t a problem if users don’t have shell access to the server, though.) Dovecot has recently been gaining in popularity and is worth investigating if you find UW IMAP too limiting. Any of the other servers may also be good choices for particular uses—for example, if you only want to use POP or if you want to provide access to maildir-format mailboxes. This chapter describes running UW IMAP later, in Section 13.4.

Mail servers, like all servers, are potential security risks. In fact, mail servers—and particularly SMTP servers—can be more vulnerable than you might at first think, because they must perform some operations as root. For instance, when storing mail, the server needs to be able to write to arbitrary users’ mail queues, which are owned by their respective users. This means that mail servers must run as root, and the complexity of modern SMTP servers means that bugs in the code can give clever intruders access. This is why modular mail servers are, theoretically and all other things being equal, potentially safer than monolithic servers. By isolating tasks that must be run as root to separate programs, other mail server programs can run as non-root users, reducing the risk that a bug will lead to a system compromise.

That said, recent versions of the monolithic Exim and sendmail servers don’t have bad security reputations. I can’t promise that you won’t encounter problems if you use one of them, but the risk isn’t unmanageable for most sites.

In recent years, another email security concern has come to dominate the news: worms and viruses. (Most of these are technically worms by most definitions, but the term virus is frequently applied to them all.) An email worm is a piece of code sent via email that, when run, replicates and sends copies of itself to others, usually via email. Typically, such worms are sent as attachments that appear innocuous. They also might rummage through victims’ address books to locate new addresses, so recipients may trust the worms because they know the apparent senders.

Worms have become a serious threat; outbreaks have become fairly frequent, and the sheer number of worms being sent requires extra storage capacity, faster CPUs, and better network connections on mail servers than would otherwise be required. When a new worm is released and spreads rapidly, the demands placed on all these resources spike, often beyond the capacity of the hardware to cope with the problem.

Another security issue with email is that SMTP servers send their mail without encryption. This doesn’t pose a direct security threat to the mail server computer, but it does mean that email can be intercepted and read if any system between the source and the destination is compromised. For this reason, sensitive data such as passwords and credit-card numbers shouldn’t be sent via email. One approach to fixing this problem is to equip mail clients with encryption tools such as the GNU Privacy Guard (GPG; http://www.gnupg.org). Two GPG-equipped systems can send encrypted messages to each other, although the SMTP protocol itself remains unencrypted.