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.

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.

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.

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.