Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

Results and Responses

Each command sent by the IMAP client elicits some sort of reaction from the IMAP server,

of course. The server takes action based on what the client requested, and then returns

back one or more text strings to indicate what occurred. There are actually two types of

replies that the server can send after a command is received:

☯ Result: This is a reply usually indicating the status or disposition of a command. It may

be tagged with the command tag of the command whose result it is communicating, or

may be a general message that is not tagged.

☯ Response: Any type of information that is being sent by the server to the client. It is

usually not tagged with a command tag and is not specifically intended to indicate

server status.

Note: The IMAP standards sometimes use the terms “result”, “response” and

“reply” in a manner that I find to be inconsistent. Watch out for this if you examine

the IMAP RFCs.

Key Concept: IMAP servers issue two basic types of replies to client commands.

Results are replies that indicate the success, failure or status of a command;

responses are general replies containing many different types of information that the

server needs to send to the client.

Result Codes

There are three main result codes sent in reply to a command, and two special ones used in

certain circumstances:

☯ OK: A positive result to a command, usually sent with the tag of the command that

was successful. May be sent untagged in the server's initial greeting when a session

starts.

☯ NO: A negative result to a command. When tagged, indicates the command failed;

when untagged, serves as a general warning message about some situation on the

server.

NOOP

(No Operation)

None

Does nothing. This may be used to reset the inactivity timer or to periodi-

cally prompt the server to send notification if new messages arrive.

LOGOUT None

Tells the server that the client is done and ready to end the session, which

transitions to the Logout state for termination.

Table 260: IMAP “Any State” Commands (Page 2 of 2)

Command

Parame-

ters

Description

☯ BAD: Indicates an error message. It is tagged when the error is directly related to a

command that has been sent, and otherwise is untagged.

☯ PREAUTH: An untagged message sent at the start of a session to indicate that no

authentication is required; the session goes directly to the Authenticated state.

☯ BYE: Sent when the server is about to close the connection. It is always untagged,

and is sent in reply to a Logout command or when the connection is to be closed for

any other reason.

Response Codes

In contrast to results, responses are used to communicate a wide variety of information to

the client device. Responses normally include descriptive text that provides details about

what is being communicated. They may be sent either directly in reply to a command or

incidentally to one. An example of the latter case would be if a new message arrives in a

mailbox during a session. In this case, the server will convey this information “unilaterally”

at its first opportunity, regardless of what command was recently sent.

The following are the response codes defined by the IMAP standard:

☯ ALERT: An alert message to be sent to the human user of the IMAP client to inform

him or her of something important.

☯ BADCHARSET: Sent when a search fails due to use of an unsupported character set.

☯ CAPABILITY: A list of server capabilities; may be sent as part of the initial server

greeting so the CAPABILITY command does not need to be used.

☯ PARSE: Sent when an error occurs parsing the headers or MIME content of an e-mail

message.

☯ PERMANENTFLAGS: Communicates a list of message status flags that the client is

allowed to manipulate.

☯ READ-ONLY: Tells the client that the mailbox is only accessible in a read-only mode.

☯ READ-WRITE: Tells the client that the mailbox is accessible in read-write mode.

☯ TRYCREATE: Sent when an APPEND or COPY command fails due to the target

mailbox not existing, to suggest to the client that it try creating the mailbox first.

☯ UIDNEXT: Sent with a decimal number that specifies the next unique identifier value to

use in an operation. These identifiers allow each message to be uniquely identified.

☯ UIDVALIDITY: Sent with a decimal number that specifies the unique identifier validity

value, used to confirm unique message identification.

☯ UNSEEN: Sent with a decimal number that tells the client the message that is flagged

as not yet seen (a new message).

IMAP Not Authenticated State: User Authentication Process and Commands

An IMAP4 session begins with an IMAP4 client establishing a TCP connection with an

IMAP4 server. Under normal circumstances, the IMAP4 server has no idea who the client

is, and therefore starts the session in the Not Authenticated state. For security reasons, the

client is not allowed to do anything until it is authenticated. Thus, the only purpose of this

state is to allow the client to present valid credentials so the session can move on to the

Authenticated state.

