The Internet Message Access Protocol, Version 4 is an electronic messaging protocol with both client and server functions. It is defined by RFC 3501. Similar to POP, IMAP4 servers store messages for multiple users to be retrieved upon client requests, but the IMAP4 model provides more functionality to users than does the POP model. IMAP4 allows clients to have multiple remote mailboxes from which messages can be retrieved, and allows users to choose any of those at any point. IMAP4 clients can also specify criteria for downloading messages,
such as not transferring large messages over slow links. Additionally, IMAP4 always keeps messages on the server and replicates copies to the clients.
Another difference between POP and IMAP4 implementations is in the
operational mode. Using POP, a client must always be connected to the server for changes to be made. However, IMAP4 allows clients to make changes both when connected and when disconnected. When disconnected, (referred to as a disconnected client), changes made on the client take effect on the server by periodic re-synchronization of the client and server. Let us discuss the underlying electronic mail models of IMAP4 first in order to understand the IMAP4 functions clearly. These are described in detail in RFC 1733 – Distributed Electronic Mail Models In IMAP4.
5.5.1 Fundamental IMAP4 electronic mail models
As defined in RFC 1733, there are three fundamental models implemented by the IMAP4 client and server: offline, online, and disconnected.
The offline model is similar to POP3’s implementation (see 15.4, “Post Office Protocol (POP)” on page 589). An IMAP4 client connects to a server, downloads mail messages, and then disconnects from the server. Downloaded messages are then deleted from the server-based mailbox and exist only on the client’s system.
The online model is the opposite of the offline model. In the online model, an IMAP4 client does not download messages from the server. Instead, it
establishes a connection with the server, and then manipulates the mail while it remains in the server-based mailbox.
The disconnected model is a combination of both the offline and online models.
In this model, an IMAP4 client connects to a server, downloads some or all of the messages, and disconnects. However, following the disconnect, the server does not delete the messages as it does in the offline model. The client can then manipulate the messages on the local system and later reconnect to the server.
Upon reconnecting, the client’s changes are synchronized with the server’s mailbox, enacting any of the changes made while offline. In this model, the server remains the authoritative repository for the messages.
Each of these models have advantages and disadvantages, but because IMAP4 supports all these models, the client is able to switch to another model to meet whatever needs might exist at the time. Some of these advantages and
disadvantages are listed in Table 15-5.
5.5.2 IMAP4 states
Similar to POP3 (see 15.4.1, “Connection states” on page 589), the IMAP4 session exists in different states. Some commands are valid for certain states and some of the commands are valid for all states. If the client sends a command that is not appropriate for that state, the server responds with an error message.
The four states are:
Non-authenticated state In this state, the client has not yet authenticated
with the server.
Authenticated state In this state, the client has identified itself to the server, and must select a mailbox to proceed.
Selected state In this state, a mailbox has been successfully selected, and actions can be taken against mail
within the mailbox.
Logout state In this state, the connection has been ended either at the request of the client or for any other
reason.
These states are illustrated in Figure 15-9.
Where:
(1)Connection without pre-authentication (OK greeting) (2)Pre-authenticated connection (PREAUTH greeting) (3)Rejected connection (BYE greeting)
(4)Successful LOGIN or AUTHENTICATE command (5)Successful SELECT or EXAMINE command
(6)CLOSE command, or failed SELECT or EXAMINE command (7)LOGOUT command, server shutdown, or connection closed 5.5.3 IMAP4 commands and response interaction
IMAP4 clients establish a TCP connection to the server using well-known port 143. When the connection is established, the server sends a greeting message, after which the client and the server exchange data interactively. Whenever the client sends a command, the server sends a completion result response to this command. The server can also send data for any other reason. All commands and responses are in the form of lines ending with the <CRLF> sequence.
Although the server must respond to all client commands, it might not respond to them in the order in which they were received. In order to correlate the responses with the commands, the client commands begin with an identifier called a tag. For example, assume a client sends two commands to the server. The first has the tag ABC005, and the second with the tag ABC006. If it takes less time to process the second command, the server will respond to this command first, even though it was received second. In order to let the client know the response is for the second command, the response will include the ABC006 tag.
Client commands
Most of the IMAP4 commands must be used in the correct corresponding state (we define the states in 15.5.2, “IMAP4 states” on page 592), though some of them can be used in more than one state. The following list shows the commands and the states in which they are used:
_ In any state:
– CAPABILITY: Request a list of functions supported by the server.
– NOOP: Do nothing. This is typically to reset an inactivity autologout timer on the server.
– LOGOUT: Disconnect from the server.
_ In the non-authenticated state:
– AUTHENTICATE mechanism: This command requests a special
authentication mechanism with an argument from the server. If the server does not support that mechanism, the server sends an error message.
Valid mechanisms, defined in RFC 1731, include:
• KERBEROS_V4
• GSSAPI
• SKEY
– LOGIN user pass: This command sends the user name and password (in plain text).
– STARTTLS: Begin TLS negotiation. Note that using TLS with IMAP4 is defined in RFC 2595.
In the authenticated state:
– SELECT name: Select the mailbox named name.
– EXAMINE name: Select the mailbox named name, but in read-only mode.
– CREATE name: Create a mailbox named name.
– DELETE name: Delete the mailbox named name.
– RENAME oldName newName: Change the name of the mailbox named oldName to newName.
– SUBSCRIBE name: Add the mailbox named name to the subscription list.
– UNSUBSCRIBE name: Remove the mailbox named name from the subscription list.
– LIST name mailbox: Return a list of all names conforming to the name string within mailbox. If the name argument is not specified, all available names are listed.
– LSUB name: Return a list of all mailboxes on the subscription list that conform to name. If the name argument is not specified, all mailboxes on the subscription list are returned.
– STATUS name item: Return the status of item for the mailbox named name.
– APPEND mailbox message: Appends the message text to the given mailbox as a new message. In the original RFC 3501 definition, only one message could be APPENDed at a time. However, a MULTIAPPEND extension was provided in RFC 3502, allowing multiple messages to be APPENDed at once. It was later extended by RFC 4469 to include a CONCATENATE option. This option enables a user to APPEND a message without first having to FETCH it from the server.
_ In selected state:
– CHECK: Request a checkpoint of the currently selected mailbox. The checkpoint is implementation-specific, but typically consists of
“house-keeping” functions such as synchronizing a mailbox between a client and server.
– CLOSE: Close the currently selected mailbox. This permanently removes all messages from the mailbox that were previously marked as deleted and returns the client to the authenticated state.
– UNSELECT: Close the current mailbox without removing messages previously marked deleted. Note that this command is not defined in the original RFC 3501 specifications. Its implementation is defined in RFC
3691 and it is optional.
– EXPUNGE: Permanently removes all messages from the currently
selected mailbox that were previously marked as deleted. This does not close the currently selected mailbox, nor does it remove the client from the selected state.
– SEARCH criteria: Search the mailbox for messages that match the specified criteria.
– FETCH item message: Retrieve the specified item associated with a message. Item can be a single thing, or a list of things.
– STORE item message: Store the specified item with the associated message in the mailbox.
– COPY message mailbox: Copies the specified message to the end of the specified destination mailbox.
– UID name arguments: Returns the unique identifier instead of message sequence numbers. This command is used with other commands.
Server responses
The IMAP4 server’s responses exist in three forms:
_ Status _ Server data
_ Command continuation requests
Depending on the message, these responses might or might not be tagged.
Status responses
Valid status response include:
OK This response provides the client with information. If tagged, this indicates that a client command has completed successfully.
NO This response indicates that an operational error has occurred on the server. If tagged, it indicates that a client command did not complete successfully.
BAD This response provides an error message from the server. If tagged, the response is reporting a protocol-level error within a
client’s command.
PREAUTH This response is one of three possible greetings sent at connection startup. It is always untagged.
BYE This response indicates that the server is preparing to close the connection, and can be a part of the normal logout sequence, a panic shutdown, or an inactivity logout. It is always untagged.
Server data responses
Server data responses are unsolicited messages sent from the server to the client. They are always untagged, marked only by an asterisk. These messages can be sent at any time, including when there are outstanding client commands.
Therefore, the client must be ready to accept server data responses at all times, even when it is awaiting a response indicating the completion of a command.
Server data responses indicate things such as the receipt of new mail, a change of state for a mailbox or message, or any other information for which the server needs to alert the client.
Command continuation request responses
There are cases in which a client’s command is sent in two messages. In these cases, the client sends the first message, and then waits for a response from the server. When the server is ready for the second message, it sends the command continuation response. This response is marked by a plus (+) tag. An example of this is the logon sequence. In the following example, client commands are marked with a C and server responses are marked with an S:
C: A001 LOGIN
S: + Ready for additional command text C: user1
S: + Ready for additional command text C: password
S: A001 OK LOGIN completed
5.5.4 IMAP4 messages
There are two methods used to identify the messages: the unique identifier and the message sequence number. Some of the more common attributes are shown in the following sections. Refer to RFC 3501 for details.
Unique identifier (UID) message attribute
Every message has a 32-bit identifier, which, when it is combined with a unique identifier validity value, forms a 64-bit value. When a new message is added to the mailbox, a higher UID than those added previously is assigned to that
message. Unique identifiers do not have to be contiguous, and also persist into other sessions. This allows a client to access a message using the same
information in every session.
Each mailbox has a unique identifier validity value. If it is not possible to use the same value for the next session, the new value must be greater than the value that was used in the previous session. For example, if a mailbox is deleted in one session and a new one created with the same name in the next session, the client might not realize that this is a new mailbox, because the mailbox name is the same. In this case, the unique identifier validity value must be changed. The unique identifier validity value is sent with the mailbox selection to the client as UIDVALIDITY.
Message sequence number message attribute
The message sequence number shows the relative position of the message in the mailbox, and must be in ascending order. The message sequence number is subject to change during the session, or between sessions. If a new message is added to a mailbox, it is given the next sequential number. If a message is deleted, the message numbers of messages remaining in the mailbox are recalculated.
Flags message attribute
Flags are used to show the current status of a message. These flags include:
\Seen Message has been read.
\Answered Message has been answered.
\Flagged Message is marked for special attention.
\Deleted Message is deleted for later permanent removal.
\Draft Message has been completed.
\Recent Message has arrived recently and this is the first session after its arrival. This flag cannot be changed by the client.