IMAP ( Interactive Mail Access Protocol )

• Be fully compatible with Internet messaging standards, e.g. MIME.


• Allow message access and management from more than one computer.


• Allow access without reliance on less efficient file access protocols.


• Provide support for "online", "offline", and "disconnected" access modes.


• Support for concurrent access to shared mailboxes.
• Client software needs no knowledge about the server's file store format.

• An IMAP mail system has a number of immediate advantages for users.



• As all mail is stored on the server, changing mail client becomes the work of seconds - all that is required is to configure a new IMAP client with the IMAP account details.



• An IMAP client can easily be configured to view multiple mailboxes in physically separate servers.



• Multiple IMAP clients can be used by each user. This makes implementing a webmail solution for roaming users a simple task.



• IMAP maintains message status flags on the server for read, answered, etc.



• IMAP allows the idea of shared folders. This makes it easier to implement generic email accounts for an organisation, and then allow multiple users to access those accounts.



• Many implementations also allow server side filtering of mail. This can be an extremely useful feature when users are accessing their mailboxes through different email clients.

Example 1: Client Commands - Experimental/Expansion



X Command

Arguments: implementation defined

Responses: implementation defined

Result: OK - command completed

        NO - failure

        BAD - command unknown or arguments invalid



Any command prefixed with an X is an experimental command. Commands which are not part 

of this specification, a standard or standards-track revision of this specification, or 

an IESG-approved experimental protocol, MUST use he X prefix.



Any added untagged responses issued by an experimental command MUST also be prefixed 

with an X. Server implementations MUST NOT send any such untagged responses, unless 

the client requested it by issuing the associated experimental command.



          C: a441 CAPABILITY

          S: * CAPABILITY IMAP4rev1 XPIG-LATIN

          S: a441 OK CAPABILITY completed

          C: A442 XPIG-LATI

          S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay

          S: A442 OK XPIG-LATIN ompleted-cay

Example 2: Sample IMAP4rev1 connection



The following is a transcript of an IMAP4rev1 connection.  A long line in this sample 

is broken for editorial clarity.



          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

               "")

               BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028

               92))

          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 

          S:    Subject: IMAP4rev1 WG mtg summary and minutes

          S:    To: imap@cac.washington.edu

          S:    cc: minutes@CNRI.Reston.VA.US, John Klensin 

          S:    Message-Id: 

          S:    MIME-Version: 1.0

          S:    Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

          S:

          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

Example 3: Server Responses



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.



          C: A001 LOGIN {11}

          S: + Ready for additional command text

          C: FRED FOOBAR {7}

          S: + Ready for additional command text

          C: fat man

          S: A001 OK LOGIN completed

          C: A044 BLURDYBLOOP {102856}

          S: A044 BAD No such command as "BLURDYBLOOP"

■ Parent layer
■ Child layer

TCP

IMAP