IMAP Not Authenticated State Commands

The IMAP4 standard defines three different mechanisms by which a client may authenticate

itself. These are implemented using one or more of the three different commands allowed

only in the Not Authenticated state, which are shown in Table 261.

IMAP Authentication Methods

The authentication methods are:

1. Plain Login: This is the typical “username / password” technique, using the LOGIN

command by itself. This is similar to the simple scheme used in POP3, except that in

IMAP4 one command is used to send both the user name and password. Since the

command and parameters are sent in plain text, this is by far the least secure method

of authentication and is not recommended by the standard unless some other means

is used in conjunction.

2. TLS Login: This is a secure login where the Transport Layer Security (TLS) protocol is

first enabled with the STARTTLS command, and then the LOGIN command can be

used securely. Note that STARTTLS only causes the TLS negotiation to begin, and

does not itself cause the IMAP client to be authenticated. Either LOGIN or AUTHEN-

TICATE must still be used.

3. Negotiated Authentication Method: The AUTHENTICATE command allows the

client and server to use any authentication scheme that they both support. The server

may indicate which schemes it supports in response to a CAPABILITY command. After

specifying the authentication mechanism to be used, the server and client exchange

authentication information as required by the mechanism specified. This may require

one or more additional lines of data to be sent.

In response to a LOGIN or AUTHENTICATE command, the server will send an “OK”

message if the authentication was successful, and then transition to the Authenticated

state. It will send a “NO” response if authentication failed due to incorrect information. The

client can then try another method of authenticating, or terminate the session with the

LOGOUT command.

Table 261: IMAP Not Authenticated State Commands

Command Parameters Description

User name and

password

Specifies a user name and password to use for authentication.

AUTHENTICATE

Authentication

mechanism name

Tells the server that the client wants to use a particular authenti-

cation mechanism and prompts the client and server to exchange

authentication information appropriate for that mechanism.

STARTTLS None

Tells the IMAP4 server to use the Transport Layer Security (TLS)

protocol for authentication, and prompts TLS negotiation to begin.

Key Concept: IMAP supports three basic types of authentication: a plain username/

password login; authentication using Transport Layer Security; or the negotiation of

some other authentication method between the client and server. In some cases, the

IMAP server may choose to preauthenticate clients that it is able to reliably identify, in which

case the Not Authenticated state is skipped entirely.

IMAP Authenticated State: Mailbox Manipulation/Selection Process and Commands

In the normal progression of an IMAP session, the Authenticated state is the first one where

the IMAP client is able to perform “useful work” on behalf of its user. This state will normally

be reached from the Not Authenticated state after successful authentication using the

and begin the session in this state directly.

Once in the Authenticated state, the client is considered authorized to issue commands to

the server. However, it may only give commands that deal with whole mailboxes. As

mentioned in the general operation overview, IMAP was created to allow access to, and

manipulation of, multiple mailboxes. For this reason, the client must specify dynamically

which mailbox it wants to use before commands dealing with individual messages may be

given. This is done in this state using the SELECT or EXAMINE commands, which cause a

transition to the Selected state as we will see.

It is also possible that the Authenticated state can be re-entered during the course of a

session. If the CLOSE command is used from the Selected state to close a particular

mailbox, the server will consider that mailbox “de-selected” and the session will transition

back to the Authenticated state until a new selection is made. The same can occur if a new

SELECT or EXAMINE command is given from the Selected state but fails.

Authenticated State Commands

Table 262 provides a brief description of the mailbox-manipulation commands that can be

used in the Authenticated state:

Table 262: IMAP Authenticated State Commands (Page 1 of 2)

Command Parameters Description

SELECT Mailbox name

Selects a particular mailbox so that messages within it can be

accessed. If the command is successful, the session transitions to

the Selected state. The server will also normally respond with

information for the client about the selected mailbox; see below.

EXAMINE Mailbox name

Exactly the same as the SELECT command, except that the

mailbox is opened “read-only”; no changes are allowed to it.

CREATE Mailbox name Creates a mailbox with the given name.

DELETE Mailbox name Deletes the specified mailbox.

Note: All of the commands above may also be used in the Selected state; they

