IMAP, fully documented in
RFC 3501, was designed to provide a robust, mobile mail delivery and access
mechanism. For more detail on the protocol and how it functions on the network
layer, or for additional information on the numerous specification options,
please consult the RFC documentation.
POP and IMAP tend to be grouped together or
compared, which is a bit unfair since they are dissimilar in many ways. POP was
created as a simple mail delivery vehicle, which it does very well. Users
connect to the server and obtain their messages, which are then, ideally,
deleted from the server. IMAP takes an entirely different approach. It acts as
the keeper of the messages and provides a framework in which the users can
efficiently manipulate the stored messages. While administrators and users can
configure POP to store the messages on the server, it can quickly become
inefficient since a POP client will download all old messages each time the mail
is queried. This can get messy quickly, if the user is receiving any quantity of
email. For users who do not need any kind of portability, or receive little
email, POP is probably an acceptable choice, but those seeking greater
functionality will want to use IMAP.
Once
you've decided that IMAP is for you, there are two primary options. The two main
flavors are Cyrus IMAP and the University of Washington IMAP server. Both follow
the RFC specification for IMAP and have their advantages and disadvantages. They
also use different mailbox formats and therefore cannot be mixed. One key
difference between the two is found in Cyrus IMAP. It does not use
/etc/passwd for its mail account database, so the administrator does not
have to specially add mail users to the system password file. This is more
secure option for system administrators, because creating accounts on systems
can be construed as a security risk. However, the ease of configuration and
installation of UW IMAP often makes it more appealing. In this chapter, we'll
primarily focus on the two most common IMAP servers: UW IMAP, because of its
popularity and ease of installation, and Cyrus IMAP, because of its additional
security features.
Once the
server software has been downloaded and decompressed, it can be installed.
However, because of UW-IMAP's large portability database, it does not support
GNU automake, meaning that there isn't a configure script. Instead, a Makefile that relies on user-specified parameters is
used. There are many supported operating systems, including a number of Linux
distributions. Here's a list of a few of the supported Linuxes
distributions:
# ldb Debian Linux # lnx Linux with traditional passwords and crypt( ) in the C library # (see lnp, sl4, sl5, and slx) # lnp Linux with Pluggable Authentication Modules (PAM) # lrh RedHat Linux 7.2 # lsu SuSE Linux # sl4 Linux using -lshadow to get the crypt( ) function # sl5 Linux with shadow passwords, no extra libraries # slx Linux using -lcrypt to get the crypt( ) function
The lrh version
will probably work on newer Red Hat versions as well. If your distribution isn't
listed, try one of the matching generic options. lnp is a good guess
for most modern versions of Linux.
To begin the installation of the Cyrus server, download and
decompress the latest version. You will need to download both the IMAP and SASL
packages.
SASL is the authentication mechanism used by
Cyrus IMAP, and will need to be configured and installed first. It is easily
built using the standard "configure-make" order.
vlager# cd cyrus-sasl-2.1.15 vlager# ./configure loading cache ./config.cache checking host system type... i686-pc-linux-gnu . creating saslauthd.h Configuration Complete. Type 'make' to build. vlager# make make all-recursive make[1]: Entering directory `/tmp/cyrus-sasl-2.1.15'
Assuming the compile is completed without failure and you've
successfully executed the make install, you can now proceed to configuring and
installing the Cyrus IMAP server itself.
