CHAPTER 26. Internet Mail Protocols: POP3, SMTP, and IMAP

SOME OF THE MAIN TOPICS IN THIS CHAPTER ARE

---

How SMTP Works 436

Putting It All Together 442

The Post Office Protocol (POP3) 443

The Internet Message Access Protocol Version 4 (IMAP4) 445

Although protocols such as IP are responsible for transporting and routing traffic on the Internet, application protocols such as SMTP, IMAP, and POP3 provide the message exchanges needed to make client/server applications available over the network. The following list briefly explains these protocols:

The Simple Mail Transfer Protocol (SMTP) is used to transfer mail messages from a client to an SMTP server, and to transfer those messages from one SMTP server to another.

The Post Office Protocol (POP3) is a client mail application used to retrieve messages from an SMTP server. This protocol is often referred to as POP3 because it is the third version of the protocol.

The Internet Message Access Protocol (IMAP) is used to store email messages on a server. A client that supports IMAP can view the headers of email messages and decide to download messages, or just read them and leave them on the server. IMAP also enables the user to create folders on the server that can be used to store messages. This protocol is often referred to as IMAP4, because it is the fourth version of the protocol.

In this chapter, you’ll learn about the basic functions provided by these three protocols.

How SMTP Works

As an application protocol, SMTP relies on the error-detection and correction mechanisms of the underlying transport protocols and does not implement these sorts of functions in the SMTP protocol. For example, TCP uses sequence numbers to keep track of TCP segments sent and acknowledged. Those that are not acknowledged within a timely fashion are retransmitted. Thus, SMTP, using TCP as a transport protocol, doesn’t have to worry about this sort of thing. SMTP has also been implemented using other transfer protocols, including NCP, NITS, and X.25. For purposes of this text, I will be focusing on SMTP using the TCP Transport service, because that is the most common model you are likely to see. Because SMTP is an application protocol, it’s associated with a port number just like FTP, Telnet, and other applications that make up the TCP/IP suite. The port generally used for SMTP is TCP port 25.

SMTP is used to send email from a client to an SMTP server and for SMTP servers to exchange mail. Other protocols, such as POP3 and IMAP, are used by clients to retrieve mail from mailboxes that reside on SMTP servers. SMTP is not used for that purpose, as you can see in Figure 26.1.

Figure 26.1. SMTP is used to send and receive email. SMTP is used primarily to upload email to the server, whereas POP3 is generally used to download mail.

In this figure, you can see that Computer A sends outgoing email to its local SMTP server operated by the Internet Service Provider (ISP). Computer A uses the POP3 protocol (Post Office Protocol) to check for and retrieve messages stored on the server. If Computer A needs to send an email to Computer B, the message travels first through SMTP to the local SMTP server. This server looks up the mail server for the domain in which the recipient on Computer B resides and sends the message, again using SMTP, to Computer B’s SMTP server. When Computer B decides to check messages, it uses POP3 and gets the email sent by Computer A. Note that if either computer wants to send email to Computer C, then still another SMTP server becomes involved.

Note, however, that there isn’t real centralization. SMTP servers communicate among themselves directly and do not go through any central clearinghouse. It’s possible that a mail message will take a route through several SMTP servers to reach the eventual mailbox that is the destination of the email. When a client initially starts a session with an SMTP server, it can give the server a source-route (list of hosts) through which the message should travel to get to its destination. This is called a forward-path. In addition, the client can give the server a reverse-path, which is a source-route to return error messages to the client if something happens during the transmission of the email message.

Because it is a decentralized system, the operation is simplified. The failure of an SMTP server, here and there, doesn’t affect the entire Internet. The only people who get to complain are those who use the downed SMTP servers for their email.

When mail is downloaded from an SMTP server using POP3, the messages are deleted from the SMTP server’s database and stored locally on the user’s computer. If you delete the email messages stored locally on your computer, they are gone forever!

The SMTP Model