should really be called “Authenticated+Selected” state.commands.

The SELECT and EXAMINE Commands

When either the SELECT or EXAMINE command is successfully issued, the server will

return to the client a set of useful information about the mailbox, which can be used to guide

commands issued from the Selected state. This information includes the following three

mandatory responses:

☯ <n> EXISTS: Tells the client the number of messages in the mailbox.

☯ <n> RECENT: Tells the client the number of recently-arrived (new) messages.

☯ FLAGS (<flag-list>): Tells the client which flags are supported in the mailbox. These

include the following: “\Seen”, “\Answered”, “\Flagged” (marked for special attention),

“\Deleted”, “\Draft” and “\Recent”. (The backslashes are part of the flag names.)

The reply from the server may also contain these optional replies:

☯ UNSEEN <n>: The message number of the first unseen message.

☯ PERMANENTFLAGS (<flag-list>): A list of flags (as for the FLAGS response above)

that the client is allowed to change.

☯ UIDNEXT <n>: The next unique identifier value. This is used to check for changes

made to the mailbox since the client last accessed it.

RENAME

Current and new

mailbox names

Renames a mailbox.

SUBSCRIBE Mailbox name

Adds the mailbox to the server's set of “active” mailboxes. This is

sometimes used when IMAP4 is employed for Usenet message

access.

UNSUBSCRIBE Mailbox name Removes the mailbox from the “active” list.

LIST

Mailbox name or

reference string

Requests a partial list of available mailbox names, based on the

parameter provided.

LSUB

Mailbox name or

reference string

The same as LIST but only returns names from the “active” list.

STATUS Mailbox name

Requests the status of the specified mailbox. The server responds

providing information such as the number of messages in the box

and the number of recently-arrived and unseen messages.

APPEND

Mailbox name,

message, optional

flags and date/

time

Adds a message to a mailbox.

Table 262: IMAP Authenticated State Commands (Page 2 of 2)

Command Parameters Description

☯ UIDVALIDITY <n>: The unique identifier validity value, used to confirm valid UID

values.

Key Concept: In the Authenticated state, the IMAP client can perform operations on

whole mailboxes, such as creating, renaming or deleting mailboxes, or listing

mailbox contents. The SELECT and EXAMINE commands are used to tell the IMAP

server which mailbox the client wants to open for message-specific access. Successful

execution of either command causes the server to provide the client with several pieces of

important information about the mailbox, after which the session transitions to the Selected

state.

IMAP Selected State: Message Manipulation Process and Commands

Once the IMAP client has been authorized to access the server, it enters the Authenticated

state, where it is allowed to execute tasks on whole mailboxes. Since IMAP allows multiple

mailboxes to be manipulated, message-specific commands cannot be used until the client

tells the server what mailbox in wants to work with. Only one mailbox can be accessed at a

time in a given session.

After the SELECT or EXAMINE command is successfully issued, the session enters the

Selected state. In this state, the full “palette” of message and mailbox commands is

available to the client. This includes the message-specific commands below as well as the

mailbox commands defined for the Authenticated state. Most of IMAP's message-specific

commands do not include a mailbox name as a parameters, since the server knows

automatically that the commands apply to whatever mailbox was selected in the Authenti-

cated state.

The session remains in the Selected state for as long as the client continues to have work

to do with the particular selected (or “examined”) mailbox. Three different actions can cause

a transition out of the Selected state:

☯ If the client has nothing more to do when it is done with the current mailbox, it can use

the LOGOUT command to end the session.

☯ The client can use the CLOSE command to tell the server it is done with the current

mailbox but keep the session active. The server will close the mailbox and the session

will go back to the Authenticated state.

☯ The client can issue a new SELECT or EXAMINE command. This will implicitly close

the current mailbox and then open the new one. The transition in this case is from the

Selected state back to the Selected state, but with a new current mailbox.

Selected State Commands

Table 263 lists the message-specific commands that can only be used in the Selected state.

The FETCH and STORE Commands

This command list might seem surprisingly short; you might wonder, for example, where the

specific commands are to read a message header or body, delete a message, mark a

message as “seen” and so forth. The answer is that these (and much more) are all imple-

