Skip to main content

2. Protocol Overview

The IMAP4rev2 protocol assumes a reliable data stream such as that provided by TCP. When TCP is used, an IMAP4rev2 server listens on port 143 (cleartext port) or port 993 (Implicit TLS port).

2.2 Commands and Responses​

An IMAP4rev2 connection consists of the establishment of a client/server network connection, an initial greeting from the server, and client/server interactions. These client/server interactions consist of a client command, server data, and a server completion result response.

All interactions transmitted by client and server are in the form of lines, that is, strings that end with a CRLF. The protocol receiver of an IMAP4rev2 client or server is reading either a line or a sequence of octets with a known count followed by a line.

2.2.1 Client Protocol Sender and Server Protocol Receiver​

The client command begins an operation. Each client command is prefixed with an identifier (typically a short alphanumeric string, e.g., A0001, A0002, etc.) called a "tag". A different tag is generated by the client for each command. More formally: the client SHOULD generate a unique tag for every command, but a server MUST accept tag reuse.

Clients MUST follow the syntax outlined in this specification strictly. It is a syntax error to send a command with missing or extraneous spaces or arguments.

There are two cases in which a line from the client does not represent a complete command. In one case, a command argument is quoted with an octet count (see the description of literal in Section 4.3); in the other case, the command arguments require server feedback (see the AUTHENTICATE command in Section 6.2.2). In either case, the server sends a command continuation request response if it is ready for the octets (if appropriate) and the remainder of the command. This response is prefixed with the token "+".

Note: If, instead, the server detected an error in the command, it sends a BAD completion response with a tag matching the command (as described below) to reject the command and prevent the client from sending any more of the command.

2.2.2 Server Protocol Sender and Client Protocol Receiver​

Data transmitted by the server to the client and status responses that do not indicate command completion are prefixed with the token "*" and are called untagged responses.

Server data MAY be sent as a result of a client command or MAY be sent unilaterally by the server. There is no syntactic difference between server data that resulted from a specific command and server data that were sent unilaterally.

The server completion result response indicates the success or failure of the operation. It is tagged with the same tag as the client command that began the operation.

2.3 Message Attributes​

In addition to message texts, several attributes are associated with each message. These attributes can be retrieved by either message sequence number or unique identifier (UID).

2.3.1 Message Numbers​

Messages have two forms of identification: message sequence number and unique identifier (UID).

2.3.1.1 Unique Identifier (UID) Message Attribute​

A unique identifier (UID) is a 32-bit non-zero unsigned integer value assigned to each message. The UID provides a means of identification that persists across IMAP sessions.

2.3.1.2 Message Sequence Number Message Attribute​

A message sequence number is a relative position from 1 to the number of messages in the mailbox. This position MUST be ordered by ascending unique identifiers.

2.3.2 Flags Message Attribute​

A message has a list of zero or more named tokens, known as "flags", associated with it. There are two types of flags in IMAP4rev2: system flags and keywords.

System flags defined:

  • \Seen - Message has been read
  • \Answered - Message has been answered
  • \Flagged - Message is "flagged" for urgent/special attention
  • \Deleted - Message is "deleted" for removal by later EXPUNGE
  • \Draft - Message has not completed composition (marked as a draft)
  • \Recent - This flag was in use in IMAP4rev1 and is now deprecated

Keywords defined:

  • $Forwarded - Message has been forwarded
  • $MDNSent - Message Disposition Notification was sent
  • $Junk - Message contains junk/spam
  • $NotJunk - Message does not contain junk
  • $Phishing - Message is likely a phishing email

2.3.3 Internal Date Message Attribute​

An Internal Date message attribute is the internal date and time of the message on the server. This is not the date and time in the RFC5322 header but rather a date and time that reflects when the message was received.

2.3.4 RFC822.SIZE Message Attribute​

RFC822.SIZE is the number of octets in the message when the message is expressed in RFC5322 format. This size SHOULD match the result of a "FETCH BODY[]" command.

2.3.5 Envelope Structure Message Attribute​

An envelope structure is a parsed representation of the RFC5322 header of the message. Note that the IMAP envelope structure is not the same as an SMTP envelope.

2.3.6 Body Structure Message Attribute​

A body structure is a parsed representation of the MIME-IMB body structure information of the message.

2.4 Message Texts​

In addition to being able to fetch the full RFC5322 text of a message, IMAP4rev2 permits the fetching of portions of the full message text. Specifically, it is possible to fetch the RFC5322 message header, the RFC5322 message body, a MIME-IMB body part, or a MIME-IMB header.

Last updated on