Skip to main content

6. Client Commands

IMAP4rev2 commands are described in this section. Commands are organized by the state in which the command is permitted. Commands that are permitted in multiple states are listed in the minimum permitted state (for example, commands valid in authenticated and selected states are listed in the authenticated state commands).

Command arguments, identified by "Arguments:" in the command descriptions below, are described by function, not by syntax. The precise syntax of command arguments is described in "Formal Syntax" (Section 9).

Some commands cause specific server responses to be returned; these are identified by "Responses:" in the command descriptions below. See the response descriptions in "Responses" (Section 7) for information on these responses and in "Formal Syntax" (Section 9) for the precise syntax of these responses. It is possible for server data to be transmitted as a result of any command. Thus, commands that do not specifically require server data specify "no specific responses for this command" instead of "none".

The "Result:" in the command description refers to the possible tagged status responses to a command and any special interpretation of these status responses.

The state of a connection is only changed by successful commands that are documented as changing state. A rejected command (BAD response) never changes the state of the connection or of the selected mailbox. A failed command (NO response) generally does not change the state of the connection or of the selected mailbox, with the exception of the SELECT and EXAMINE commands.

6.1 Client Commands - Any State​

The following commands are valid in any state: CAPABILITY, NOOP, and LOGOUT.

6.1.1 CAPABILITY Command​

Arguments: none

Responses: REQUIRED untagged response: CAPABILITY

Result:

  • OK - capability completed
  • BAD - arguments invalid

The CAPABILITY command requests a listing of capabilities (e.g., extensions and/or modifications of server behavior) that the server supports. The server MUST send a single untagged CAPABILITY response with "IMAP4rev2" as one of the listed capabilities before the (tagged) OK response.

A capability name that begins with "AUTH=" indicates that the server supports that particular authentication mechanism as defined in the Simple Authentication and Security Layer (SASL) [SASL]. All such names are, by definition, part of this specification.

Other capability names refer to extensions, revisions, or amendments to this specification. See the documentation of the CAPABILITY response in Section 7.2.2 for additional information. If IMAP4rev1 capability is not advertised, no capabilities, beyond the base IMAP4rev2 set defined in this specification, are enabled without explicit client action to invoke the capability. If both IMAP4rev1 and IMAP4rev2 capabilities are advertised, no capabilities, beyond the base IMAP4rev1 set specified in [RFC3501], are enabled without explicit client action to invoke the capability.

Client and server implementations MUST implement the STARTTLS (Section 6.2.1) and LOGINDISABLED capabilities on cleartext ports. Client and server implementations MUST also implement AUTH=PLAIN (described in [PLAIN]) capability on both cleartext and Implicit TLS ports. See the Security Considerations (Section 11) for important information.

Unless otherwise specified, all registered extensions to IMAP4rev1 are also valid extensions to IMAP4rev2.

Example:

C: abcd CAPABILITY
S: * CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI LOGINDISABLED
S: abcd OK CAPABILITY completed
C: efgh STARTTLS
S: efgh OK STARTTLS completed
<TLS negotiation, further commands are under TLS layer>
C: ijkl CAPABILITY
S: * CAPABILITY IMAP4rev2 AUTH=GSSAPI AUTH=PLAIN
S: ijkl OK CAPABILITY completed

6.1.2 NOOP Command​

Arguments: none

Responses: no specific responses for this command (but see below)

Result:

  • OK - noop completed
  • BAD - command unknown or arguments invalid

The NOOP command always succeeds. It does nothing.

Since any command can return a status update as untagged data, the NOOP command can be used as a periodic poll for new messages or message status updates during a period of inactivity (the IDLE command; see Section 6.3.13) should be used instead of NOOP if real-time updates to mailbox state are desirable). The NOOP command can also be used to reset any inactivity autologout timer on the server.

Example:

C: a002 NOOP
S: a002 OK NOOP completed
   . . .
C: a047 NOOP
S: * 22 EXPUNGE
S: * 23 EXISTS
S: * 14 FETCH (UID 1305 FLAGS (\Seen \Deleted))
S: a047 OK NOOP completed

6.1.3 LOGOUT Command​

Arguments: none

Responses: REQUIRED untagged response: BYE

Result:

  • OK - logout completed
  • BAD - command unknown or arguments invalid

The LOGOUT command informs the server that the client is done with the connection. The server MUST send a BYE untagged response before the (tagged) OK response, and then close the network connection.

Example:

C: A023 LOGOUT
S: * BYE IMAP4rev2 Server logging out
S: A023 OK LOGOUT completed
(Server and client then close the connection)

Note: Chapter 6 is extensive and contains multiple subsections. For the complete command list, please refer to individual subsections:

Last updated on