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.
Protocols
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.
IMAP
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.
POP
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.
SMTP
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.