RFC 2821 recognizes that an SMTP server would have to service both local clients and relay mail messages to other SMTP servers when the destination is not a client of the original server. In the original RFC, names were given for the different processes involved, depending on who is doing what to whom. For example, SMTP applications can act as either of the following, depending on the direction of the flow of information:

Sender-SMTP—The client establishes a two-way (full-duplex) session with the local SMTP sever.

Receiver-SMTP—The SMTP server receives commands from the Sender-SMTP. The Receiver-SMTP process can be an SMTP server that can deliver the message to its recipient’s mailbox or to another SMTP server.

To bring these definitions up-to-date using more modern terminology, the Sender-SMTP is now referred to in the RFCs as the SMTP Client (Sender-SMTP) and the SMTP Server (Receiver-SMTP).

Note that when a message passes through several SMTP servers, one server becomes the SMTP Client and the server to which the message is being sent becomes the SMTP Server. The SMTP Client process does not always indicate the original client that created the email message in the first place.

In fact, there are four types of SMTP server roles that are dependent on the services provided:

Originator—A server that originates an email message and sends it out onto the Internet (or an intranet).

Delivery—A server that receives email messages and stores them for the client to retrieve.

Relay—An SMTP server that relays an email message from one SMTP server to another, and is not the originator or delivery SMTP server.

Gateway—A server that acts as a go-between SMTP and another messaging system. The gateway may modify the contents of the SMTP message to accommodate the other messaging system.

Most of the original definition of SMTP from RFC 821 remains intact. A few other RFCs over the years have added minor changes to the protocol, but it has remained basically a system for request/reply messages, or in the words of the RFC, a lock-step method. A request is made and a reply is sent. In the original version, a client sends a command to the server and the server responds with a single reply. The connection between the client and the SMTP server is a simple two-way channel (using the single TCP port 25).

SMTP Service Extensions

SMTP was developed more than a decade ago. Over time it has been necessary to provide additional functionality to the protocol, called service extensions. These were first added to SMTP by RFC 1425, “SMTP Service Extensions.” Further RFCs added to these additional services, which are now covered by RFC 2821. An additional extension has been added by RFC 2920, “SMTP Service Extension for Command Pipelining.”

Service extensions are negotiated between SMTP servers to find out which extensions are supported by each server. There are four basic categories of service extensions:

Delivery

Authentication and Security

Command Pipelining

Enhanced Status Codes

The Internet Assigned Numbers Authority (IANA) is responsible for maintaining a list of SMTP extensions. You can consult the IANA at www.iana.org.

SMTP Commands and Response Codes

The first command that the Sender-SMTP client sends is either the HELO command or the EHLO command. EHLO is now the preferred command and is part of the basic service extensions. If an SMTP server does not support additional service extensions, it will respond with an error message indicating a syntax error.

This is the basic syntax for SMTP commands:

<command> <arguments> <CRLF>

In this syntax, <CRLF> indicates that a carriage-return followed by a line-feed character is used to signal the end of the command line.

In the following commands, the term forward-path is a list of hosts the message travels through to reach its destination. The term reverse-path is used to indicate how to get back to the sender of the email, which can be helpful when returning error or other informational messages.

The basic SMTP commands include the following:

HELO—This command (or the next one in this list) is sent by the Sender-SMTP client to the SMTP server to begin the mail transfer session. The argument to this command is the hostname of the Sender-SMTP computer.

EHLO—This is now the preferred command that replaces the HELO command and indicates that the Sender-SMTP client wants to use SMTP extensions. This command also uses the Domain name instead of the IP address. If the SMTP server supports SMTP extensions, it returns a code of 250 to the client. If the server does not support the extensions, it returns a code of 500.

AUTH—This stands for authenticate. The user provides a username/password to the SMTP server to authenticate the client before mail can be sent.

ATRN—This stands for authenticated TURN. After a client has been authenticated to the SMTP server, this command instructs the Receiver-SMTP to return an OK response. In that case, the SMTP server must assume the function as the sender of the mail. Otherwise, the SMTP server can return a Bad Gateway message (reply number 502) and remain in the role as Receiver-SMTP.

