Before rushing to install a pull mail server, you must understand the differences between the major pull mail server protocols and the individual products that are available in this arena. In some cases, it doesn't much matter which protocol or server you select, but in others, the differences can be quite important.
The two major pull mail protocols are POP and IMAP. Although some more exotic protocols also exist, these two protocols dominate the field. Most modern mail clients support one or both of these protocols, and a few support more exotic protocols. Both POP and IMAP perform basically the same task: Client programs connect, retrieve e-mail, and disconnect. The client programs display a list of available messages and enable users to read these messages, archive them, reply to them, and so on.
Note POP and IMAP are both pull mail protocols, so a mail client can retrieve mail from the POP or IMAP server. To send mail, a mail client uses another protocol—typically SMTP. Small networks are often configured such that mail clients use the same computer for an outgoing SMTP server that they use for incoming POP or IMAP mail. Larger networks sometimes use physically separate computers for these two functions in order to better spread the mail-delivery load. There can also be security advantages to separating these two functions, as well. For instance, pull mail servers use passwords that might be compromised. Running your network's world-accessible SMTP server on a system that doesn't have many ordinary users minimizes the risk that it could be abused by a cracker using a stolen password. You can block external access to your pull mail server, minimizing the chance that it could be abused.
Although they fill roughly the same role, POP and IMAP aren't identical protocols.
Some of their important differences include:
Mail Storage POP users typically retrieve their messages from the server and then immediately delete the messages from the server. Long-term archival of messages occurs on client systems. IMAP, on the other hand, was designed to enable users to store messages in folders on the IMAP server computer. As a result, an IMAP server may need to devote more disk space to user mail directories than a POP server. IMAP may also require more network bandwidth in the long run, although IMAP's partial retrieval options (which are described next) can mitigate this need or even give IMAP an advantage, depending on how your users interact with their mail systems. One big advantage to IMAP's system is that it enables users to access mail using different mail client programs or even different computers, without having to copy mail files between systems.
Partial Retrieval Options POP mail retrieval is all-or-none. Clients can either retrieve a message in its entirety (using nothing but a number to identify it) or leave the message on the server. IMAP is more flexible; it supports retrieving various parts of a message, such as its header separately from its body. Therefore, with IMAP, users can delete messages they know they don't want without retrieving the bulk of the message text. With obvious spams and worms, this feature can save your network substantial amounts of bandwidth.
Client Support Although POP and IMAP are both widely supported, POP support is more common than that for IMAP. If your users already have preferred mail clients, you may want to check their configuration options to learn what pull mail protocols they support.
Your decision of whether to support POP, IMAP, or both will boil down to a study of these factors. As a general rule, IMAP is the more flexible protocol, but you may prefer to force mail off of the mail server and onto clients as quickly as possible. In that case, using POP makes sense. If your users frequently use multiple computers, IMAP has a certain advantage in convenience for users. This advantage may be negated if users must call in on slow dial-up lines, though; in that case, local mail storage will result in quicker mail reading, at least after the first reading.
Both POP and IMAP are available in several different versions. In 2003, the latest versions are POP3 and IMAP4. Earlier versions of both are still in use at some sites, and you may need to support earlier versions for some older clients. In the case of IMAP, support for earlier versions is usually automatic. POP2, though, uses a different port (109) than does POP3 (110). IMAP uses port 143.
Pull mail servers tend to be much simpler than push mail servers. Essentially, pull mail servers are local mail clients, much like Pine or ELM. The difference is that they deliver mail to another computer using their own pull protocols instead of displaying mail to users who are logged in on the console, via SSH or the like. As a result, pull mail servers tend to lurk almost unnoticed. Nonetheless, several different pull mail servers are available for Linux:
UW IMAP Despite its name, the University of Washington IMAP server (http://www.washington.edu/imap/) supports POP2, POP3, and IMAP. The POP servers use the IMAP server behind the scenes. This set of servers is extremely common; it ships with most Linux distributions, usually in a package called imap or uw-imapd. The IMAP server stores user mail folders in users' home directories, which can be awkward if users also log into their accounts and store nonmail files there.
Cyrus IMAP Like UW IMAP, Cyrus IMAP
(http://asg.web.cmu.edu/cyrus/imapd/) supports more than just IMAP. Specifically, Cyrus IMAP supports IMAP, P0P3, and a Kerberos-enabled P0P3 variant (KPOP). This server stores IMAP mail folders in a proprietary file format in its own directory tree, so it can be a good choice if users store nonmail files in their home directories.
nupop This server is designed for quick and efficient handling of P0P3 requests. Its goals are accomplished, in part, by discarding support for IMAP and other protocols. You can learn more at http://nupop.nuvox.net.
popa3d This server, like nupop, is a POP-only server designed for efficiency. Its website (http://www.openwall.com/popa3d/) also emphasizes the developers' attention to security.
Courier The Courier mail server (http://www.courier-mta.org) is an integrated set of SMTP, POP, and IMAP servers. Although the Courier SMTP server isn't very popular in Linux, the IMAP server can be installed separately, and it has a modest following.
Qpopper This P0P3 server was originally a commercial product released by the same people who developed the popular Eudora client and server packages. With version 4.0, though, Qpopper has gone open source. You can learn more at http://www.eudora.com/qpopper/.
qmail-pop3d This P0P3 server ships with the qmail SMTP server (http://www.qmail.org). As such, it can be a good choice if you use qmail as your SMTP server, but isn't a good choice if you use another SMTP server.
One critical consideration when picking a pull mail server is the message file formats the server supports. All of the major mail servers covered in depth in this chapter (sendmail, Postfix, and Exim) use a format known as mbox, in which messages in a mail folder are stored in a single file. Typically, SMTP servers or their helper programs store users' files in /var/spool/mail/usemame. IMAP servers that use mbox format use files of the same type for mail directories in users' home directories, subdirectories thereof, or special IMAP mail server directories.
The qmail server, by contrast, stores its incoming mail in another format: a maildir. The maildir format devotes one directory to each mail folder and puts each message in its own file. Typically, incoming maildirs are stored in users' home directories. IMAP servers that use maildirs typically store them in users' home directories. Although qmail uses maildirs by default, it can be configured to use the mbox format. Similarly, Postfix and Exim can both be configured to use maildirs.
The UW IMAP, Cyrus IMAP, and Qpopper servers all use mbox format for incoming mail. UW IMAP also uses mbox for IMAP mail folders. Cyrus IMAP uses its own unique format for mail folders. The nupop, Courier, and qmail-pop3d servers all use the maildir format. If a given pull server looks appealing but uses the "wrong" mail storage format compared to your SMTP server, you'll have to replace your SMTP server, reconfigure your SMTP server, or pick a different pull mail server.
One issue you should consider when installing and configuring a pull mail server is password security. In a typical configuration, the traditional POP and IMAP servers require password authentication—users must enter their usernames and passwords. Most servers authenticate users against the normal Linux username and password database. The basic protocols deliver the username and password over an unencrypted link. As a consequence, a miscreant with the appropriate access can sniff the password, as described in Chapter 18, "System Security." Some servers support encrypted variants of the standard protocols, but these variants require support in the mail clients. Another approach is to use the Secure Shell (SSH) to tunnel the pull mail protocol over an encrypted link—that is, to encrypt the pull mail data and pass it over an encrypted connection. This approach requires configuring SSH on the server and on all the clients, though. If you don't want to go to this effort, you may want to consider setting aside special mail-only accounts and instruct users to create unique passwords for these accounts. Ideally, you can create these accounts on a dedicated pull mail server computer. This practice will at least minimize the damage that a miscreant might do if pull mail passwords are compromised. You may also want to restrict access to your POP or IMAP ports using firewall rules, TCP Wrappers, or xinetd access restrictions, as described in Chapter 20, "Controlling Network Access."
Was this article helpful?