Home > Help Center > General > IMAP Mail Protocol

IMAP Mail Protocol

Internet Message Access Protocol (IMAP) is used by email clients to access and manage messages on a mail server.

Typically, the IMAP server listens on port 143, and when the mail account is configured to use SSL/TLS - on port 993.

All modern mail servers without exception support the IMAP protocol and, to a great extent, it is the default protocol for creating an email account.

Multiple Devices and Connections

IMAP makes it possible for a client to access mail account on multiple devices, also many clients can access one mail account simultaneously.

Automatic Synchronization

Automatic synchronization is a remarkable IMAP feature - any message change (delete, reply, forward and move) is automatically synced to all active devices.

Selective Fetching of Individual MIME Parts

IMAP can be set to retrieve only message headers - the entire message along with the images (HTML) and attached documents are downloaded only if requested by the user.

Message State

By using flags defined in the IMAP protocol, customers can monitor the status of the messages: for example, whether the message is read, answered, or deleted.

These flags are stored on the server so that different customers who have access to the same mailbox at different times can find state changes made by other clients.

Server Based Search

Server based search - instead of downloading all mail from the server in order to perform a search on the local computer, IMAP searches on the server and the user can download only the messages found by the search.

Offline mode

IMAP supports offline mode - downloaded emails can be read or deleted when the device is offline. The changes made to the messages (changed flags or deleted) are synchronized with the server when the device goes online.

If you wonder how such a complicated protocol like IMAP works, we offer a very brief description of the main processes and terms.

Commands and Responses

An IMAP connection consists of a client/server network connection and client/server interactions.

These client/server interactions consist of a client command, server data, and a server completion result response.

There are three possible server completion responses:

  • OK (indicating success)
  • NO (indicating failure)
  • BAD (indicating a protocol error such as unrecognized command or command syntax error).

State and Flow Diagram

Once the connection between client and server is established, an IMAP connection is in one of four states.

  • Not Authenticated State - the client MUST supply authentication credentials before most commands will be permitted.

  • Authenticated State - the client is authenticated and MUST select a mailbox to access before commands that affect messages will be permitted.

  • Selected State - a mailbox has been selected to access.

  • Logout State - the connection is being terminated.

Data Formats

IMAP uses text commands and answers.

The data in IMAP can be in one of several forms: atom, number, string, In brackets, or NIL. Pay attention that a specific data item may take more than one form; for example, a data element defined as using "astring" syntax can be an atom or a string.

Client Commands

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

Server Responses

Server responses are in three forms:

  • status responses
  • server data
  • command continuation request

Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD can be tagged or untagged. PREAUTH and BYE are always untagged.

Some status responses, and all server data, are untagged. An untagged response is indicated by the token "*" instead of a tag.

The command continuation request response is indicated by a "+" token instead of a tag. This form of response indicates that the server is ready to accept the continuation of a command from the client. The remainder of this response is a line of text.

Security Considerations

IMAP protocol transactions, including electronic mail data, are sent unprotected over the network unless protection from snooping is negotiated.

This can be accomplished either by the use of STARTTLS, negotiated privacy protection in the AUTHENTICATE command, or some other protection mechanism (SSL/TLS).

Sample IMAP Connection

S:   * OK IMAP4rev1 Service Ready
C:   a001 login mrc secret
S:   a001 OK LOGIN completed
C:   a002 select inbox
S:   * 18 EXISTS
S:   * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S:   * 2 RECENT
S:   * OK [UNSEEN 17] Message 17 is the first unseen message
S:   * OK [UIDVALIDITY 3857529045] UIDs valid
S:   a002 OK [READ-WRITE] SELECT completed
C:   a003 fetch 12 full
S:   * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
      RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
      "IMAP4rev1 WG mtg summary and minutes"
      (("Terry Gray" NIL "gray" "cac.washington.edu"))
      (("Terry Gray" NIL "gray" "cac.washington.edu"))
      (("Terry Gray" NIL "gray" "cac.washington.edu"))
      ((NIL NIL "imap" "cac.washington.edu"))
      ((NIL NIL "minutes" "CNRI.Reston.VA.US")
      ("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
S:    a003 OK FETCH completed
C:    a004 fetch 12 body[header]
S:    * 12 FETCH (BODY[HEADER] {342}
S:    Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S:    From: Terry Gray <gray@cac.washington.edu>
S:    Subject: IMAP4rev1 WG mtg summary and minutes
S:    To: imap@cac.washington.edu
S:    cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>
S:    Message-Id: <B27397-0100000@cac.washington.edu>
S:    MIME-Version: 1.0
S:    )
S:    a004 OK FETCH completed
C:    a005 store 12 +flags \deleted
S:    * 12 FETCH (FLAGS (\Seen \Deleted))
S:    a005 OK +FLAGS completed
C:    a006 logout
S:    * BYE IMAP4rev1 server terminating connection
S:    a006 OK LOGOUT completed


As the world becomes more and more mobile, IMAP is becoming more and more popular. The usage of smartphones, laptops, tablets and other devices is making the demand for IMAP stronger than ever.

Reference: RFC3501

#email #server #overview

Still not finding what you're looking for?

Contact our support team with any additional questions or concerns.

Contact support