DATA—This command is followed by actual data that makes up the email message. This includes both the body text and such things as the subject line.

EXPN—This stands for expand. This command requests the SMTP server to tell the client whether the argument included with the command is a mailing list. If so, the server returns a list of the members of the mailing list to the client.

HELP—This command instructs the SMTP server to return help information to the sender. The HELP command might or might not contain arguments.

MAIL—This command includes the reverse path as its argument. This is the name of the sender, but it also can be a list of hosts that were used to relay the mail message from its original Sender-SMTP. In a list of hosts, the first host is the current Receiving-SMTP server. The last is the destination of the email.

NOOP—This is the “no operation” command. The server responds with OK.

QUIT—The Sender-SMTP sends this command when it is finished. The server should return an OK message and then close down the transmission channel (that is, TCP connection).

RCPT—This stands for recipient. The argument for this command is a single recipient, specified by using a forward-path list preceded by the letters TO:. If a mail message is being sent to more than one recipient, a separate RCPT command must be issued for every recipient.

RSET—This aborts the current email transaction. The SMTP server should respond with an OK message.

SAML—This stands for Send and Mail. Mail is the typical use today with SMTP. The send method is meant to be used when the SMTP server has been implemented to deliver mail directly to a recipient that is actively connected. The argument for this command, again, is a reverse-path showing the path to the destination of the email. The reverse-path text is preceded by the text FROM:.

SEND—This command, not often implemented, specifies that the mail message be delivered directly to the destination, if it’s actively connected. If this cannot be done, the server returns a message code of 450 (the mailbox is not available). Similar to the SAML command, the argument for this command is the text FROM: followed by the reverse-path to the destination mailbox.

SIZE—This command lets the Sender-SMTP inform the server of the size of the mail message it wants to send. This is supported only by SMTP implementations that use the SMTP Service Extensions. The server can return a message indicating that it cannot handle mail of the size requested, or it can accept the message.

SOML—This stands for Send or Mail. Similar to SAML, this command requests that the mail be “sent” (for example, directly to the actively connected recipient) or mailed. The server tries the Send method first, and if that fails, the server attempts to deliver the message to the destination mailbox.

TURN—This command instructs the Receiver-SMTP to assume the role of the sender of the mail (in which an OK response is returned). The server can refuse (with a code 502) and remain in the role of Receiver-SMTP.

VRFY—This command asks the Receiver-SMTP to verify that the username that is passed as an argument with the command be checked to determine whether it’s valid. If the username is a valid one, the full name and mailbox of the user are returned.

Because SMTP allows for sending a single message to multiple recipients, a large mailing list could generate a lot of network traffic. Thus, the original SMTP RFC 821 recommends that only one copy of the actual email be sent to the server in this sort of situation. The SEND command (and its associated commands) was intended originally to send a message directly to a user’s terminal. In today’s world of PCs and workstations, it isn’t typical to find a user sitting at a terminal. It also usually is not desirable to have mail pop up suddenly on a user’s terminal if this function is still supported in your network. Instead, the MAIL command and its other associated commands are usually used.

The DATA portion of the mail message is terminated using the period (.) character by itself on a single line—which is followed by the line terminating characters (CRLF). Typically this will be <CRLF>.<CRLF>, because the first <CRLF> terminates the last line of actual data.

SMTP Response Codes

Remember that for each command issued by the Sender-SMTP, a single response is expected from the Receiver-SMTP. This simple lock-step method keeps things synchronized so that both sides of the connection are aware of the current state of the transaction. The three-digit response codes that the Receiver-SMTP can use are similar in format to those returned by FTP servers. The first digit indicates the general meaning (or category) of the response.

These are the first digits for SMTP response codes:

1—This is a positive response. The command has been accepted by the SMTP server and the server is waiting for further information to determine whether it should continue or abort processing. At this time, no SMTP commands allow this kind of reply message.

2—This is a positive response. The function requested by the client-SMTP has been completed, and the server is ready for another command.

3—This is a positive response. This is similar to category 2 but indicates that the action requested is being held up, waiting for further information or commands from the Sender-SMTP.