mented as part of the powerful and flexible FETCH and STORE commands.

The FETCH command can be used to read a number of specific elements from either one

message or a sequence of messages. The list of “message data items” specifies what infor-

mation is to be read. The data items that can be read include the headers of the message,

the message body, flags that are set for the message, the date of the message and much

Table 263: IMAP Selected State Commands

Command Parameters Description

CHECK None

Sets a “checkpoint” for the current mailbox. This is used to

mark when a certain sequence of operations has been

completed.

CLOSE None

Explicitly closes the current mailbox and returns the session to

the Authenticated state. When this command is issued, the

server will also implicitly perform an EXPUNGE operation on

the mailbox.

EXPUNGE None

Permanently removes any messages that were flagged for

deletion by the client. This is done automatically when a

mailbox is closed.

Search criteria and

an optional character

set specification

Searches the current mailbox for messages matching the

specified search criteria. The server response lists the

message numbers meeting the criteria. See below.

FETCH

Sequence of

message numbers

and a list of message

data items (or a

macro)

Retrieves information about a message or set of messages

from the current mailbox. See below for more details.

STORE

Sequence of

message numbers,

message data item

name and value

Stores a value for a particular message data item for a set of

messages. See below for more details.

COPY

Sequence of

message numbers

and a mailbox name

Copies the set of messages specified to the end of the

specified mailbox.

UID

Command name and

arguments

Used to allow one of the other commands above to be

performed using unique identifier numbers for specifying the

messages to be operated on, rather than the usual message

sequence numbers.

more. The FETCH command can even be used to retrieve part of a message, such as one

body part of a MIME multipart message, making it very useful indeed. Special “macros” are

also defined for convenience. For example, the client can specify the message data item

“FULL” to get all the data associated with a message.

The compliment to FETCH, STORE, is used to make changes to a message. However, this

command is not used to modify the basic message information such as the content of

headers and the message body. Rather, it exists for changing the message's status flags.

For example, after replying to a particular message, the client may set the “\Answered” flag

for that message using the STORE command.

Message deletion in IMAP is done in two stages for safety, as in POP and many other

protocols. The client sets the “\Deleted” flag for whichever messages are to be removed,

using the STORE command. The messages are only really deleted when the mailbox is

expunged, typically when it is closed.

The search facility in IMAP4 is also surprisingly quite sophisticated, allowing the client to

look for messages based on multiple criteria simultaneously. For example, with the appro-

priate syntax, you could search for “all posts that are flagged as having been answered, that

were sent by Jane Jones before April 1, 2004”. Users of IMAP clients can thus easily locate

specific messages even in very large mailboxes, without having to download hundreds of

messages to hunt through.

Key Concept: After the client opens a specific mailbox, the IMAP session enters the

Selected state, where operations such as reading and copying individual e-mail

messages may be performed. The two most important commands used in this state

are FETCH, which can be used to retrieve a whole message, part of a message, or only

certain message headers or flags; and STORE, which sets a message’s status information.

IMAP also includes a powerful search facility, providing users with great flexibility in finding

messages in a mailbox. When the client is done working with a particular mailbox, it may

choose a different one and re-enter the Selected state, close the mailbox and return to the

Authenticated state, or log out, automatically entering the Logout state.

Other TCP/IP Electronic Mail Access and Retrieval Methods

The Post Office Protocol (POP3) and Internet Message Access Protocol (IMAP4) are the

two most common protocols employed for TCP/IP e-mail access and retrieval. The majority

of people using e-mail today choose the simplicity and universal acceptance of POP3, while

a growing number opt for the power and flexibility of IMAP4. There are, however, some that

choose “alternative” ways of accessing e-mail, two of which I feel are worth a closer look.

Both of the methods described in this section are based on the “online” e-mail access

model, but they are a study in contrasts in terms of their role in the e-mail system and how

they are used. The first is what I call direct server access, and describes several ways that

mailboxes are accessed without the use of special remote access protocols like POP and

IMAP. The second is e-mail access using a World Wide Web browser. This is the newest e-

mail access method, and is growing in popularity every year.

