Essential System Administration, Third Edition

There are several administrative tasks associated with using message stores for some or all email recipients:

• Selecting and designating a mail server for the message store. For large sites, this task expands to designing and deploying a scheme in which several servers divide this task.

• Configuring daemons to run POP and/or IMAP on the mail servers.

• Setting up user mail programs to access the message store instead of or in addition to the default local mailbox.

The first item is intimately related to the overall network architecture and capacity planning, and this issue is discussed in this context in Chapter 15.

The second item deals with providing server-side support for remote email clients wishing to access and retrieve messages. There are two main protocols used for this purpose: the Post Office Protocol Version 3 (POP3, or justPOP) and theInternet Message Access Protocol Version 4 (IMAP4, or justIMAP).

POP is the older of the protocols, and it is also simpler than IMAP. It was designed for "offline" mail processing; the user's mail program connects to the mail server and downloads any new mail messages to the local system (usually deleting them from the server after doing so). In this scheme, the remote server functions purely as a temporary remote storage site. Although POP clients can be configured to automatically poll the mail server periodically, POP remains a manual transfer method at heart.

IMAP implements an interactive client-server model of interaction between the mail server and the client software. Mail can be downloaded to the local system as with POP, but an IMAP client can also be used to access and manage a centrally located mailbox from any remote location. When an IMAP client accesses a remote mailbox, it can perform operations on the messages stored there without necessarily having to download any of them. By default, only mail headers are transferred to the client (to save bandwidth). The body of the message is downloaded only when a message is selected for viewing, and it is not deleted from the server. Messages can be marked with various status flags (e.g., read vs. unread), and this data is stored along with the message (and accordingly appears during subsequent IMAP sessions). An IMAP client can also access multiple mailboxes and mailboxes shared among a group of users.

The functional differences between the two protocols will become clear with an example. Suppose that user chavez's mail is delivered to a system named poffice. If her mail program supports POP, chavez can transfer messages that arrive on poffice to a different system, most likely her usual workstation. Under this POP configuration, chavez's mailbox on poffice serves as a message store, and the mailbox on her local system is her "real" one. She can choose to retain or delete the downloaded messages on the server (via a configuration option). If she chooses the latter, the next time she connects to the message store, only messages that arrived since her previous access will be present in the mailbox.

The POP approach can be beneficial for retrieving mail from remote dialup locations, because it minimizes the time you must be connected to the mail server.