4—This is a negative response. It indicates that something went wrong and the command could not be completely processed. The Sender-SMTP should retry the command, or sequence of commands, that led up to this response.

5—This is a negative response. Unlike the “4” response code category, this one indicates that an error has occurred that prevents the command from being executed, such as a misspelling. The command can be tried again, but not unless the Sender-SMTP can determine the problem and correct it before trying again.

The second digit of the response code provides a further subdivision within that category to further indicate the response. The second digit can have the following values:

0—This indicates a syntax error or that the particular command is not supported by the server. For example, if the Sender-SMTP client supports the SMTP service extensions but the Receiver-SMTP server does not, it returns this value.

1—This is used in replies that return help messages to the client.

2—This is used for replies that refer to the transmission channel.

5—This is used in replies that are reporting the status of the mail system, as it pertains to the requested mail transfer or the current command.

Note in the preceding list that numbers 3 and 4 are omitted. They are undefined at this time.

The third digit further delineates the response indicated by the first two digits, and the list of possible codes that result from this combination is much too long to list here. Table 26.1 lists just a few of the more common numeric responses that are used in most SMTP implementations today.

Table 26.1. Typical Reply Codes Used by SMTP

Putting It All Together

Now that you’ve seen the simple command set that is used by SMTP, and the simple response code mechanism, you can put it all together and see an example of how a particular mail transaction might occur:

1. First, the Sender-SMTP sends a HELO or an EHLO command to the SMTP server.
2. The MAIL command is used, with the reverse-path information. At this state, the SMTP server knows who wants to send the mail message and a return path to send back error messages should anything go awry. The server clears the necessary buffers and sends the “250 OK” message back to the sender.
3. The RCPT command is issued by the client giving a forward-path of exactly one recipient of the mail message. If more than one recipient is the target of the message, multiple RCPT commands must be used. The “250 OK” response is sent if the server thinks it can get the message delivered. If not, the SMTP server returns a code of 550, which is a failure code.
4. The DATA command is sent to the server. The server will return an intermediate reply code, 354, indicating that the remaining lines it receives from the sender will be interpreted as part of the email message.
5. The client sends each line of text, and the server responds with “250 OK” for each line received. When the client is finished sending the message, a line with a single period character (“.”) is sent (with the appropriate <CRLF> that ends every line of text in SMTP).
6. After receiving a final OK from the server, the client issues the QUIT command to terminate the session.

In these steps, information typically found in an email message—the subject, date, and so on—are included as part of the email message data that is transmitted following the DATA command. Also, this is a simple message exchange. It can get more complicated. For example, the server can return a reply code of “251 - User not local; will forward to...” followed by the forward-path information. This happens when the Receiver-SMTP knows the correct host on which a destination user’s mailbox is located, but it differs from the one sent by the client. Another message of a similar type leaves the process of sending mail to another destination up to the client. This message, “551 - User not local...” supplies the client with the forward-path that the client can use to deliver the message. In this case, however, the server does not forward the message but lets the client take further action.

The Post Office Protocol (POP3)

Mail clients use SMTP to send outgoing mail to an SMTP server. To retrieve mail messages, however, the Post Office Protocol (currently version 3) generally is used. POP3 is a stateful protocol, progressing from one state to another, depending on the results of the transaction in progress and the commands that are issued. The states are listed here:

AUTHORIZATION—In this state, the user supplies a username and password to authenticate the client to the mail server. In its original implementation, the protocol supports clear-text for username and password transmissions. This, of course, can be a security problem, and other techniques should be used in a secure environment.

TRANSACTION—In this state, the client issues commands and receives responses from the server.

UPDATE—In this state, the client has finished its commands (by issuing the QUIT command), and the server can then delete messages that were marked for deletion and close the TCP connection.

In the following sections, you’ll see what happens during each state and the POP3 commands that can be used in each state. Similar to SMTP, commands are not case-sensitive and are either 3 or 4 characters long. The total length of arguments allowed for a command is 40 characters. Responses, however, can be up to 512 characters in length.

