Section 13.4. Configuring POP and IMAP Servers

13.4. Configuring POP and IMAP Servers

SMTP servers tend to attract a lot of attention; after all, Internet mail delivery runs mostly over SMTP. Still, pull mail protocolsPOP and IMAPare just as important in many situations. Typically, users configure their desktop computers' email clients to contact POP or IMAP servers in order to read their incoming mail. Knowing how to handle these servers' configurations is therefore quite important. In the simplest cases, this requires launching the servers and setting authentication options. Most sophisticated servers provide additional options, though.

13.4.1. Launching POP and IMAP Servers

POP and IMAP servers vary in how they're launched. For the popular and simple UW IMAP, the typical method of launching and controlling the server is via a super server. (This method doesn't scale up very well, though, so for a busy server system, you might want to look into launching the server via a SysV startup script, or even running a server that uses this configuration by default.) On distributions that use xinetd as the super server, the UW IMAP package typically ships with one or more files in /etc/xinetd.d. Typically, each file starts the server to handle a single protocol (POP or IMAP, sometimes with variants for different protocol versions or to add encryption). A typical entry looks like this:

service imap {   socket_type = stream   protocol    = tcp   wait        = no   user        = root   server      = /usr/sbin/imapd   disable     = yes }

Most distributions disable most or all of the servers by default, by setting the disable = yes option. To enable the server, you must delete this line or change it to read disable = no. You must then restart xinetd, typically by typing /etc/init.d/xinetd restart or something similar. Thereafter, xinetd responds to incoming requests for the protocols you've enabled. If you want the server to respond to multiple protocols, you must be sure to enable them all.

If your distribution uses inetd as a super server, you may need to add one line to /etc/inetd.conf for each protocol you want to use. These lines set the same options that you'd set in the xinetd configuration:

imap stream tcp nowait root /usr/sbin/tcpd imapd

This example uses tcpd (that is, TCP Wrappers) to manage the server. You can therefore use the TCP Wrappers configuration files, /etc/hosts.allow and /etc/hosts.deny, to provide access restrictions based on IP addresses. (You can enable similar restrictions using xinetd's built-in features if you use it as your super server.)

Some POP and IMAP servers, such as Dovecot, are more commonly launched via their own SysV startup scripts. To launch such servers on a one-time basis, you typically pass the start option to their startup scripts:

# /etc/init.d/dovecot start

To configure the server to start automatically when you boot the computer, you must set up your SysV links appropriately. Many distributions provide tools to help with this task, such as chkconfig (used by Fedora, Mandrake, and SuSE, among others) or rc-update (used by Gentoo). Consult distribution-specific documentation for more information on these tools.

13.4.2. Setting Authentication Options

The UW IMAP server provides no authentication options, in the sense of command-line arguments or configuration file entries, that affect authentication. (In fact, UW IMAP has no main configuration file.) UW IMAP, though, does use the Linux PAM system for authentication. As such, you can edit the IMAP PAM configuration files to change how IMAP authenticates users. Typical UW IMAP installations actually provide two PAM files, one for POP and one for IMAP: /etc/pam.d/pop and /etc/pam.d/imap. Thus, you can use different authentication options for POP as for IMAP. Some POP and IMAP servers call their PAM configuration files something else; for instance, Dovecot uses /etc/pam.d/dovecot, which controls both POP and IMAP access.

If your server uses the local Linux password database for POP and IMAP authentication, the default UW IMAP PAM configuration files should work fine. If you want to use another authentication tool, though, such as an NT domain controller or a Kerberos server, you need to modify the PAM configuration files. This topic is described in detail in Appendix A.

Using Kerberos, or any other encrypted network authentication tool, via a PAM configuration encrypts the authentication between the POP or IMAP server and the authentication database, but not between the POP or IMAP server and its client. If you want to encrypt the authentication between the POP or IMAP server and its client, you must either tunnel the protocol in some way (say, via SSH) or use a server and client that support an encrypted exchange natively. The encrypted versions of POP and IMAP are commonly referred to as POPS and IMAPS, respectively.

More sophisticated POP and IMAP servers, including Cyrus IMAP and Dovecot, support their own authentication tools instead of or in addition to PAM. These servers often include configuration options to enable the authentication methods you want to use, so consult their documentation for details.

13.4.3. Additional Options on Advanced Servers

UW IMAP is easy to set up and configure, but it's inflexible; you can't change features such as where it looks for IMAP folders except by editing the source code and recompiling it. Using more sophisticated servers is, of course, an option; however, doing so opens up many additional options, some of which can be tricky to configure. As an example, consider Dovecot (http://www.dovecot.org), which is rising rapidly in popularity. This server uses the /etc/dovecot.conf configuration file to hold options, which take the form:

option = value

For the most part, the default options work well; however, you might want to peruse the file or the Dovecot documentation to learn about its configurable features. As with many Linux configuration files, dovecot.conf uses hash marks (#) as comment characters, and the default file is well commented.

Dovecot provides options relating to protocol support (protocols, which takes one or more values such as imap and pop), SSL options, an option to disable cleartext authentication (disable_plaintext_auth), the default mailbox format to use (default_mail_env), options to enable special authentication methods, and so on.