In contrast, with IMAP, user chavez's "real" mailbox is on poffice itself, and she can access it from any system within the network. When she connects to it via a mail program running IMAP, she will see all of the messages in her mailbox. She will be able to distinguish new messages from those she's already read (she may even have some messages that are marked as deleted but haven't yet been actually discarded). She can also save messages from her default mailbox known as her "inbox" to other mail folders that she has created (which frequently reside in the directory tree under ~chavez/Mail on the server).

There are many sources of POP and IMAP daemons, and many Unix vendors provide one with the operating system (or as a optional package). The following list gives the paths to the daemons provided by various Unix versions we are considering:

In addition, there is a widely used POP/IMAP server package available for free from the University of Washington (http://www.washington.edu/imap/). In fact, some of the vendor-provided versions are simply this package.

Usually, both POP and IMAP daemons are controlled by inetd, using /etc/inetd.conf configuration file entries like these:

pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d imap stream tcp nowait root /usr/sbin/tcpd imapd

Both daemons should use tcpwrappers for access control. There may be other POP- and IMAP-related entries in some inetd configuration files, corresponding to other versions/configurations of the protocols.

The services corresponding to these protocols are defined in /etc/services with entries like these:

pop3 110/tcp # Post Office Protocol - Version 3 pop3 110/udp # Post Office Protocol - Version 3 imap 143/tcp imap2 # Internet Message Access Protocol imap 143/udp imap2 # Internet Message Access Protocol

You may also find entries for POP2 (generally port 109) and IMAP version 3 (port 220), which is no longer in wide use, as well as some SSL-enabled variants. The latter are preferable to avoid sending plain-text passwords across the network.

If you add POP or IMAP daemons to a system, don't forget to verify that the required entries in /etc/services and /etc/inetd.conf are present and active (i.e., not commented out). You may also need to modify the entries in some cases (most often true for the inetd configuration entries).

Ordinarily, both POP and IMAP rely on passwords for userauthentication. Some particularly poorly implemented clients require the password to be reentered for each IMAP operation, which can be very tedious. In these cases, it may be preferable to use host-level equivalence (hosts.equiv-type) authentication. Most IMAP daemons can configured to do this by creating a link from the IMAP server file to /etc/rimapd. See Section 7.6 for more information about inetd, /etc/services, and host-level equivalence authentication.

Carnegie Mellon University has developed a much more sophisticatedIMAP daemon facility known asCyrus. This package is designed to be efficient and secure even for very large sites. Cyrus has a number of interesting characteristics:

• Users are not allowed to log in to mail server systems. The actual files are directly accessible only to the Cyrus processes, via a special user account created for the facility. Users can access mailboxes only via mailer programs implementing IMAP (or POP).

• The mailbox format is nonstandard and designed for scalability. Individual messages are stored in discrete files. In addition, user mailboxes are protected with access control lists.

• User authentication can be performed in any of several ways: standard Unix passwords, Kerberos, PAM.

• Disk-use quotas can be imposed on user mailboxes, if desired.

For more information about IMAP in general and the Cyrus package, see the book Managing IMAP by Dianna Mullet and Kevin Mullet (O'Reilly & Associates).

9.3.1 Setting Up User Agents to Use POP and IMAP

Many mailer programs support POP and IMAP access to remote mailboxes, among them mutt, pine, the mh family, and Netscape. In this section, we will briefly consider how to configure some of them to use a remote mailbox. Unlike the settings for PGP and mail encryption, settings for POP and IMAP are user-specific and thus typically reside in the user-specific configuration file.

mutt support for POP and IMAP must be selected at compile time (use the -v option and look for USE_POP and USE_IMAP). The following configuration file entries set up mutt as a POP client.

set pop_host=poffice set pop_user=chavez set pop_pass=xxx set pop_delete=yes Delete messages on server after downloading.

In this case, this user connects to host poffice via POP as user chavez (her mailbox is in the usual location), using the specified password for authentication (obviously, including this third entry requires care with the configuration file permissions). Once a message is downloaded from the server, it is deleted from the mailbox. mutt's G command is used to initiate mail retrieval via POP.

Here are the entries needed to connect to the same server as the same user using IMAP:

set spoolfile={poffice}INBOX Where new messages arrive. set folder={poffice}Mail Saved mail directory. set imap_user=chavez Connect as this user . . . set imap_pass=xxx . . . with this password. set imap_checkinterval=900 Check for new mail every 15 minutes. set imap_passive=no Open new IMAP connections as required.

The first entry specifies the mail spool file as the usual user mailbox on the specified server (the meaning of the keyword INBOX). The second entry defines another mail location a namespace, in IMAP parlance as ~/Mail (where ~ refers to the user account used for access, specified here as chavez in line 3).

pine also uses very simple configuration file entries for these purposes. Only one entry is needed to configure the POP client:

inbox-path={poffice/pop3}

This makes the default mailbox for pine the user's remote mailbox on the poffice system (accessed with the POP3 protocol), using the same username as on the local system.

The entries for an IMAP server are very similar:

inbox-path={poffice/user=chavez}inbox folder-collections={poffice/user=chavez}Mail/[]

The first entry specifies the user's default mailbox as the mailbox corresponding to user chavez on system poffice (no protocol is specified because IMAP is the default). The second entry defines the mail folder collection to be the directory poffice:~chavez/Mail.

Netscape can also be configured to use POP or IMAP to retrieve or access mail on a remote system, and it is a very popular choice for PC and Macintosh users. The relevant settings are reached by selecting the Edit Preferences menu path and then clicking on the Mail Servers item under Mail & Newsgroups. The Incoming Mail Servers area of the resulting dialog lists any configured remote mail servers. You can set one up by clicking the Add or Edit button as appropriate.

Figure 9-4 illustrates the dialog used to configure a POP server.

The fields in this dialog are generally self-explanatory. The Server Type field allows you to select the protocol for remote mail access (POP is chosen here). The POP tab lets you specify whether to leave messages on the server or delete them after downloading.

The corresponding dialogs for an IMAP server are illustrated in Figure 9-5. The General tab again lists the server name, protocol, username, password retention setting, and mail check interval (if any).

The IMAP panel, shown on the right in the figure, includes settings related to offline downloads, using an SSL-secured session, and handling of deleted messages. When a message is deleted with IMAP, the message is marked as such, but it is retained on the server by default; it actually goes away when the mail folder is "cleaned up" (known as "expunging"). With these options, a user can select how deleted messages are treated and whether/when folders are automatically expunged.

The dialog's Advanced tab lets you specify IMAP namespaces to be accessed on this server. It comes into play only when namespaces other than the defaults are in use.