Finally, the status indicators that the POP3 server can return to the client are limited to only two:

+OK—A positive response.

-ERR—A negative response.

Each of these status indicators can be followed by text that describes the response. In many cases, the response consists of multiple lines. Both the +OK and the -ERR status indicators must be sent by the server in uppercase only. When multiple lines are sent as part of a response, the same method used by SMTP to mark the end of the response is used: the period character on a line by itself.

The AUTHORIZATION State

A POP3 server typically listens on TCP port number 110 for incoming requests from POP3 clients. After a TCP connection is established between the client and the POP3 server, the POP3 server sends a greeting to the client. At this point, the process is said to be in the AUTHORIZATION state. During this state, the client uses some authentication method to identify itself to the POP3 server. This can be clear-text username and password combinations, or it can be a more secure authorization method. For more information about secure forms of authentication when using POP3, see RFC 1734, “POP3 AUTHentication command.” This RFC defines the AUTH command that can be used to negotiate an authentication mechanism between the client and the server.

After the client has been authenticated to the POP3 server, the server attempts to gain an exclusive lock on the client’s mailbox files. This lock prevents changes to the mailbox during the session so that the current collection of messages remains the same through the UPDATE state. Failure to lock the mailbox could allow new messages to arrive. As you’ll find out in the next section, the server uses message numbers to identify each message in the mailbox. If new messages were allowed to enter the mailbox while the users were accessing it, it would be possible for confusion to exist during the UPDATE state, especially if messages are to be deleted. Thus, the mailbox is locked so that it will remain consistent for the current session.

The TRANSACTION State

After authentication has been performed successfully, the process enters into the TRANSACTION state, in which the client can send commands to the POP3 server. When finished issuing commands to the server, the client uses the QUIT command to terminate the session. At this point, the server enters the UPDATE state.

The POP3 server assigns a unique message number, beginning with 1, to each message in the mailbox. During this TRANSACTION state, the client can use the following commands to communicate with the POP3 server:

STAT—This “status” command results in the server returning information about the mailbox to the client. This is called a drop listing. The format is the +OK status indicator followed by a single space and then the number of messages currently in the mailbox. The drop listing also contains the size of the messages contained in the mailbox in octets (bytes).

LIST—This command can be optionally followed by a message number. If a message number is included, the POP3 server returns a “scan listing” for the specified message. If no message number is specified, the server responds with the +OK status indicator and then lists, line by line, a scan listing for each message in the mailbox. The scan listing consists of the message number followed by one single space and then the size of the message in octets.

RETR—This is the retrieve command used to pull copies of messages from the server. A message number must follow the RETR command. The server responds with the +OK status indicator, followed by a multiline response that consists of the actual text of the mail message itself. The message is terminated with the period character.

DELE—This command allows the client to request that a message be deleted from the POP3 server. Again, a specific message number is required. The message will be marked as deleted, but it still exists in the mailbox until the session enters the UPDATE state.

NOOP—Again, the no operation command does nothing, but the POP3 server responds with the +OK status indicator.

RSET—This “reset” command causes any messages that have been marked as deleted to be reset to a nondelete state.

After the client has finished issuing commands to the server and processing the responses the POP3 server returns, the client issues the QUIT command to indicate that it is finished. This ends the TRANSACTION state.

The UPDATE State

After the QUIT command has been received by the POP3 server, the session enters the UPDATE state. In this state, the POP3 server can delete the mail messages that were previously marked for deletion by the client. Again, if the session is terminated (by a network failure, for example) before the client can issue the QUIT command, messages that were marked for deletion are not deleted because the session never makes it to the UPDATE state.

When the POP3 server deletes messages during this state, it sends the +OK status indicator back to the client. If an error occurs trying to delete any of the messages, the -ERR status indicator is returned to the client.

After deleting the messages, the server performs other housekeeping chores, such as removing its lock on the mailbox, and then terminates the TCP connection.

The Internet Message Access Protocol Version 4 (IMAP4)

