A folder must be opened before accessing its messages. Only
    one folder can be opened at a time. Opening a second folder
    automatically closes the first folder. When opening a folder,
    the SMAP server's response indicates how many messages there
    are in the folder. The messages are numbered consecutively,
    from 1 to the message count returned by the OPEN command.
New messages can be added to the folder while it is open. Other application can also remove or modify existing messages, while the folder is opened. There are two mechanisms by which the SMAP client is notified about these changes.
The SMAP client explicitly requests to be notified about any
    other changes by issuing either the NOOP or the EXPUNGE command. The server's response to the
    client includes notification of any messages that were added,
    modified, or removed from the server.
The NOOP and EXPUNGE commands work like all other commands:
    the server does the requested action, and replies accordingly.
    The second mechanism uses the IDLE
    command, which works a little differently. The server's initial
    reply includes any changes to the folder's contents, as with
    NOOP and EXPUNGE, but the story doesn't end there. The
    client's next command, after IDLE,
    must be the RESUME command. Until
    the server receives the RESUME,
    the server may immediately notify the client any time the
    folder's contents change. SMAP servers that are not capable of
    immediate notification of this type should periodically poll
    the folder for changes, until they get a RESUME.
When the client is waiting for user input it should issue
    the IDLE command, so that it knows
    about any changes to the folder made by other applications, and
    react immediately. The client issues a RESUME when it finally has something to do.
    This can be a result of user input, or caused by a change to
    the folder's contents (when new mail arrives, for example, the
    client may want to automatically download its headers).
Messages in the folder are always consecutively numbered, starting with message #1. The messages are renumbered after removing a message; and new messages are added at the end. For example: a folder has five messages, numbered 1 through 5. The third message is removed, and messages #4 and #5 become messages #3 and #4, respectively. When two more messages are added to the folder, they become messages #5 and message #6.
The client may send the “RESUME” command at the same time the server is sending a message to the client concerning some changes to the folder that just occured. The SMAP client should always wait and process any remaining folder content notification changes, until it receives that status reply for “RESUME”.
        C: OPEN "Saved Mail" 2002
        S: * EXISTS 17
        S: +OK Folder opened
The OPEN command opens a
      folder. If another folder is already opened, the other folder
      is closed. The other folder is closed automatically, whether
      or not the OPEN command
      ultimately succeeds.
The whitespace-delimited words after “OPEN” specify the folder
      to open. If it's a valid folder, the server response includes
      a "* EXISTS" single line reply.
SMAP servers are encouraged to offer concurrent access to
      the same folder to multiple application. SMAP servers that
      are unable to do so should reject the OPEN command if the folder is already opened
      by someone else.
        C: SOPEN "28378jhaskdjk9@localhost" "Saved Mail" 2002
        S: * SNAPSHOTEXISTS "28378jhaskdjk9@localhost"
        S: * EXPUNGE 10-13
        S: * EXISTS 25
        S: +OK Folder opened
The SOPEN command enables
      folder snapshots, and opens a previously folder snapshot. A
      folder snapshot is a saved, or cached, copy of the folder's
      contents. Both the SMAP client and the SMAP server maintain
      synchronizes cached copies, or snapshots, of the folder's
      contents. This includes the list of messages in the folder,
      and the message state flags. Normally, after opening a folder
      the SMAP client needs to download the entire list of
      messages, and their states, from the server. Restoring a
      previously snapshot eliminates that step.
The first whitespace-delimited word after SOPEN is a snapshot identifier, as returned
      by a “*
      SNAPSHOT” message (see NOOP). The
      remaining words specify the name of the folder, as in
      OPEN.
The server responds with a “*
      SNAPSHOTEXISTS” message, with a copy of
      the snapshot identifier, followed by zero or more
      “*
      EXPUNGE”, “* FETCH msgnum
      FLAGS”, and “*
      EXISTS” message that reflect any changes
      to the folder's contents that occured since the snapshot was
      made. When the final +OK is
      received, the folder's contents are brough up to date, and
      the SMAP client should issue a NOOP command to make an updated
      snapshot.
If the server is unable to find the requested snapshot, it
      should respond just like to the OPEN command, with a single “*
      EXISTS” message. If the client does not
      receive a “*
      SNAPSHOTEXISTS” message, the client will
      conclude that the requested snapshot is not available. This
      is not an error condition. The requested snapshot might be
      too old, and the server decided that it should be removed by
      now.
A client that wants to use snapshots, but does not have a
      saved snapshot, should use the SOPEN command with an empty string for a
      snapshot identifier. This is because the server would not
      normally make snapshots if the client used the OPEN command to open a folder. The server
      responds to an SOPEN with an
      empty identifier in the same way as to an OPEN command, but enable and make
      snapshots.
        C: CLOSE
        S: +OK Folder closed
The CLOSE command closes the
      currently-opened folder. This command should always succeed,
      and should ideally do nothing if no folder is currently
      open.
