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, due to the fact that fewer commands can be sent between the client and the server. POP is also somewhat more popular, although most major email clients can use either protocol quite well.

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 network containing your mail server, although IMAP can now be configured to store messages locally so that you can view them when disconnected from the network.

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 sending the password in plaintext.

• KPOP — POP3 with Kerberos authentication. See Chapter 8 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, Mozilla Mail is an excellent 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. Or, two email servers attempting to move a message between one another utilize SMTP so they can communicate, even if they are totally different platforms.

SMTP uses port 25 on the server for its 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, SMTP does not require authentication in its most basic form. This has made possible a lot of spam, due to the fact that a non-local user could use your system to send or relay mail to entire lists of recipients, using your system's resources and bandwidth to deliver the junk mail. Modern SMTP applications have gone to great length 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 noticeable extension concerns the addition of SMTP Authentication through the AUTH command as outlined in RFC-2554. Another widely used SMTP extension is detailed in RFC-2034, which discusses the use of dot-separated, standardized error codes to be used 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 get a handle on how SMTP communications occur.

Red Hat Linux uses Sendmail as its SMTP program by default, although various other applications are available that have many of the same features but are easier to use, such as Postfix. Many email client applications connect to an SMTP server directly to send messages, although you can configure a locally running SMTP service to deliver your email for you, either directly to the final destination or to a central email server to then be forwarded on.