This Internet email protocol was also developed many years ago, but has been gaining wide adoption only in the past five years. Like POP3, users can download email messages from an IMAP server. However, it is also possible to leave the messages on the server. You can download a list of header information (such as the sender, subject line, and date of the email) and decide which messages you want to read. The messages still reside on the server. You do not have to download them to your workstation. Similar to the way in which POP3 email clients function, you can also create folders on the IMAP server so that you can organize your email. When using POP3 or IMAP, you can also create local folders that are stored on your computer’s hard drive.

Storing email messages on a central server enables a system administrator to create backups of the email database—reducing the worry of accidentally deleting a message after you download it from an SMTP server. Provided that the message was put to backup before you deleted it on an IMAP server, it can be restored from the backup. Another benefit for the network administrator is that it is easy to enforce limits on the number of messages that can accumulate in a user’s mailbox, and automatically delete older messages. Of course, a good administrator will first send out an email to users approaching their limit to inform them.

Perhaps a more important feature that is useful to the end user is that you can access your email from more than one location. For example, you can read email at work or from home, and it will appear the same. This can be useful for mobile users who are away from the office. Using POP3, messages that are downloaded to your workstation may no longer be available on the SMTP server. IMAP will store the messages on a central server so that you can access them from any location that allows a connection to your network, such as through a VPN or an authenticated Web-based client. You can read messages while on the road and still have them to download to your mail client back at your office when you return. The alternative, when using a POP3 client, is that you have to extract the messages from your client software on your laptop and then import them into the client software on your desktop computer.

Of course, the end user can also delete messages from the IMAP server via client software if they are no longer needed.

Transport Protocols

IMAP is an application protocol. As with POP3 and SMTP, the underlying transport protocol is TCP/IP. The IMAP server listens on port 143 for requests from IMAP clients. The mechanism for receiving data is also similar to SMTP. Lines of data (text or other data) are used, and each line is terminated by the <CRLF> sequence.

Client Commands

Each command sent by the client application begins with a tag. Each tag consists of a string of characters followed by the line of text. A tag consists of the unique identifier of the command or the message sequence number. This allows the client and server to keep track of which requests and responses are being sent or acknowledged. Either of the following may be part of the tag:

Unique Identifiers (UIDs)—These usually exist across sessions between the client and the IMAP server. Thus, these numbers are not assigned in a sequential manner; however, they should be assigned in an ascending order should they change.

Message Sequence Number—Each message in the user’s mailbox is assigned a message sequence number, starting with the number one, so that each message is uniquely identified in the mailbox of that user by this number. When messages are deleted, the message sequence number for those messages that follow the deleted message are reassigned to maintain a contiguous numerical ascending order.

System Flags

The IMAP server also maintains a set of flags that tell it the status of each email message. All system flags begin with a backslash (). These are the common system flags:

Seen—The message has been read by the client software application.

Answered—The message has been sent an answer by the client software.

Flagged—The message has been marked for some type of action, such as deletion, urgency, or special attention.

Deleted—The message has been marked for deletion by the function called expunge.

Draft—The message has not been finished and is flagged as a “draft” message so that you can save it and complete it later.

Recent—The message is new to the current session. If more than one session is opened by client software, this flag may not be seen by all client software applications.

Retrieving the Message Header and Body of the Message

Because IMAP must interact with SMTP, it recognizes the SMTP envelope, which consists of the header information and data stored in the email message. There are several states that the protocol goes through when interacting with the IMAP server.

The selected state means that a mailbox has been selected. The logout state indicates that the connection is to be terminated by either the client or the server.

Data Formatting

Although all transfers occur in text format, similar to SMTP, there are several forms of data that can be used with commands/responses that are exchanged between the client and the server of the IMAP computers:

Atom—One or more special characters.

Number—One or more numerical digits.

String—Two versions of this type are used:

A literal string consists of a sequence of zero or more string ASCII characters. The literal string is prefixed with a number (enclosed in braces {}) that indicate the number of characters to follow. The literal string includes the <CRLF> characters. An empty literal string is represented as {0}<CRLF>.