SMAP servers that do not support concurrent access to the same folder, by multiple applications, should release the folder so that other applications can open it.
        C: NOOP
        S: * EXPUNGE 10-13 17
        S: * FETCH 12 FLAGS=SEEN
        S: * EXISTS 32
        S: +OK Ok.
        C: NOOP
        S: * SNAPSHOT "89238yu90doi923@localhost"
        C: +OK Ok.
NOOP polls the server for any
      changes made to the folder's contents by other applications.
      The server's response includes 0 or more single line replies before NOOP's status reply.
The single line replies may be sent in any order, and the SMAP client should process each single line reply individually, based on its current understanding of the folder's contents, which is taken into account when processing the next single line reply.
The “*
      EXPUNGE” single line reply lists
      messages that have been removed from the folder. The
      remaining words enumerate the removed message numbers.
      “a-b”
      indicates messages #a through #b, inclusive, and the entire
      list must be sorted in strict numerically increasing order,
      with no overlaps. This message indicates that the specified
      messages have been removed, and the remaining messages were
      renumbered by shifting over to fill in the gaps.
Some time may elapse before a server receives a
        NOOP, after a message is
        removed by some other application. Since the client will
        not be aware of the removed message, the server must handle
        client commands as if the message was not yet removed. For
        example, after message #13 is removed, message #14 now
        becomes message #13. Until the server receives a
        NOOP, it should be aware that
        client's FETCH and
        STORE commands that reference
        message #14 really reference message #13. The server must
        process these commands accordingly, until the server
        receives a NOOP, and notifies
        the client.
Excessively long lists of expunged messages may result
        in multiple * EXPUNGE
        messages, instead of a single, huge *
        EXPUNGE.
The * EXISTS message
      indicates that new messages were added to the folder, and
      specifies the new number of messages now in the folder.
The * FETCH message indicates
      that an existing message attribute was changed. The next word
      specifies the number of the changed message, and the
      remaining word provide the new message attributes. See the
      description of the
      FETCH command for more
      information.
The server creates snapshots of the folder's index when
      the folder was opened with the SOPEN command. If the NOOP command did not report any changes to
      the folder's contents, the server sends a “*
      SNAPSHOT”, followed by a single word that
      specifies the saved snapshot's identifier. The format of the
      snapshot's identifier is defined by the server, and the
      client should treat it as an opaque text string.
A client issues the NOOP
      command when it wants the server to save the folder's
      snapshot. If the server comes back with other messages that
      report changes to the folder, the client should issue another
      NOOP, and try again.
When the server finds no changes to the folder, and no
      changes at all since the previous NOOP that returned a snapshot, the server
      does not need to make a second, identical snapshot. A client
      may not receive any response to a NOOP; neither a list of folder's changes,
      nor a “*
      SNAPSHOT” message. This indicates that
      the folder's contents have not changed since the last
      snapshot. The client should already know this; but if not,
      that's how the server will remind it.
The server is not required to keep saved snapshots indefinitely. A server does not need to save more than two snapshots per session. After making snapshots A and B, after processing a request to make a third snapshot, C, the server may delete snapshot A.
The server cannot delete snapshot B, because the client
        may crash or be disconnected before it receives the
        server's acknowledgement of creating snapshot C, and the
        next time the client reopens the same folder it will
        specify snapshot B to the SOPEN command. If a client opens a folder
        using SOPEN, but does not name
        either A or B, (or C), the server may conclude that another
        client is opening the same folder, and should not remove
        any of the saved snapshots, unless they are very old.
        C: EXPUNGE 7
        S: * EXPUNGE 7 9 11
        S: +OK Ok.
The EXPUNGE command is
      similar NOOP, except that
      EXPUNGE also removes messages
      from the folder, and the server's response to EXPUNGE includes the removed messages. The
      response also includes any additional messages removed by
      other applications, and any other changes to the folder's
      contents.
Message numbers to remove should follow the EXPUNGE command, as whitespace-delimited
      words. An EXPUNGE without an
      explicit message list is the same as an EXPUNGE that lists all messages that have
      the DELETED flag set.
        C: IDLE
        S: +OK Idling...
        
        [ ... some time passes ... ]
        
        S: * FETCH 15 FLAGS=SEEN,DELETED
        S: * EXPUNGE 4
        C: RESUME
        S: +OK Resumed...
The SMAP client sends the IDLE command to inform the server that
      client wants to know about any changes to the folder's
      contents immediately, without waiting for a NOOP or EXPUNGE. If the folder already had some
      changed made by another process, the server will notify the
      client immediately after the status reply.
The next command sent by the client (at some later time)
      must be the RESUME command.
      RESUME indicates that the client
      is no longer interested in receiving folder updates, and the
      server should wait until another NOOP, EXPUNGE,
      or IDLE before notifying the
      client about any changes to the folder's contents.
The client must be aware that the folder's contents might
      be changed after it sends a RESUME and before the server receives it. In
      this case the client might receive additional single line
      replies before the server responds to the RESUME. The client must still properly
      process single line replies, until it receives the server's
      status reply to the RESUME.