IMAP

The Internet Message Access Protocol (IMAP) is a method used by email client applications to access remotely stored messages. When using IMAP, commonly called IMAP4 after the version of the protocol used, the email messages remain on the remote mail server, where the user can read or delete them and create, rename, or delete mailboxes to store the email.

In addition, IMAP is fully compatible with important Internet messaging standards, such as the Multipurpose Internet Mail Extensions (MIME), to allow attachments to be received. Many email clients that use IMAP can also be configured to cache a copy of the messages locally, so that you can browse previously read messages when you are not directly connected to the IMAP server.

IMAP is primarily utilized by users that may access their email using multiple machines, as messages are stored in a central location and can be accessed by any system with an IMAP mail client and a connection to the remote IMAP server. Also, users that connect to the Internet or a private network via a low-bandwidth connection often use IMAP because only the email header information is pulled off at first. This allows them to defer the downloading of messages containing large attachments until a time when their limited bandwidth is not in use. In the same way, email that the user does not want can be deleted without viewing the message body, saving the need to even download it through their network connection.

The Request for Comment (RFC) documents that cover IMAP contain the assorted details and specifics about how the protocol is designed to work. RFC-1730 first defined the way IMAP is used in version 4, but RFC-2060 discusses the current IMAP implementation used with many IMAP servers, called version IMAP4rev1.

The imap package in Red Hat Linux allows users to connect to your system and receive their email using IMAP. Secure IMAP connections are supported through Secure Socket Layer (SSL) technology built into the imapd daemon, allowing it to use the /usr/share/ssl/certs/imapd.pem certificate file. The stunnel program is not required to provide SSL-encryption for IMAP connections, though it can be used. See the Section called Secure Email Servers for more information concerning these two encryption options.

Other free, as well as commercial, IMAP clients and servers are available, many of which extend the IMAP protocol and provide additional functionality. A comprehensive list can be found at http://www.imap.org/products/longlist.htm.

POP

The Post Office Protocol (POP) allows email clients to pull off email from remote servers and save those messages on their local machine. Most POP email clients are automatically configured to delete the message on the email server after it has been successfully transferred to the client's system, though this can usually be changed.

To connect to a POP server, the email client opens a TCP connection to port 110 on the server. At the time the connection is made, the POP server sends the POP client a greeting, after which the two machines send each other commands and responses specified in the protocol. As part of this communication, the POP client is asked to authenticate itself in what is called the Authentication State, where the user's username and password are sent to the POP server. If authentication is successful, then the POP client moves on to the Transaction State, where commands like LIST, RETR, and DELE can be used to list, download, and delete the messages from the server, respectively. Messages set to be deleted are not actually removed from the server until the POP client sends the QUIT command to end the session. At this point, the POP server enters the Update State, where it deletes the flagged messages and cleans up any resources remaining from this session.

POP is a much simpler protocol than IMAP, since fewer commands are sent between the client and the server. POP is also slightly more popular, although most major email clients can use either protocol.

Most POP users only have one system that they use to read email, and they download their messages to that machine for storage. POP also works well if you do not have a constant connection to the Internet or the network containing your mail server.

Several RFCs cover the POP protocol, but RFC-1939 defines the basic outline of POP3, the current version.

Occasionally, you may run into lesser-used POP protocol variants:

• APOP — POP3 with MDS authentication, where an encoded hash of your password is sent from the email client to the server rather then sending the password in plain text.

• KPOP — POP3 with Kerberos authentication. See Chapter 11 for more information concerning Kerberos authentication.

• RPOP — POP3 with RPOP authentication, which utilizes an ID issued per user, similar to a password, to authenticate POP requests. However, this ID is not encrypted, so RPOP is no more secure than standard POP.

Many POP servers, clients, and assorted other applications are available with Red Hat Linux. If you prefer a graphical email client, either Mozilla Mail or Ximian Evolution is a good choice. In addition, other email utilities, such as Fetchmail, can retrieve email via POP. If you are using your Red Hat Linux system as a mail server, the imap package contains POP2 (ipop2) and POP3 (ipop3) daemons in the /usr/sbin/ directory.

SMTP

While the IMAP and POP protocols involve allowing a user to be able to receive and read their email, the Simple Mail Transfer Protocol (SMTP) is used to send email. Outgoing email uses SMTP to move from the client's machine to the server, where it moves along toward its final destination. Two email servers attempting to move a message between one another also utilize SMTP to communicate.

SMTP uses port 25 on the server for communication. A basic SMTP exchange begins with the connecting system issuing a MAIL From: <email-address> command to initiate exchange. The receiving system responds with a 250 message to acknowledge receipt of the first command. Then, the connecting system hands the email addresses to receive the message to the receiving system, followed by a DATA message. This tells the receiving system that the next part of the communication will be the actual body of the email message. When the connecting system is finished with the email message, it places a single dot (.) on a line. At that point, the message is considered sent.

SMTP also handles cases where email needs to be forwarded between systems, when the receiving system knows where to send the message. The protocol can verify that certain users are indeed served by a particular mail server (the VRFY command) or expand a mailing list (the EXPN command). Email can also be relayed between two SMTP servers, if both systems permit such activity.

Unlike IMAP and POP, the SMTP protocol does not require authentication. This means that SMTP servers can allow anyone on the Internet to use your system to send or relay mail to large lists of recipients. It is this characteristic of SMTP that makes spam possible. Modern SMTP applications attempt to minimize this behavior by restricting relaying and allowing only known hosts to send email.

RFC-821 outlines the basic behavior of SMTP, but several SMTP extensions, made possible by RFC-1869, have added additional functionality to SMTP over the years by making new commands available. By initiating a conversation with an SMTP server with an EHLO command rather than HELO, the connecting server can identify itself as one that supports SMTP extensions. The receiving server answers with a 250 line containing the various SMTP extensions it supports. Then, the connecting server can use the supported extensions as it wishes to accomplish the goals of the communication.

One extension adds SMTP Authentication through the AUTH command as outlined in RFC-2554. Another widely used SMTP extension, detailed in RFC-2034, discusses the use of dot-separated, standardized error codes for use between SMTP applications. Reading the various RFCs that involve SMTP provides a background to the way email moves around the Internet. In addition, you can connect to an SMTP server via telnet by specifying port 25, such as telnet localhost 25. Executing a few commands and sending a mail manually is a good way to understand how SMTP communications work.

Red Hat Linux 7.3 uses Sendmail as its SMTP program by default. However, easier to use applications, such as Postfix, are also installed by default with the operating system.