A quoted string is a string of characters made up of zero or more 7-bit characters, not including the <CRLF> characters. The string of characters contains a quote character (") at the start and end of the string as a delimiter of the string. Thus, no count of characters is required. An empty quoted string is represented as "".

8-bit binary text—This type of data uses MIME (Multi-Purpose Internet Mail Extensions) that transfers encoding using 8-bit encoding.

Parenthesized list—A sequence of data structures, each delimited by a space character, and surrounded by the parentheses characters ( and ). An empty list is represented as ().

In addition, the NIL data type is a special type of the atom data type which indicates that a data type is nonexistent. This is used to differentiate between the null string "" and the null parenthesized list ().

The User’s Inbox and Other Mailbox Naming

Most mailbox names used by IMAP4 depend on the particular IMAP implementation. The Inbox is a reserved term used to designate the incoming mail (inbox) of a user.

Other mailbox names start with the pound (#) character.

Universal Commands

Clients may also send the following commands:

Capability—This command starts with the AUTH command to determine whether the server can use a particular authentication method.

NOOP (No Operation)—Generally does nothing. This command can be used to poll the server to update the client’s listing to see whether any new messages are available, or to reset a time after which the client will be logged off the server. In other words, it’s an “I’m still here” type of command.

LOGOUT—This tells the server that the client software is finished and the connection should be closed.

Other IMAP Commands Non-Authenticated Commands

In addition to the commands listed earlier in this chapter concerning IMAP, the following commands are used before the user has been authenticated to the server. These are the commands that are indeed used during the initial authentication process.

AUTHENTICATE—Is followed by the name of an authentication mechanism, and the server can ask for additional data for the authentication. The server can then accept or reject the client’s logon. The server can also reject this command if it does not support the method of authentication requested by the server. Subsequent communications between the client and the server depend on the method of authentication chosen.

LOGIN—Sends the user’s name and password in clear text without using any encryption mechanism, such as LOGON OGLETREE ZIRA. In an environment where security is important, the AUTHENTICATION command should be used to select a more secure mechanism.

Authenticated Commands

These commands can be used after the client has authenticated itself to the server:

SELECT—Is used to select the mailbox. The server can respond that the mailbox exists and, if so, can indicate the number of recent messages, and any flags defined in the mailbox (such as urgent).

EXAMINE—Is nearly identical to the SELECT command, except that the mailbox is available for read-only access.

CREATE—Is used to create a new mailbox.

DELETE—Is used to delete a mailbox.

RENAME—Renames an existing mailbox.

SUBSCRIBE—Is used to subscribe to a newsgroup, such as pets.cats.zira.

UNSUBSCRIBE—You guessed it—is used to unsubscribe from a newsgroup.

LIST—Lists the contents of a mailbox (mail or newsgroup).

LSUB—Returns a list of names for newsgroup lists the user has subscribed to, even if they no longer exist.

STATUS—Obtains the status of the mailbox. Replies can include MESSAGES (number of messages in the mailbox), RECENT (number of messages in the mailbox with the Recent flag set), UIDNEXT (the value of the unique identifier, UID, that will be assigned to the next message received), or UIDVALIDITY (the unique identifier validity value of the mailbox).

APPEND—Adds a new message to another mailbox.

CLOSE—Removes messages that have the /Deleted flag set, unless the mailbox was opened with EXAMINE or is in a read-only state.

EXPUNGE—Permanently removes messages with the /Deleted flag set.

SEARCH—Searches a mailbox for messages per criteria set by the client. A large number of criteria can be used, which can be obtained by reading RFC 2060.

FETCH—Obtains all or part of a message (such as the header or body of text of the message) for the client to read.

STORE—Alters data that is part of a message in a mailbox.

COPY—Copies a message to the end of a destination mailbox.

The responses sent by the server to the client will depend on the particular command in this list, and the list is quite lengthy. As with the SEARCH command, the reader is encouraged to read RFC 2060. This chapter was designed to give you an idea of how a client interacts with the server to get or manipulate messages stored on the server.