TCP/IP Direct Server Electronic Mail Access

In my overview discussion of e-mail message communication, I discussed the different

devices involved in a complete mail exchange, and how a message is created and then

transported from the originator to the recipient. SMTP is used to carry the message most of

the way, to the recipient's mailbox. The last step of the process is to convey the message

from the server where the mailbox is located to the machine the client is using.

This final portion of the e-mail journey is usually the job of an e-mail access and retrieval

protocol like POP3 or IMAP4. These are customized protocols, by which I mean that they

were created specifically for the last step of the e-mail communication process. However,

there are also several generic methods by which an e-mail client can gain access to a

mailbox, without the use of a special protocol at all.

E-Mail Direct Access Methods

These methods are all variations of the online e-mail access model. They generally work by

establishing direct access to the server where the mailbox is located. The mailbox itself is

just a file on a server somewhere, so if that file can be made available, it can be viewed and

manipulated like any other file using an e-mail client program that reads and writes the

mailbox file. The following are some of the ways in which this can be done:

☯ Using The SMTP Server Directly: Obviously, the simplest method for gaining access

to the mailbox is to simply log on to the server itself. This is not an option for most

people, and even in years gone by it was not often done, for security reasons as well

as others. However, even today there are some people who do run their own SMTP

servers, giving them considerable control over access to their e-mail.

☯ File Sharing Access: Using a protocol such as the Network File System, it is possible

to have a mailbox mounted on a user's client machine where it can be accessed as if it

were a local file. The mail is still on the server and not the client machine, but the

communication between the client and the server occurs “transparently” to both the

user and the e-mail client software.

☯ Dial-Up Remote Server Access: A user on a client machine dials up a server where

his or her mailbox is located and logs in to it. The user then can issue commands to

access mail on that server as if he or she were logged in to it directly.

☯ Telnet Remote Server Access: Instead of dialing in to the server, a user can connect

to it for remote access using the Telnet Protocol.

Pros and Cons of Direct Server E-Mail Access

These techniques are much more commonly associated with timesharing systems, which

commonly use the UNIX family of operating systems than others. They are also often

combined; for example, remote access is often provided for UNIX users, but most

companies don't want users logging in directly to the SMTP server. Instead, an Internet

service provider might run an SMTP server on one machine called

“mail.companyname.com” and also operate a different server that is designed for client

access called “users.companyname.com”. A user could access e-mail by dialing into the

“users” machine, which would employ NFS to access user mailboxes on the “mail”

machine.

Direct server access is a method that has been around for decades. At one time, this was

how the majority of people accessed e-mail, for two main reasons. First, if you go back far

enough, protocols like POP or IMAP had not yet been developed; the TCP/IP e-mail system

as a whole predates them by many years and direct access was the only option back then.

Second, the general way that e-mail and networks were used years ago was just different

than it is today. Most individuals did not have PCs at home, and there was no Internet as we

know it. Remotely accessing a UNIX server using a modem or Telnet for e-mail and other

services was just “the way it was done”.

I myself got started using direct server access for e-mail over 10 years ago, and still use this

today. I Telnet in to a client machine and use a UNIX e-mail program called elm to access

and manipulate my mailbox. To me, this provides numerous advantages. First and most

importantly, I can access my e-mail using Telnet from any machine on the Internet,

anywhere around the world. Second, since I am logged in directly, I get immediate notifi-

cation when new mail arrives, without having to routinely check for new mail. Third, my

mailbox is always accessible and all my mail is always on a secure server in a profes-

sionally-managed data center. Fourth, I have complete control over my mailbox and can

edit it, split it into folders, write custom “spam” filters, or do anything else I need to do.

This probably sounds good, but most people today do not use direct server access because

of the disadvantages of this method. One big issue is that you must be logged in to the

Internet to access your e-mail. Another one, perhaps even larger, is the need to be familiar

with UNIX and a UNIX e-mail program. UNIX is simply not as “user-friendly” as a graphical

operating systems such as Windows or the Apple Macintosh. For example, my UNIX e-mail

program doesn't support color and cannot show me attached graphic images. I must extract

images and other files from MIME messages and transfer them to my own PC for viewing.