Email is one of the most widely used services on the Internet. Red Hat Linux offers many ways to serve and access email, whether you are a desktop user or a system administrator.
This chapter looks at popular email protocols that are in use today and some of the programs designed to deal with email.
Email, like other network services, uses a variety of protocols. These protocols allow different machines, often running different operating systems and using different email programs, to communicate with one another via email.
The following protocols are the most commonly used to transfer email from system to system.
The Internet Message Access Protocol (IMAP) is a method used by email client applications to access remotely stored messages. When using IMAP email messages remain on the remote mail server where users 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 for receiving attachments. 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 used by those who access their email using multiple machines. 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 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 /usr/sbin/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.
The Post Office Protocol (POP) allows email clients to download 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. 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 the session.
POP is a much simpler protocol than IMAP, since fewer commands are sent between the client and the server.
POP works best for users who only have one system to read email with since they download their messages to that machine. 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 10 for more information concerning Kerberos authentication.
RPOP — POP3 with RPOP authentication, which uses 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 installs POP2 (ipop2) and POP3 (ipop3) daemons in the /usr/sbin/ directory.
While the IMAP and POP protocols involve allowing a user to be able to receive 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, on its way toward its final destination. Email servers attempting to move a message between one another also use 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 served by a particular mail server using the VRFY command or expand a mailing list using 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 8.0 uses Sendmail (/usr/sbin/sendmail)as its SMTP program by default. However, an easier to use application called Postfix (/usr/sbin/postfix) is also available for use. the Section called Mail Transfer Agent for more on this topic.