Network Working Group                                       Mark Crispin
Internet Draft: IMAP2bis                        University of Washington
Obsoletes: RFC 1176, 1064                                    August 1993


            INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2bis


Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."  Please check the I-D abstract listing
   contained in each Internet Draft directory to learn the current
   status of any this or any other Internet Draft.

   This draft document will be submitted to the RFC editor as a Proposed
   Standard for the Internet Community.  Discussion and suggestions for
   improvement are requested.  This document will expire before 31
   December 1993.  Distribution of this draft is unlimited.  Comments
   are solicited and should be sent to imap@CAC.Washington.EDU.


Introduction

   The Interactive Mail Access Protocol, Version 2bis (IMAP2bis) allows
   a client to access and manipulate electronic mail on a server.
   IMAP2bis is designed to permit manipulations of remote mailboxes as
   if they were local.  IMAP2bis includes operations for creating,
   deleting, and renaming mailbox folders; checking for new mail;
   permanently removing messages; setting and clearing flags; RFC 822
   and MIME parsing; searching; and selective fetching of message
   attributes, texts, and portions thereof.

   IMAP2bis does not specify a means of posting mail; this function is
   handled by a mail transfer protocol such as SMTP (RFC 821).

   IMAP2bis assumes a reliable data stream such as provided by TCP.
   When TCP is used, an IMAP2bis server listens on port 143.





Crispin                                                         [Page 1]

Internet Draft                  IMAP2bis                 August 13, 1993


System Model and Philosophy

   There are three fundamental models of client/server email: offline,
   online, and disconnected use.  IMAP2bis can be used in any one of
   these three models.

   The offline model is the most familiar form of client/server email
   today, and is used by protocols such as POP-3 (RFC 1225) and UUCP.
   In this model, a client application periodically connects to a
   server.  It downloads all of the pending messages to the client
   machine and deletes these from the server.  Thereafter, all mail
   processing is local to the client.  This model is store-and-forward;
   it moves mail on demand from an intermediate server (maildrop) to a
   single destination machine.

   The online model is most commonly used with remote filesystem
   protocols such as NFS.  In this model, a client application
   manipulates mailbox data on a server machine.  A connection to the
   server is maintained throughout the entire session.  No mailbox data
   is kept on the client; the client retrieves data from the server as
   is needed.  IMAP2bis introduces a form of the online model which
   requires considerably less network bandwidth than a remote filesystem
   protocol, and provides the opportunity for using the server for CPU
   or I/O intensive functions such as parsing and searching.

   The disconnected use model is a hybrid of the offline and online
   models, and is used by protocols such as PCMAIL (RFC 1056).  In this
   model, a client user downloads some set of messages from the server,
   manipulates them offline, then at some later time uploads the
   changes.  The server remains the authoritative repository of the
   messages.  The problems of synchronization (particularly when
   multiple clients are involved) are handled through the means of
   unique identifiers for each message.

   Each of these models have their own strengths and weaknesses, as
   shown in the following table:

      Feature                               Offline Online  Disc
      -------                               ------- ------  ----
      Can use multiple clients               NO      YES     YES
      Minimum use of server connect time     YES     NO      YES
      Minimum use of server resources        YES     NO      NO
      Minimum use of client disk resources   NO      YES     NO
      Multiple remote mailboxes              NO      YES     YES
      Fast startup                           NO      YES     NO
      Mail processing when not online        YES     NO      YES

   Although IMAP2bis was originally designed to accommodate the online



Crispin                                                         [Page 2]

Internet Draft                  IMAP2bis                 August 13, 1993


   model, it can support the other two models as well.  This makes
   possible the creation of clients which can be used in any of the
   three models.  For example, a user may wish to switch between the
   online and disconnected models on a regular basis (e.g. due to
   travel).

   IMAP2bis is designed to transmit message data on demand, and to
   provide the facilities necessary for a client to make an intelligent
   decision on what data it needs at any particular time.  There is
   generally no need to do a wholesale transfer of an entire mailbox or
   even of the complete text of a message.  This makes a difference in
   situations where the mailbox is large, or when the link to the server
   is slow.

   More specifically, IMAP2bis provides the capability of server-based
   RFC 822 and MIME processing.  With this information, it is possible
   for a client to determine in advance whether or not it wishes to
   retrieve a particular message or part of a message.  For example, a
   user connected to an IMAP2bis server via a dialup link can determine
   that a message has a 2000 byte text segment and a 40 megabyte video
   segment, and elect to fetch only the text segment.

   In IMAP2bis, the client/server relationship lasts only for the
   duration of the TCP connection, and mailbox state is maintained on
   the server.  There is no registration of clients.  With the possible
   exception of unique identifiers used in disconnected use operation,
   the client initially has no knowledge of mailbox state and learns it
   from the IMAP2bis server when a mailbox is selected.  This initial
   transfer is minimal; the client requests additional state data as it
   needs it.





















Crispin                                                         [Page 3]

Internet Draft                  IMAP2bis                 August 13, 1993


The Protocol

   The IMAP2bis protocol consists of a sequence of client commands and
   server responses, with server data interspersed between the
   responses.  Unlike most Internet protocols, commands and responses
   are tagged.  That is, a command begins with a unique identifier
   (typically a short alphanumeric sequence such as a Lisp "gensym"
   function would generate e.g., A0001, A0002, etc.) called a tag.  The
   response to the command is given the same tag from the server.

   Additionally, the server may send an arbitrary amount of "unsolicited
   data", which is identified by the special reserved tag of "*".  The
   unsolicited data mechanism is used to transmit most data in IMAP2bis.
   The term "unsolicited data" refers to the fact that the data may have
   been transmitted without any explicit request by the client for that
   data.  No distinction is made in IMAP2bis between data transmitted as
   a result of a client command and data which is unilaterally
   transmitted by the server.  One form of unilaterally transmitted data
   which commonly occurs is an alert of a change to the mailbox made by
   some process other than the IMAP2bis client or server; for example,
   changes in the size of the mailbox (new mail) or in the status of
   individual messages.

   There is another special reserved tag, "+", discussed below.

   The server must be listening for a connection.  When a connection is
   opened the server sends a greeting message and then waits for
   commands.  This greeting is either a PREAUTH (meaning that the user
   has already been identified and authenticated by an external
   mechanism such as rsh) or OK (meaning that the user is not yet
   authenticated) unsolicited response.  The server may also send a BYE
   unsolicited response and close the connection if it rejects the
   connection.

   The client opens a connection and waits for the greeting.  The client
   must not send any commands until it has received the greeting from
   the server.

   Once the greeting has been received, the client may begin sending
   commands.  It is not under any obligation to wait for a server
   response to a command before sending another command, subject to the
   constraints of underlying flow control.  When commands are received
   the server acts on them and responds with command responses, often
   interspersed with data.

   In general, the command responses do not themselves contain the
   requested data, but rather indicate the completion status of the
   request.  There are three fundamental responses: success (OK), error



Crispin                                                         [Page 4]

Internet Draft                  IMAP2bis                 August 13, 1993


   (NO), request faulty or not understood (BAD).  The effect of a
   command can not be considered complete until a command response with
   a tag matching the command is received from the server.

   It is not required that a server process a command to completion
   before beginning processing of the next command, except when the
   processing of the previous command may affect the results of the next
   command by changing the state of the current mailbox.  This has
   certain other effects; for example, this implies that an EXPUNGE
   response can not be transmitted as part of a response to a request
   that may be streamed with another response.

   If authentication has not yet been completed, it must now be done via
   the LOGIN command before any IMAP2bis commands are permitted.  The
   only other permitted command prior to successful authentication is
   LOGOUT.  See the section below on authentication.

   Once authenticated, the client must send a mailbox selection command
   to access the desired mailbox; no mailbox is selected by default.
   Mailbox names are implementation dependent.  However, the word
   "INBOX" must be implemented to mean the primary or default mailbox
   for this user, independent of any other server semantics.  It is
   permitted for a server not to have an INBOX if there is no concept of
   a primary or default mailbox for this user.  The name "INBOX" MUST
   NOT be used for any other purpose.

   On a successful selection, the server will send a list of valid
   flags, number of messages, and number of messages arrived since last
   access for this mailbox as unsolicited data, followed by an OK
   response.  The client may terminate access to this mailbox and access
   a different one with another selection command.

   The client requests mailbox data with FETCH commands, and receives it
   via the unsolicited data mechanism.  Three major categories of
   mailbox data exist.

   The first category is data that is associated with a message as an
   entity in the mailbox.  There are now four such items of data: the
   "internal date", the "RFC 822 size", the "flags", and the "unique
   id".  The internal date is the date and time that the message was
   placed in the mailbox.  The RFC 822 size is the size in bytes of the
   message, expressed as an RFC 822 text string.  The flags are a list
   of status flags associated with the message.  The unique id is an
   identifier which is guaranteed to refer to this message and to none
   other and which, unlike IMAP2bis sequence numbers, persists across
   sessions.

   The second category is data that describes the composition and



Crispin                                                         [Page 5]

Internet Draft                  IMAP2bis                 August 13, 1993


   delivery information of a message; that is, information such as the
   message sender, recipient lists, message-ID, subject, MIME structure,
   etc.  This is the information that is stored in the RFC 822 and MIME
   headers.  In IMAP2bis, the RFC 822 header information that may be
   fetched is called the "envelope" (not to be confused with SMTP
   envelopes).  Similarly, the MIME header information that may be
   fetched is called the "body".  A client can use the parsed envelope
   and body and not worry about having to do its own RFC 822 or MIME
   parsing.

   The third category is textual data, some of which is intended for
   direct human viewing.  IMAP2bis defines six such items:
   RFC822.HEADER, RFC822.HEADER.LINES, RFC822.HEADER.LINES.NOT,
   RFC822.TEXT, RFC822, and MIME body parts.  It is possible to fetch an
   individual MIME body part of a message without fetching any other
   data associated with the message.

   In the simplest case, a client can "FETCH RFC822" to get the entire
   message without any processing.  A more sophisticated client might
   fetch some combination of the first and second categories of data for
   use as a presentation menu.  Then, when the user wishes to read a
   particular message, it will fetch the appropriate texts.

   Data structures in IMAP2bis are represented as an S-expression list
   similar to that used in the Lisp programming language.  An S-
   expression consists of a sequence of data items delimited by space
   and bounded at each end by parentheses.  An S-expression may itself
   contain other S-expressions, using parentheses to indicate nesting.
   S-expression syntax was chosen because it provides a concise and
   precise means of expressing nested data (e.g. MIME structure).

   The client can alter certain data with a STORE command.  As an
   example, a message is deleted from a mailbox by setting the \DELETED
   flag with a STORE command.

   Other client operations that can be done to a mailbox include copying
   messages to other mailboxes, permanently removing deleted messages,
   checking for updated mailbox state, and searching for messages that
   match certain criteria.  It is also possible to select different
   mailboxes, create a new mailbox, and rename or delete an existing
   mailbox.

   The client should terminate the session with the LOGOUT command.  The
   server returns a "BYE" followed by an "OK", at which point both the
   client and the server close the connection.  If the client closes the
   network connection without a LOGOUT command, the server should
   perform its normal logout procedures without attempting any further
   interaction with the client.



Crispin                                                         [Page 6]

Internet Draft                  IMAP2bis                 August 13, 1993


Authentication

   Pre-authentication is only possible when the connection to the
   IMAP2bis service is made through some link protocol which provides
   its own authentication mechanism.  It is not used with a TCP
   connection to port 143.

   An example of pre-authentication is the BSD "RSH" protocol which
   provides authentication through a "trusted host" facility.  Another
   example would be a manual invocation of an IMAP2bis server from a
   logged-in timesharing job.

   A pre-authenticated IMAP2bis server should recognize that
   authentication has already happened, and enter the post-login state.
   In its greeting message, it should use the unsolicited response
   "PREAUTH" instead of "OK" to indicate that external authentication
   has taken place.

   This is an example of a pre-authentication scenario.  In this and all
   other examples in this document, S: indicates server dialog and C:
   indicates client dialog.

           S: * PREAUTH IMAP2bis Server pre-authenticated as user "Smith"
           C: A001 SELECT INBOX
           S: * FLAGS (\Answered \Flagged \Deleted \Seen)
           S: * 19 EXISTS
           S: * 2 RECENT
           S: A001 OK SELECT complete

   A connection that is not pre-authenticated is constrained to using
   the LOGIN command for establishing authentication.  Authentication
   via the LOGIN command is with either a user name and password pair,
   or with an user identifier and Kerberos authenticator.  See the
   description of the LOGIN command for more details.

   Servers may allow non-authenticated access to certain mailboxes or
   bulletin boards.  By convention, this is accomplished with a LOGIN
   command using the userid "anonymous".  A password is still required.
   It is implementation-dependent what requirements, if any, are placed
   upon the password and what access restrictions are placed on
   anonymous users.

   Implementations are NOT required to support pre-authentication,
   Kerberos authentication, or the anonymous convention in order to be
   considered IMAP2bis compliant.






Crispin                                                         [Page 7]

Internet Draft                  IMAP2bis                 August 13, 1993


Definitions of Commands and Responses

     Summary of Defined Commands and Responses

       Commands                            ||  Responses
       --------                            ||  -------
       tag NOOP                            ||  tag OK response_text
       tag LOGIN user password             ||  tag NO response_text
       tag LOGOUT                          ||  tag BAD response_text
       tag CREATE mailbox                  ||  * PREAUTH response_text
       tag DELETE mailbox                  ||  * OK response_text
       tag RENAME old_mailbox new_mailbox  ||  * NO response_text
       tag FIND MAILBOXES pattern          ||  * BAD response_text
       tag FIND ALL.MAILBOXES pattern      ||  * BYE response_text
       tag FIND BBOARDS pattern            ||  * MAILBOX mstring
       tag FIND ALL.BBOARDS pattern        ||  * BBOARD mstring
       tag SUBSCRIBE MAILBOX mailbox       ||  * SEARCH 1#number
       tag UNSUBSCRIBE MAILBOX mailbox     ||  * FLAGS flag_list
       tag SUBSCRIBE BBOARD mailbox        ||  * number EXISTS
       tag UNSUBSCRIBE BBOARD mailbox      ||  * number RECENT
       tag SELECT mailbox                  ||  * number EXPUNGE
       tag EXAMINE mailbox                 ||  * number FETCH data
       tag BBOARD mailbox                  ||  * number COPY
       tag CHECK                           ||  * number STORE data
       tag EXPUNGE                         ||  + text
       tag COPY sequence mailbox           ||
       tag APPEND mailbox string           ||
       tag FETCH sequence data             ||
       tag PARTIAL msgno data start count  ||
       tag STORE sequence data value       ||
       tag UID AFTER uniqueid              ||
       tag UID BEFORE uniqueid             ||
       tag UID COPY sequence mailbox       ||
       tag UID FETCH sequence data         ||
       tag UID STORE sequence data value   ||
       tag SEARCH search_program           ||
       tag x_command arguments             ||

   Note: there is no pairing between commands and responses on the same
   line.  Any command may result in any number (including none at all)
   of any of responses beginning with "*" (referred to as "unsolicited
   data"), followed by one tagged response.









Crispin                                                         [Page 8]

Internet Draft                  IMAP2bis                 August 13, 1993


Commands

   Certain commands and facilities described below are listed as
   "optional".  This term is used to identify server capabilities which
   may not be present in a minimal server implementation or a server
   implementation based upon an older version of this specification.
   Such a server is considered to be IMAP2bis compatible (but not
   necessarily compliant) if it implements all commands which are not
   labeled as "optional".

   An IMAP2bis compliant server implementation MUST implement all of the
   commands and facilities listed below, whether or not they are
   labelled as "optional".

   An IMAP2bis compliant client MUST be prepared to accept BAD as a
   response to any of the optional commands or facilities, and
   substitute alternate or default action in that case.

   If, during the execution of any command, the server observes that the
   mailbox size has changed, the server should output an unsolicited
   EXISTS and RECENT response reflecting the changed size to alert the
   client.  Similarly, any observed change in message status should
   cause an unsolicited FETCH response with the new flag data.


   tag NOOP

      The NOOP command returns an OK to the client.  By itself, it does
      nothing else.  However, since any command can return a status
      update as unsolicited data, this command can be used to poll for
      new mail or for message status updates.

      Another possible use of this command is for the client to "ping"
      the server so that the client and server know that each other are
      still alive.  This is useful with servers that have an inactivity
      autologout timer.


   tag LOGIN user password

      The LOGIN command identifies the user to the server and carries
      the password authenticating this user.  This information is used
      by the server to control access to the mailboxes.

      EXAMPLE:  a001 LOGIN SMITH SESAME
      logs in as user SMITH with password SESAME.

      If a server supports authentication via Kerberos, it may accept



Crispin                                                         [Page 9]

Internet Draft                  IMAP2bis                 August 13, 1993


      the string "@KERBEROS:" followed by the hexadecimal representation
      of a Kerberos authenticator.

      EXAMPLE: The following is a Kerberos login scenario (note that the
      line breaks in the sample authenticator are for editorial clarity
      and are not in a real authenticator):

         S: * OK Kerberos IMAP2bis Server
         C: a001 LOGIN smith @KERBEROS:040700414e445245572e434d552e4544550
            038202c868f3890b377fc8266acc1bedb96b80d3fa76489898e74cd1c952dc
            4003ea3428f29f1c470016cf5adc22f939e6deff2747254c1815d5b0b90d4c
            5a2cba21eb0abe32f9acbf568d751bf4cc13f5ba4e6d82c638a8b5421
         S: a001 OK [df84a4cb8323454f] Login OK via Kerberos

      The token in the brackets in the OK response is the Kerberos
      authentication response, encrypted with the session key in network
      byte order and an incremented checksum as in the usual Kerberos
      procedure.


   tag LOGOUT

      The LOGOUT command informs the server that the client is done with
      the session.  The server should send an unsolicited BYE response
      before the (tagged) OK response, and then close the network
      connection.


   Mailbox manipulation commands: CREATE, DELETE, RENAME

   These commands permit the manipulation of entire mailboxes.  Server
   support for mailbox manipulation commands is optional.

      tag CREATE mailbox

         The CREATE command creates a mailbox with the given name.  This
         command returns an OK response only if a new mailbox with that
         name has been created.  It is an error to attempt to create a
         mailbox with a name that refers to an extant mailbox.  Any
         error in creation will return a NO response.

         Creating INBOX is not permitted.  If there is a primary or
         default mailbox for this user, it MUST exist and be called
         INBOX.







Crispin                                                        [Page 10]

Internet Draft                  IMAP2bis                 August 13, 1993


      tag DELETE mailbox

         The DELETE command deletes a mailbox with the given name.  This
         command returns an OK response only if a mailbox with that name
         has been deleted.  It is an error to attempt to delete a
         mailbox name that does not exist.  Any error in deletion will
         return a NO response.

         A server SHOULD NOT attempt to test that a mailbox is empty
         prior to permitting deletion; this would prevent the deletion
         of a mailbox which for some reason can not be opened or
         expunged, leaving to possible denial of service problems.  Any
         such checking should be left to the discretion of the client.

         Deleting INBOX is not permitted.


      tag RENAME old_mailbox new_mailbox

         The RENAME command changes the name of a mailbox.  This command
         returns an OK response only if a mailbox with the old name
         exists and has been successfully renamed to the new name.  It
         is an error to attempt to rename with an old mailbox name that
         does not exist or a new mailbox name which already exists.  Any
         error in renaming will return a NO response.

         Renaming INBOX is permitted.  A new, empty INBOX is created in
         its place.


   FIND commands

   The FIND commands return some set of unsolicited MAILBOX or BBOARD
   replies, depending upon the type of FIND, that have as their value a
   single mailbox name.

   Three wildcard characters are defined in the pattern argument.  "*"
   specifies any number (including zero) characters may match at this
   position.  "%" and "?"  specify a single character may match at this
   position.  For example, FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR
   and FOO.BAR, whereas FOO%BAR and FOO?BAR match only FOO.BAR.  "*"
   will match all mailboxes.

   Server support for all forms of FIND is optional.  If a FIND command
   returns BAD as a response then the client can make no assumptions
   about what mailboxes exist on the server.





Crispin                                                        [Page 11]

Internet Draft                  IMAP2bis                 August 13, 1993


      tag FIND MAILBOXES pattern

         The FIND MAILBOXES command accepts as an argument a pattern
         (including wildcards) that specifies some set of mailbox names
         that the user has declared as being "active" or "subscribed."
         The exact meaning of this is implementation-dependent, since
         the concept of a set of "active" or "subscribed" mailboxes that
         is preserved across sessions may not be meaningful for a
         particular server or server implementation.  If the SUBSCRIBE
         MAILBOX and UNSUBSCRIBE MAILBOX commands are implemented then
         this command returns the list manipulated by those commands.

         EXAMPLE:  C: A002 FIND MAILBOXES *
                   S: * MAILBOX FOOBAR
                   S: * MAILBOX GENERAL
                   S: A002 OK FIND completed


      tag FIND ALL.MAILBOXES pattern

         The FIND ALL.MAILBOXES command is similar to FIND MAILBOXES;
         however, it should return a complete list of all mailboxes
         available to the user.  Data is returned as in FIND MAILBOXES.

         The special name INBOX is included in the output from FIND
         ALL.MAILBOXES unless INBOX is not supported by this server or
         for this user.  The criteria for omitting INBOX is whether or
         not SELECT INBOX will return failure; it is not relevant
         whether or not the user's actual INBOX resides on this or some
         other server.  FIND MAILBOXES and SUBSCRIBE MAILBOX provide a
         mechanism for the user to identify that this is his or her real
         INBOX.

         If FIND ALL.MAILBOXES is implemented FIND MAILBOXES must also
         be implemented, even if it returns the same information.  Also,
         FIND ALL.MAILBOXES must, at least, return all the mailbox names
         that are returned by FIND MAILBOXES.

         The exact meaning of this is implementation-dependent, since
         the concept of a bounded or deterministic set of "mailboxes
         available to the user" may not be meaningful for a particular
         server or server implementation.


      tag FIND BBOARDS pattern

         The FIND BBOARDS command accepts as an argument a pattern that
         specifies some set of bulletin board names that the user has



Crispin                                                        [Page 12]

Internet Draft                  IMAP2bis                 August 13, 1993


         declared as being "active" or "subscribed."  Wildcards are
         permitted as in FIND MAILBOXES.

         The FIND BBOARDS command will return some set of unsolicited
         BBOARD replies that have as their value a single bulletin board
         name.

         EXAMPLE:  C: A002 FIND BBOARDS *
                   S: * BBOARD FOOBAR
                   S: * BBOARD GENERAL
                   S: A002 OK FIND completed

         The exact meaning of this is implementation-dependent, since
         the concept of a set of "active" or "subscribed" bboards that
         is preserved across sessions may not be meaningful for a
         particular server or server implementation.  If the SUBSCRIBE
         BBOARD and UNSUBSCRIBE BBOARD commands are implemented then
         this command returns the list manipulated by those commands.


      tag FIND ALL.BBOARDS pattern

         The FIND ALL.BBOARDS command is similar to FIND BBOARDS;
         however, it should return a complete list of all bulletin
         boards available to the user.  Data is returned as in FIND
         BBOARDS.

         If FIND ALL.BBOARDS is implemented FIND BBOARDS must also be
         implemented, even if it returns the same information.  Also,
         FIND ALL.BBOARDS must, at least, return all the bboard names
         that are returned by FIND BBOARDS.

         The exact meaning of this is implementation-dependent, since
         the concept of a bounded or deterministic set of "bboards
         available to the user" may not be meaningful for a particular
         server or server implementation.


   Subscription commands

   These commands permit the manipulation of mailbox or bulletin board
   subscriptions.  Server support for subscription commands is optional.
   Subscription status should be preserved between sessions.


      tag SUBSCRIBE MAILBOX mailbox

         The SUBSCRIBE MAILBOX command adds the specified mailbox name



Crispin                                                        [Page 13]

Internet Draft                  IMAP2bis                 August 13, 1993


         to the list of "active" or "subscribed" mailboxes as returned
         by the FIND MAILBOXES command.  This command returns an OK
         response only if the subscription is successful.

         If SUBSCRIBE MAILBOX is implemented then FIND MAILBOXES must
         also be implemented, and FIND ALL.MAILBOXES should be
         implemented.


      tag UNSUBSCRIBE MAILBOX mailbox

         The UNSUBSCRIBE MAILBOX command removes the specified mailbox
         name from the list of "active" or "subscribed" mailboxes as
         returned by the FIND MAILBOXES command.  This command returns
         an OK response only if the unsubscription is successful.

         If UNSUBSCRIBE MAILBOX is implemented then SUBSCRIBE MAILBOXES
         and FIND MAILBOXES must also be implemented, and FIND
         ALL.MAILBOXES should be implemented.


      tag SUBSCRIBE BBOARD bboard

         The SUBSCRIBE BBOARD command adds the specified mailbox name to
         the list of "active" or "subscribed" bulletin boards as
         returned by the FIND BBOARDS command.  This command returns an
         OK response only if the subscription is successful.

         If SUBSCRIBE BBOARD is implemented then FIND BBOARDS must also
         be implemented, and FIND ALL.BBOARDS should be implemented.


      tag UNSUBSCRIBE BBOARD bboard

         The UNSUBSCRIBE BBOARD command removes the specified mailbox
         name from the list of "active" or "subscribed" bulletin boards
         as returned by the FIND BBOARDS command.  This command returns
         an OK response only if the unsubscription is successful.

         If UNSUBSCRIBE BBOARD is implemented then SUBSCRIBE BBOARDS and
         FIND BBOARDS must also be implemented, and FIND ALL.BBOARDS
         should be implemented.


   tag SELECT mailbox

      This command select a particular mailbox.  The server must check
      that the user is permitted read access to this mailbox.  Before



Crispin                                                        [Page 14]

Internet Draft                  IMAP2bis                 August 13, 1993


      returning an OK to the client, the server must send the following
      unsolicited data to the client:
         FLAGS        mailbox's defined flags
         <n> EXISTS   the number of messages in the mailbox
         <n> RECENT   the number of new messages in the mailbox
      in order to define the initial state of the mailbox at the client.

      Multiple selection commands are permitted in a session, in which
      case the previous mailbox is automatically deselected when a new
      selection is made.

      The mailbox name INBOX is a special name reserved to mean "the
      primary mailbox for this user on this server".  The format of
      other mailbox names is implementation dependent.

      The text of an OK response to the SELECT command should begin with
      either "[READ-ONLY]" or "[READ-WRITE]" to show the mailbox's
      access status.


   tag EXAMINE mailbox

      The EXAMINE command is similar to SELECT, and returns the same
      output; however, the selected mailbox is identified as read-only
      and no changes are permitted to this mailbox.  EXAMINE has the
      same mailbox namespace as SELECT.

      Server support for EXAMINE is optional.


   tag BBOARD mailbox

      The BBOARD command is similar to SELECT, and returns the same
      output.  Its argument is a shared mailbox (bulletin board) name
      instead of an ordinary mailbox.  There is no requirement that the
      namespace for BBOARD be the same as that for SELECT and EXAMINE.
      BBOARD also differs from EXAMINE in that it may allow changes
      (e.g. marking a message as seen or deleted) to a mailbox; the
      exact handling of this is implementation dependent.

      Server support for BBOARD is optional.


   tag CHECK

      The CHECK command requests a checkpoint of the mailbox.  CHECK may
      cause an operation which may take a non-instantaneous amount of
      real-time to complete.  The exact meaning of a checkpoint is



Crispin                                                        [Page 15]

Internet Draft                  IMAP2bis                 August 13, 1993


      implementation-dependent.  Possible interpretations include
      forcing a update of the server's disk of all changes made to the
      selected mailbox, rescanning of the entire mailbox, etc.  If an
      implementation has no such considerations, CHECK should be
      equivalent to NOOP.

      CHECK should NOT be used to poll for new mail; new mail checking
      happens implicitly as part of every command.  NOOP should be used
      for any new mail polling.  CHECK should NOT be used to get the
      current size of the mailbox; there is no guarantee that CHECK will
      cause an EXISTS or RECENT unsolicited response.


   tag EXPUNGE

      The EXPUNGE command permanently removes all messages with the
      \DELETED flag set from the currently selected mailbox.  Before
      returning an OK to the client, for each message that is removed,
      an unsolicited EXPUNGE response is sent.  The message number for
      each successive message in the mailbox is immediately decremented
      by 1; this means that if the last 5 messages in a 9-message mail
      file are expunged you will receive 5 unsolicited EXPUNGE responses
      for message 5.


   tag COPY sequence mailbox

      The COPY command copies the specified message(s) to the specified
      destination mailbox.

      If the destination mailbox does not exist, a server that supports
      the CREATE command SHOULD return an error.  It SHOULD NOT
      automatically create the mailbox.  Unless it is certain that the
      destination mailbox can not be created, the server MUST, prior to
      the tagged NO response, send an unsolicited OK response with text
      beginning with the string "[TRYCREATE]".  This gives a hint to the
      client that it can attempt a CREATE command and retry the COPY if
      the CREATE is successful.

      If the COPY command is unsuccessful for any reason, IMAP2bis
      compliant server implementations MUST restore the destination
      mailbox to its state prior to the COPY.

      EXAMPLE:  A003 COPY 2:4 MEETING
      copies messages 2, 3, and 4 to mailbox "MEETING".






Crispin                                                        [Page 16]

Internet Draft                  IMAP2bis                 August 13, 1993


   tag APPEND mailbox string

      The APPEND command appends the string, which is in the format of
      an RFC 822 message, to the specified mailbox.  If the append is
      unsuccessful for any reason the mailbox must be restored to its
      state prior to the append; no partial appending is permitted.  If
      the mailbox is presently selected, the normal new mail actions
      should occur.

      If the destination mailbox does not exist, a server MUST return an
      error, and MUST NOT automatically create the mailbox.  Unless it
      is certain that the destination mailbox can not be created, the
      server MUST, prior to the tagged NO response, send an unsolicited
      OK response with text beginning with the string "[TRYCREATE]".
      This gives a hint to the client that it can attempt a CREATE
      command and retry the APPEND if the CREATE is successful.

      Note that this functionality is unsuitable for message delivery,
      because it does not provide a mechanism to transfer RFC 821 (SMTP)
      envelope information.

      Server support for APPEND is optional.


   tag FETCH sequence data

      The FETCH command retrieves data associated with a message in the
      mailbox.  The data items to be fetched may be either a single atom
      or an S-expression list.  The currently defined data items that
      can be fetched are:

      ALL             Macro equivalent to:
                      (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)

      BODY            The MIME body structure of the message.  The
                      body is computed by the server by parsing the
                      MIME header lines.

                      Server support for this data item is optional.

      BODY[section]   The text of a particular body section.  The
                      section specification is a set of one or more
                      part numbers delimited by periods.

                      Single-part messages only have a part 1.

                      Multipart messages are assigned consecutive
                      part numbers, as they occur in the message.



Crispin                                                        [Page 17]

Internet Draft                  IMAP2bis                 August 13, 1993


                      If a particular part is of type message or multipart,
                      its parts must be indicated by a period followed by
                      the part number within that nested multipart part.
                      It is not permitted to fetch a multipart part
                      itself, only its individual members.

                      A part of type MESSAGE also has nested parts,
                      which are the parts of the MESSAGE part's body.

                      Every message has at least one part.

                      EXAMPLE: Here is a very complex message with its
                      associated section specifications.
                           1   TEXT/PLAIN
                           2   APPLICATION/OCTET-STREAM
                           3   MESSAGE/RFC822
                           3.1   TEXT/PLAIN
                           3.2   APPLICATION/OCTET-STREAM
                               MULTIPART/MIXED
                           4.1   IMAGE/GIF
                           4.2   MESSAGE/RFC822
                           4.2.1   TEXT/PLAIN
                                   MULTIPART/ALTERNATIVE
                           4.2.2.1  TEXT/PLAIN
                           4.2.2.2  TEXT/RICHTEXT
                      Note that there is no section specification for
                      the Multi-part parts (no section 4 or 4.2.2).

                      The \SEEN flag is implicitly set; if this causes
                      the flags to change they should be included as
                      part of the fetch results.

                      Server support for this data item is optional.

      ENVELOPE        The envelope of the message.  The envelope is
                      computed by the server by parsing the RFC 822
                      header into the component parts, defaulting
                      various fields as necessary.

      FAST            Macro equivalent to:
                      (FLAGS INTERNALDATE RFC822.SIZE)

      FLAGS           The flags that are set for this message.

      FULL            Macro equivalent to:
                      (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY)

                      Server support for this data item is optional.



Crispin                                                        [Page 18]

Internet Draft                  IMAP2bis                 August 13, 1993


      INTERNALDATE    The date and time the message was written to
                      the mailbox.

      RFC822          The message in RFC 822 format.  The \SEEN
                      flag is implicitly set; if this causes the
                      flags to change they should be included as
                      part of the fetch results.  This is the
                      concatenation of RFC822.HEADER and RFC822.TEXT.

      RFC822.HEADER   The RFC 822 format header of the message as
                      stored on the server including the delimiting
                      blank line between the header and the body.

      RFC822.HEADER.LINES header_line_list
                      All header lines (including continuation lines)
                      of the RFC 822 format header of the message
                      with a field-name (as defined in RFC 822) that
                      matches any of the strings in header_line_list.
                      The matching is case-independent but otherwise
                      exact.

                      This is used to obtain a filtered header
                      containing only desired header lines.

                      Server support for this data item is optional.

      RFC822.HEADER.LINES.NOT header_line_list
                      All header lines (including continuation lines)
                      of the RFC 822 format header of the message
                      with a field-name (as defined in RFC 822) that
                      does not match any of the strings in
                      header_line_list.  The matching is
                      case-independent but otherwise exact.

                      This is used to obtain a filtered header not
                      containing undesired header lines.

                      Server support for this data item is optional.

      RFC822.SIZE     The number of characters in the message as
                      expressed in RFC 822 format.

      RFC822.TEXT     The text body of the message, omitting the
                      RFC 822 header.  The \SEEN flag is implicitly
                      set; if this causes the flags to change they
                      should be included as part of the fetch results.





Crispin                                                        [Page 19]

Internet Draft                  IMAP2bis                 August 13, 1993


      UID             The unique identifier for the message.

                      Server support for this data item is optional.

      EXAMPLES:

      A003 FETCH 2:4 ALL
         fetches the flags, internal date, RFC 822 size, and envelope
         for messages 2, 3, and 4.

      A004 FETCH 3 RFC822
         fetches the RFC 822 representation for message 3.

      A005 FETCH 4 (FLAGS RFC822.HEADER)
         fetches the flags and RFC 822 format header for message 4.


   tag PARTIAL msgno data start_byte byte_count

      The PARTIAL command is equivalent to the associated FETCH command,
      with the added functionality that only the specified number of
      bytes, beginning at the specified starting byte, are returned.
      Note that only a single message can be fetched at a time.  The
      first byte of a message, and hence the minimum for the starting
      byte, is byte 1.

      The following FETCH items are valid data for PARTIAL: RFC822,
      RFC822.HEADER, RFC822.TEXT, and BODY[section].

      Any partial fetch which attempts to read beyond the end of the
      text is truncated as appropriate.  If the starting byte is beyond
      the end of the text, an empty string is returned.

      The data is returned with the FETCH response.  There is no
      indication of the range of the partial data in this response; thus
      it is generally not possible to implement caching with PARTIAL
      data.  It is also not possible to stream multiple PARTIAL commands
      of the same data item without processing and synchronizing at each
      step, since each PARTIAL fetch of data replaces any prior
      (PARTIAL) FETCH of that data.

      Note that when partial fetching it is possible to break in the
      middle of a a line or a criticial sequence such as a BASE64
      quadruple or QUOTED-PRINTABLE shift.  Implementations using
      partial fetching should keep this in mind.  There is no
      requirement that partial fetches follow any sequence; so if it
      turns out that a partial fetch of bytes 1 through 10000 breaks in
      an awkward place, it is permitted to continue with a partial fetch



Crispin                                                        [Page 20]

Internet Draft                  IMAP2bis                 August 13, 1993


      of 9987 through 19987, etc.

      The handling of the \SEEN flag is the same as with the FETCH
      command.

      Server support for PARTIAL is optional.


   tag STORE sequence data value

      The STORE command alters data associated with a message in the
      mailbox.  The currently defined data items that can be stored are:

         FLAGS           Replace the flags for the message with the
                         argument (in flag list format).

         +FLAGS          Add the flags in the argument to the
                         message's flag list.

         -FLAGS          Remove the flags in the argument from the
                         message's flag list.

      EXAMPLE:  A003 STORE 2:4 +FLAGS (\DELETED)
      marks messages 2, 3, and 4 for deletion.


   UID commands

   These commands use unique identifiers instead of message numbers in
   their arguments to reference a particular message or range of
   messages.

   Sequence ranges are permitted; note however that there is no
   guarantee that unique identifiers be contiguous.  A non-existant
   unique identifier within a sequence range is ignored without any
   error message generated.

   Because of the potential for ambiguity, the UID command does not
   change responses.  That is, the number after the "*" in an
   unsolicited FETCH response is a message number, not a unique
   identifier.  However, servers MUST implicitly include UID as part of
   any FETCH response caused by a UID command, regardless of whether or
   not UID was specified.








Crispin                                                        [Page 21]

Internet Draft                  IMAP2bis                 August 13, 1993


   EXAMPLE:  C: A003 UID FETCH 4827313:4828442 FLAGS
             S: * 23 FETCH (FLAGS (\SEEN) UID 4827313)
             S: * 24 FETCH (FLAGS (\SEEN) UID 4827943)
             S: * 25 FETCH (FLAGS (\SEEN) UID 4828442)
             S: A003 UID FETCH completed


      tag UID AFTER uniqueid

         The UID AFTER command is used to determine what unique
         identifiers exist that are greater than the specified unique
         identifier.  It returns unsolicited FETCH responses for each
         such message.

         For example, if the specified unique identifier refers to
         message 572 in a mailbox with 613 messages, the results
         returned are equivalent to doing "FETCH 573:613 UID".


      tag UID BEFORE uniqueid

         The UID BEFORE command is used to determine what unique
         identifiers exist that are less than the specified unique
         identifier.  It returns unsolicited FETCH responses for each
         such message.

         For example, if the specified unique identifier refers to
         message 572 in a mailbox with 613 messages, the results
         returned are equivalent to doing "FETCH 1:571 UID".


      tag UID COPY sequence mailbox

         The UID COPY command is identical to the COPY command, with the
         exception that the numbers used in the sequence are unique
         identifiers instead of message numbers.


      tag UID FETCH sequence data

         The UID FETCH command is identical to the FETCH command, with
         the exception that the numbers used in the sequence are unique
         identifiers instead of message numbers.


      tag UID STORE sequence data value

         The UID STORE command is identical to the STORE command, with



Crispin                                                        [Page 22]

Internet Draft                  IMAP2bis                 August 13, 1993


         the exception that the numbers used in the sequence are unique
         identifiers instead of message numbers.


   tag SEARCH search_criteria

      The SEARCH command searches the mailbox for messages that match
      the given set of criteria.  The unsolicited SEARCH <1#number>
      response from the server is a list of messages that express the
      intersection (AND function) of all the messages which match that
      criteria.  For example,
              A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87
      returns the message numbers for all deleted messages from Smith
      that were placed in the mail file since October 1, 1987.

      In all search criteria which use strings, a message matches the
      criteria if the string is a substring of that field.  The matching
      is case-independent except as noted below.

      The string may be in RFC 1342 format to express a character set
      other than US-ASCII.  In this case, the criteria matches if the
      string matches the character set and characters of a substring of
      that field.  A server implementation may omit case-independent
      matching on RFC 1342 strings.

      The currently defined search criteria are:

      ALL             All messages in the mailbox; the default
                      initial criterion for ANDing.

      ANSWERED        Messages with the \ANSWERED flag set.

      BCC istring     Messages which contain the specified string
                      in the envelope's BCC field.

      BEFORE date     Messages whose internal date is earlier than
                      the specified date.

      BODY istring    Messages which contain the specified string
                      in the body of the message.

      CC istring      Messages which contain the specified string
                      in the envelope's CC field.

      DELETED         Messages with the \DELETED flag set.

      FLAGGED         Messages with the \FLAGGED flag set.




Crispin                                                        [Page 23]

Internet Draft                  IMAP2bis                 August 13, 1993


      FROM istring    Messages which contain the specified string
                      in the envelope's FROM field.

      KEYWORD flag    Messages with the specified flag set.

      NEW             Messages which have the \RECENT flag set but
                      not the \SEEN flag.  This is functionally
                      equivalent to "RECENT UNSEEN".

      OLD             Messages which do not have the \RECENT flag
                      set.

      ON date         Messages whose internal date is within the
                      specified date.

      RECENT          Messages which have the \RECENT flag set.

      SEEN            Messages which have the \SEEN flag set.

      SINCE date      Messages whose internal date is later than
                      the specified date.

      SUBJECT istring Messages which contain the specified string
                      in the envelope's SUBJECT field.

      TEXT istring    Messages which contain the specified string.

      TO istring      Messages which contain the specified string in
                      the envelope's TO field.

      UNANSWERED      Messages which do not have the \ANSWERED flag
                      set.

      UNDELETED       Messages which do not have the \DELETED flag
                      set.

      UNFLAGGED       Messages which do not have the \FLAGGED flag
                      set.

      UNKEYWORD flag  Messages which do not have the specified flag
                      set.

      UNSEEN          Messages which do not have the \SEEN flag set.








Crispin                                                        [Page 24]

Internet Draft                  IMAP2bis                 August 13, 1993


Responses

   The first group of responses complete a request, and indicate whether
   or not the command was successful.  The response text is a line of
   human readable text, optionally prefixed by an atom inside square
   brackets that conveys a special information token between cooperating
   servers and clients.

   The currently defined special information tokens are:

      PARSE           An error occurred in parsing the RFC 822 or MIME
                      headers of a message in the mailbox.

      READ-ONLY       The mailbox is open read-only, or its access while
                      open has changed from read-write to read-only.

      READ-WRITE      The mailbox is open read-write, or its access while
                      open has changed from read-only to read-write.

      TRYCREATE       An APPEND or COPY attempt failed because the target
                      mailbox does not exist.  The server sends this as a
                      hint to the client that the operation would probably
                      succeed if the mailbox is first created by means of
                      the CREATE command.

      hex string      A hexadecimal string is returned as a special
                      information token to represent a Kerberos return
                      authenticator.  This only occurs in response to a
                      LOGIN command that uses Kerberos authentication.

   Other special information tokens defined by particular client or
   server implementations should be prefixed with an "X" until such time
   as they are added to a revision of this protocol.


   tag OK response_text

      This response identifies successful completion of the command with
      that tag.  The response text may be useful in a protocol telemetry
      log for debugging purposes.


   tag NO response_text

      This response identifies unsuccessful completion of the command
      with that tag.  The text is a line of human-readable text that
      probably should be displayed to the user in an error report by the
      client.



Crispin                                                        [Page 25]

Internet Draft                  IMAP2bis                 August 13, 1993


   tag BAD response_text

      This response identifies faulty protocol received from the client;
      The text is a line of human-readable text that should be recorded
      in any telemetry as part of a bug report to the maintainer of the
      client.


   The second group of responses convey human-readable information.  The
   response text is a line of human readable text, optionally prefixed
   by an atom inside square brackets that conveys special information
   between cooperating servers and clients.


   * PREAUTH response_text

      This response is one of three possible greetings at session
      startup.  It indicates that the session has already been
      authenticated by external means and thus no LOGIN command is
      needed.


   * OK response_text

      This response identifies an information message from the server.
      It does not indicate completion of any particular request, nor is
      it necessarily related to any request.  The text is a line of
      human-readable text that should be presented to the user as an
      information message.

      This response is also one of three possible greetings at session
      startup.  It indicates that the session is not yet authenticated
      and that a LOGIN command is needed.


   * NO response_text

      This response identifies a warning message from the server.  It
      does not indicate completion of any request, nor is it necessarily
      related to any request.  The text is a line of human-readable text
      that should be presented to the user as a warning of improper
      operation.


   * BAD response_text

      This response identifies a serious error message from the server.
      It does not indicate completion of any request, nor is it



Crispin                                                        [Page 26]

Internet Draft                  IMAP2bis                 August 13, 1993


      necessarily related to any request.  It may also indicate a faulty
      command from the client in which a tag could not be parsed.  The
      text is a line of human-readable text that should be presented to
      the user as a serious or possibly fatal error.


   * BYE text

      This response identifies that the server is about to close the
      connection.  The text is a line of human-readable text that should
      be displayed to the user in a status report by the client.  This
      may be sent as part of a normal logout sequence, or as a panic
      shutdown announcement by the server.  It is also used by some
      servers as an announcement of an inactivity autologout.

      This response is also one of three possible greetings at session
      startup.  It indicates that the server is not willing to accept a
      session from this client at the present time.


   The third group of responses convey data about the mailbox or
   messages inside the mailbox.  This is how message data is transmitted
   from the server to the client.


   * MAILBOX mstring

      This response occurs as a result of a FIND command for MAILBOXES
      and ALL.MAILBOXES.  The string is a mailbox name that matches the
      pattern in the command.


   * BBOARD mstring

      This response occurs as a result of a FIND command for BBOARDS and
      ALL.BBOARDS.  The string is a bulletin board name that matches the
      pattern in the command.


   * SEARCH number(s)

      This response occurs as a result of a SEARCH command.  The
      number(s) refer to those messages that match the search criteria.
      Each number is delimited by a space, e.g., "SEARCH 2 3 6".







Crispin                                                        [Page 27]

Internet Draft                  IMAP2bis                 August 13, 1993


   * FLAGS flag_list

      This response occurs as a result of a selection command (SELECT,
      BBOARD, and EXAMINE).  The flag list are the list of flags (at a
      minimum, the system-defined flags) that are applicable for this
      mailbox.  Flags other than the system flags are a function of the
      server implementation.


   * number message_data

      This response occurs as a result of any command when a mailbox is
      selected. The message_data is one of the following:


      EXISTS  The specified number of messages exists in the mailbox.


      RECENT  The specified number of messages have arrived since the
              previous time this mailbox was read.


      EXPUNGE The specified message number has been permanently
              removed from the mailbox, and the next message in the
              mailbox (if any) becomes that message number.

              An unsolicited EXPUNGE response MUST NOT be sent except
              while responding to a request other than FETCH, STORE,
              or SEARCH.  All references to message numbers sent after
              an unsolicited EXPUNGE response are adjusted to reflect
              the effect of the expunge.

                 Discussion: a potential ambiguity exists with
                 the FETCH, STORE, and SEARCH requests if the
                 server is permitted to send unsolicited EXPUNGE
                 responses.  This is because these requests can be
                 streamed.  If two successive FETCH requests are
                 streamed, and if during the time of the processing
                 of the first request there is an expunge response,
                 then the sequence of the second request is no
                 longer valid.


      FETCH data
              This is the principle means by which data about a
              message is returned to the client.  The data is in a
              S-expression form, and consists of a sequence of pairs
              of data item name and their values.  The current data



Crispin                                                        [Page 28]

Internet Draft                  IMAP2bis                 August 13, 1993


              items are:

         BODY          An S-expression format list that describes the
                       body of a message.  The body is computed by the
                       server by parsing the RFC 822 header and body into
                       the component parts, defaulting various fields
                       as necessary.

                       Multiple parts are indicated by S-expression
                       nesting.  In this case, instead of a body type
                       as the first element of the list there is a nested
                       body.  The last element of the list is the multipart
                       subtype (mixed, digest, parallel, alternative, etc.).

                       The basic fields of a non-multipart body part are in
                       the following order:
                         body type - an atom giving the content type name
                           as defined in MIME
                         body subtype - a string giving the content subtype
                           name as defined in MIME
                         body parameter list - an S-expression list of
                           attribute/value pairs [e.g. (foo bar baz rag)
                           where "bar" is the value of "foo" and "rag" is
                           the value of "baz"] as defined in MIME.
                         body id - a string giving the content id as
                           defined in MIME.
                         body description - a string giving the content
                           description as defined in MIME.
                         body encoding - a string giving the content
                           transfer encoding as defined in MIME.
                         body size - a number giving the size of that
                           body in bytes.  Note that this size is the
                           size in its transfer encoding and not the
                           resulting size.

                       A body type of type MESSAGE and subtype RFC822
                       contains, immediately after the basic fields,
                       the envelope of the encapsulated message, its
                       body structure, and its size in text lines.

                       A body type of type TEXT contains, immediately
                       after the basic fields, the size of the body
                       in text lines.

         BODY[section] A string expressing the body contents of the
                       specified section.  This string is transmitted
                       as 7-bit US-ASCII, and interpreted according to
                       the content transfer encoding and the body type



Crispin                                                        [Page 29]

Internet Draft                  IMAP2bis                 August 13, 1993


                       and subtype.

                       Note that 7-bit US-ASCII is the transport format
                       and NOT necessarily the byte size or character
                       set of the result.  The resulting data may be
                       8-bit; it may also be some other character set
                       or binary.

         ENVELOPE      An S-expression format list that describes the
                       envelope of a message.  The envelope is computed
                       by the server by parsing the RFC 822 header into
                       the component parts, defaulting various fields
                       as necessary.

                       The fields of the envelope are in the following
                       order: date, subject, from, sender, reply-to, to,
                       cc, bcc, in-reply-to, and message-id.  The date,
                       subject, in-reply-to, and message-id fields are
                       strings.  The from, sender, reply-to, to, cc,
                       and bcc fields are lists of addresses.

                       An address is an S-expression format list that
                       describes an electronic mail address.  The fields
                       of an address are in the following order:
                       personal name, source-route (a.k.a. the
                       at-domain-list in SMTP), mailbox name, and
                       host name.

                       Any field of an envelope or address that is
                       not applicable is presented as the atom NIL.
                       Note that the server must default the reply-to
                       and sender fields from the from field; a client is
                       not expected to know to do this.

         FLAGS         An S-expression format list of flags that are set
                       for this message.  This may include the following
                       system flags:

                       \RECENT       Message arrived since the
                                      previous time this mailbox
                                      was read
                       \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




Crispin                                                        [Page 30]

Internet Draft                  IMAP2bis                 August 13, 1993


         INTERNALDATE  A string containing the date and time the
                       message was written to the mailbox.

         RFC822        A string expressing the message in RFC 822
                       format.

         RFC822.HEADER A string expressing the RFC 822 format header
                       of the message, including the delimiting
                       blank line between the header and the body.
                       This is used for the FETCH data items
                       RFC822.HEADER, RFC822.HEADER.LINES, and
                       RFC822.HEADER.LINES.NOT (note that a blank
                       line is always included regardless of header
                       line restrictions).

         RFC822.SIZE   A number indicating the number of
                       characters in the message as expressed
                       in RFC 822 format.

         RFC822.TEXT   A string expressing the text body of the
                       message, omitting the RFC 822 header.

         UID           A string expressing the unique identifier
                       of the message.


      COPY    Obsolete.  New server implementations MUST NOT transmit
              this response.  Client implementations SHOULD ignore
              this response (not report an error).


      STORE data
              Obsolete and functionally equivalent to FETCH.  New
              server implementations MUST NOT transmit this response.
              Client implementations SHOULD treat this response as
              equivalent to the FETCH response.


   The final group of responses contains a single, special purpose
   response.

   + text

      This response identifies that the server is ready to accept the
      text of a literal from the client.  The text of this response is a
      line of human-readable text of the server's choosing (it is
      generally never seen by a client's human user).




Crispin                                                        [Page 31]

Internet Draft                  IMAP2bis                 August 13, 1993


      The purpose of this command is to solve a synchronization problem
      which can occur if one of the strings in a command is a literal.
      This may occur when logging in (if the password contains "funny"
      characters) and especially with the APPEND command (since the
      message sent consists of multiple lines).

      Normally, a command from the client is a single text line.  If the
      server detects an error in the command, it can simply discard the
      remainder of the line.  It cannot do this for commands that
      contain literals, since a literal can be an arbitrarily long
      amount of text, and the server may not even be expecting a
      literal.  This mechanism is provided so the client knows not to
      send a literal until the server expects it, preserving
      client/server synchronization.

      No such synchronization protection is provided for literals sent
      from the server to the client.  Nor is any necessary.  Any
      synchronization problems in this direction would be caused by a
      bug in the client or server.
































Crispin                                                        [Page 32]

Internet Draft                  IMAP2bis                 August 13, 1993


Sample IMAP2bis session

   The following is a transcript of an IMAP2bis session.  One very long
   long line in this sample is broken for editorial clarity.

   S:   * OK IMAP2bis Service 7.2(62) at Thu, 29 Jul 1993 21:34:23 -0700 (PDT)
   C:   a001 login mrc secret
   S:   a001 OK LOGIN completed
   C:   a002 select inbox
   S:   * 18 EXISTS
   S:   * FLAGS (\Answered \Flagged \Deleted \Seen)
   S:   * 0 RECENT
   S:   a002 OK [READ-WRITE] SELECT completed
   S:   a003 fetch 12 full
   S:   * 12 FETCH (FLAGS (\Seen) INTERNALDATE "14-Jul-1993 02:44:25 -0700"
         RFC822.SIZE 4282 ENVELOPE ("Wed, 14 Jul 1993 02:23:25 -0700 (PDT)"
         "IMAP2bis WG mtg summary and minutes" (("Terry Gray" NIL "gray"
         "cac.washington.edu")) ((NIL NIL "owner-imap" "cac.washington.edu"))
         (("Terry Gray" NIL "gray" "cac.washington.edu")) ((NIL NIL "imap"
         "cac.washington.edu")) ((NIL NIL "minutes" "CNRI.Reston.VA.US")
         ("John C Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")("Erik Huizer"
         NIL "Erik.Huizer" "SURFnet.nl")) NIL NIL
         "<Pine.3.84.9307140123.B27397-0100000@shiva2.cac.washington.edu>")
          BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))
   S:    a003 OK FETCH completed
   C:    a004 fetch 12 rfc822.header
   S:    * 12 FETCH (RFC822.HEADER {485}
   S:    Date: Wed, 14 Jul 1993 02:23:25 -0700 (PDT)
   S:    From: Terry Gray <gray@cac.washington.edu>
   S:    Reply-To: Terry Gray <gray@cac.washington.edu>
   S:    Subject: IMAP2bis WG mtg summary and minutes
   S:    To: imap@cac.washington.edu
   S:    Cc: minutes@CNRI.Reston.VA.US,
   S:            John C Klensin <KLENSIN@INFOODS.MIT.EDU>,
   S:            Erik Huizer <Erik.Huizer@SURFnet.nl>
   S:    Message-Id:
   S:     <Pine.3.84.9307140123.B27397-0100000@shiva2.cac.washington.edu>
   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 IMAP2bis server terminating connection
   S:    a006 OK LOGOUT completed



Crispin                                                        [Page 33]

Internet Draft                  IMAP2bis                 August 13, 1993


Design Discussion

   IMAP2bis is a textual protocol.  The use of MIME encoding in IMAP2bis
   makes it possible to support 8-bit textual and binary mail.

   IMAP2bis implementations MAY transmit 8-bit characters in literals,
   but should do so only when the character set is identified.  For
   example, 8-bit characters are specifically permitted in MIME body
   parts (fetching BODY[section]) of type TEXT.  8-bit characters are
   also permitted in the argument to APPEND.

   For compatibility with the 7-bit world, servers MUST NOT transmit 8-
   bit characters in RFC822.HEADER fetch results, and SHOULD NOT
   transmit 8-bit characters in RFC822.TEXT (and by extension RFC822)
   fetch results.

   Because 8-bit characters are permitted in the argument to APPEND, a
   server in the 7-bit world MUST, if it implements the APPEND command,
   be able to make a reversible conversion of the 8-bit APPEND data to
   7-bit data using MIME.

   Although a BINARY body encoding is defined, IMAP2bis does not permit
   unencoded binary strings.  A "binary string" is any string with NUL
   characters; a string with an excessive number of CTL characters may
   also be considered to be binary.  The mixing of unencoded binary in
   the same stream as textual commands would make the protocol more
   vulnerable to synchronization problems.  Implementations MUST encode
   binary data into BASE64 prior to transmitting it with IMAP2bis.

   When operating in the online model, an IMAP2bis client should
   maintain a local cache of data from the mailbox.  This cache is an
   incomplete model of the mailbox, and at startup is generally empty.
   As the client processes all unsolicited data, it updates the cache
   based on this data.  When a tagged response arrives, the client's
   cache has been updated from the associated request.

   Note that a server can send data that the client did not request,
   such as mailbox size or flag updates.  A server MUST send mailbox
   size updates automatically in the course of processing a command.  A
   server SHOULD send message flag updates automatically, without
   requiring the client to request such updates explicitly.

   Regardless of what implementation decisions a client may take on
   caching, a client MUST record EXISTS and RECENT updates and MUST NOT
   assume that a CHECK or NOOP command will return EXISTS or RECENT
   information.

   Although it is permitted for a server to send an unsolicited response



Crispin                                                        [Page 34]

Internet Draft                  IMAP2bis                 August 13, 1993


   while there is no command in progress, this practice SHOULD NOT be
   followed due to flow control considerations.  It can cause an
   incautious implementation to deadlock.  A deadlock is avoided if
   either of the following conditions are true: (1) with the exception
   of the greeting, the server never sends responses while there is no
   command in progress; (2) the client always reads responses from the
   IMAP2bis connection regardless of whether or not a command is in
   progress (or even if it is transmitting the command).  The latter
   condition generally requires a multi-threading client implementation,
   which may not always be feasible.

   If a server has an inactivity autologout timer, that timer MUST be of
   at least 30 minutes' duration.  The receipt of a NOOP command from
   the client during that interval should suffice to reset the
   autologout timer.  Periodic transmission of a NOOP from the client
   during periods of inactivity also has the benefit of avoiding the
   possible deadlock noted above, or even act as a poll for updates.

   It is frequently asked why there is no message posting capabilities
   in IMAP2bis.  Message posting is orthogonal to the scope of a mail
   access protocol and detracts from its primary focus.  SMTP (RFC 821)
   provides the minimal functionality needed for message posting without
   losing valuable capabilities (such as blind carbon copies).  Any
   message posting capability in IMAP2bis would need, at a minimum, to
   provide equivalent capabilities.

   At the time of the writing of this document, an extensive set of
   extensions to SMTP is in the Internet standards process.  Should
   those extensions become an Internet Standard it would be necessary to
   revise IMAP2bis again to provide corresponding capabilities, if a
   message posting facility was included in IMAP2bis.  In other words, a
   duplication of effort would be required each time a change is made to
   message transport technology.

   Another undesirable aspect of message posting in IMAP2bis occurs when
   a (very) remote server is used.  It is unlikely that a client will
   support multiple means of posting a message; it adds excessive size
   and complexity which can not be afforded, particularly on smaller
   machines.  Consider a client connecting to an IMAP2bis server over an
   interactive satellite link to a foreign country.  A local message
   posting (SMTP) server is available which uses a lower-cost batched
   link.  In this case, the use of the interactive link would be
   wasteful and costly.

   Message posting to IMAP2bis has been suggested as a means of
   authenticating postings.  The problem is that access authentication
   credentials are not necessarily the same as posting authentication
   credentials.  At some sites, the disclosure of a portion of access



Crispin                                                        [Page 35]

Internet Draft                  IMAP2bis                 August 13, 1993


   authentication credentials in a mail message (as a "From" or "Sender"
   address) may be a serious security breach of greater significance
   than forged mail.

   The Internet message transport infrastructure has no concept of
   authentication credentials, and neither authentication syntax nor
   semantics are transferred within a message.  As a result, any attempt
   at authenticating a message via posting authenticaton is completely
   ineffective once the message leaves the authenticating server; any
   indication of authentication in the message can easily be reproduced
   further down the line.  It is for this reason that public-key based
   message authentication systems such as Privacy Enhanced Mail are
   presently under development.

   IMAP2bis does not address problems with multiple IMAP2bis servers at
   a single site, access control lists, and mobility of client
   configuration and address book information.  These and other issues
   are being considered for a companion protocol (Interactive Mail
   Support Protocol) being developed at CMU.
































Crispin                                                        [Page 36]

Internet Draft                  IMAP2bis                 August 13, 1993


Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) notation as specified in RFC 822 with one exception; the
   delimiter used with the "#" construct is a single space (SPACE) and
   not a comma.

   Except as noted otherwise, all alphabetic characters in the IMAP2bis
   protocol are case-insensitive.  For example, "LOGIN", "login" and
   "lOgIn" are all valid as the login command.

   Syntax marked as obsolete may be encountered with implementations
   written for an older version of this specification.  New
   implementations SHOULD accept obsolete syntax as input, but MUST NOT
   otherwise use it.

   address         ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox
                       SPACE addr_host ")"

   addr_adl        ::= nil / string

   addr_host       ::= nil / string

   addr_mailbox    ::= nil / string

   addr_name       ::= nil / string

   append          ::= "APPEND" SPACE mailbox SPACE string

   astring         ::= atom / string

   atom            ::= 1*<any CHAR except specials, SPACE, and CTLs>

   bboard          ::= "BBOARD" SPACE mailbox_bboard

   body            ::= "(" body_structure ")"

   body_basic      ::= body_type SPACE body_subtype SPACE body_parameter
                       SPACE body_id SPACE body_description SPACE
                       body_encoding SPACE body_size_byte

   body_description::= nil / string

   body_encoding   ::= "7BIT" / "8BIT" / "BINARY" / "BASE64"/
                       "QUOTEDPRINTABLE" / atom

   body_id         ::= nil / string




Crispin                                                        [Page 37]

Internet Draft                  IMAP2bis                 August 13, 1993


   body_msg        ::= body_basic SPACE envelope SPACE body

   body_parameter  ::= nil / "(" 1#(string string) ")"

   body_section    ::= number / number "." body_section

   body_size_byte  ::= number

   body_size_line  ::= number

   body_structure  ::= body_basic / body_msg / body_text /
                       "(" body_structure ")" SPACE body_subtype

   body_subtype    ::= nil / string

   body_text       ::= body_basic SPACE body_size_line

   body_type       ::= "TEXT" / "MULTIPART" / "MESSAGE" / "APPLICATION" /
                       "AUDIO" / "IMAGE" / "VIDEO" / atom

   CHAR            ::= <any 7-bit US-ASCII character except NUL, 0x01 - 0x7f>

   CHAR8           ::= <any 8-bit octet except NUL, 0x01 - 0xff>

   check           ::= "CHECK"

   copy            ::= "COPY" SPACE sequence SPACE mailbox

   CR              ::= <ASCII CR, carriage return, 0x0C>

   create          ::= "CREATE" SPACE mailbox

   CRLF            ::= CR LF

   CTL             ::= <any ASCII control character and DEL, 0x00 - 0x1f, 0x7f>

   date            ::= date_new / date_old

   date_day        ::= 1*2DIGIT
                       ;; day of month

   date_month      ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
                       "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"

   date_new        ::= date_day "-" date_month "-" date_year

   date_old        ::= date_day "-" date_month "-" date_year_old
                       ;; Obsolete



Crispin                                                        [Page 38]

Internet Draft                  IMAP2bis                 August 13, 1993


   date_year       ::= 4DIGIT / date_year_old

   date_year_old   ::= 2DIGIT
                       ;; Obsolete, (year - 1900)

   date_time       ::= date_time_new / date_time_old

   date_time_new   ::= date_new SPACE time SPACE zone

   date_time_old   ::= date_old SPACE time "-" zone_old
                       ;; Obsolete

   delete          ::= "DELETE" SPACE mailbox_other

   DIGIT           ::= <any ASCII decimal digit, 0x30 - 0x39>

   DIGIT_HEX       :: DIGIT / "a" / "b" / "c" / "d" / "e" / "f"

   envelope        ::= "(" env_date SPACE env_subject SPACE env_from SPACE
                       env_sender SPACE env_reply-to SPACE env_to SPACE
                       env_cc SPACE env_bcc SPACE env_in-reply-to SPACE
                       env_message-id ")"

   env_bcc         ::= nil / "(" 1*address ")"

   env_cc          ::= nil / "(" 1*address ")"

   env_date        ::= string

   env_from        ::= nil / "(" 1*address ")"

   env_in-reply-to ::= nil / string

   env_message-id  ::= nil / string

   env_reply-to    ::= nil / "(" 1*address ")"

   env_sender      ::= nil / "(" 1*address ")"

   env_subject     ::= nil / string

   env_to          ::= nil / "(" 1*address ")"

   examine         ::= "EXAMINE" SPACE mailbox

   expunge         ::= "EXPUNGE"





Crispin                                                        [Page 39]

Internet Draft                  IMAP2bis                 August 13, 1993


   fetch           ::= "FETCH" SPACE sequence SPACE ("ALL" / "FULL" /
                       "FAST" / fetch_att / "(" 1#fetch_att ")")

   fetch_att       ::= fetch_att_other / fetch_att_text

   fetch_att_other ::= "BODY" / "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
                       "RFC822.SIZE" / "UID"

   fetch_att_text  ::= "BODY[" body_section "]" / "RFC822" /
                       "RFC822.HEADER" /
                       "RFC822.HEADER.LINES" SPACE header_line_list /
                       "RFC822.HEADER.LINES.NOT" SPACE header_line_list /
                       "RFC822.TEXT"

   find            ::= find_mailbox / find_bboard

   find_bboard     ::= find_bboards / find_boards_all

   find_bboards    ::= "FIND" SPACE "BBOARDS" SPACE find_pattern

   find_bboards_all
                   ::= "FIND" SPACE "ALL.BBOARDS" SPACE find_pattern

   find_mailbox    ::= find_mailboxes / find_mailboxes_all

   find_mailboxes  ::= "FIND" SPACE "MAILBOXES" SPACE find_pattern

   find_mailboxes_all
                   ::= "FIND" SPACE "ALL.MAILBOXES" SPACE find_pattern

   find_pattern    ::= astring
                       ;; includes find_wildcards

   find_wildcards  ::= "%" / "?" / "*"

   flag            ::= user_flag / system_flag

   flag_list       ::= "(" 1#flag ")"

   flags           ::= 1#flag / flag_list

   greeting        ::= "*" SPACE (human_data / "PREAUTH" SPACE response_text)

   header_line     ::= string

   header_line_list ::= "(" 1#header_line ")"





Crispin                                                        [Page 40]

Internet Draft                  IMAP2bis                 August 13, 1993


   human_data      ::= "OK" SPACE response_text / "NO" SPACE response_text /
                       "BAD" SPACE response_text / "BYE" SPACE resonse_text

   inbox           ::= "INBOX"
                       ;; case-independent, but SHOULD be upper-case

   istring         ::= astring
                       ;; possible RFC 1342 format data

   kerberos_authenticator
                   ::= 1*DIGIT_HEX

   kerberos_response
                   ::= 1*DIGIT_HEX

   LF              ::= <ASCII LF, line feed, 0x0A>

   literal         ::= "{" number "}" CRLF 1*CHAR8
                       ;; The number represents the number of CHAR8 octets.

   login           ::= "LOGIN" SPACE userid SPACE password

   logout          ::= "LOGOUT"

   mailbox         ::= inbox / mailbox_other

   mailbox_bboard  ::= astring
                       ;; May not be INBOX (in any case).  Should not
                       ;; include find_wildcards.  May be case-dependent
                       ;; as a function of server implementation.  May
                       ;; be a different namespace from mailbox_other.

   mailbox_other   ::= astring
                       ;; May not be INBOX (in any case).  Should not
                       ;; include find_wildcards.  May be case-dependent
                       ;; as a function of server implementation

   mailbox_data    ::= "MAILBOX" SPACE mstring / "BBOARD" SPACE mstring /
                        "SEARCH" SPACE 1#number / "FLAGS" SPACE flag_list

   message_data    ::= number SPACE (msg_exists / msg_recent / msg_expunge /
                       msg_fetch / msg_obsolete)

   msg_copy        ::= "COPY"
                       ;; Obsolete

   msg_exists      ::= "EXISTS"




Crispin                                                        [Page 41]

Internet Draft                  IMAP2bis                 August 13, 1993


   msg_expunge     ::= "EXPUNGE"

   msg_fetch       ::= "FETCH" SPACE "(" 1#("BODY" SPACE body /
                       "BODY[" body_section "]" string /
                       "ENVELOPE" SPACE envelope /
                       "FLAGS" SPACE "(" 1#(recent_flag / flag) ")" /
                       "INTERNALDATE" SPACE date_time /
                       "RFC822" SPACE string /
                       "RFC822.HEADER" SPACE string /
                       "RFC822.SIZE" SPACE number /
                       "RFC822.TEXT" SPACE string /
                       "UID" SPACE uniqueid) ")"

   msg_obsolete    ::= msg_copy / msg_store
                       ;; Obsolete unsolicited data responses

   msg_recent      ::= "RECENT"

   msg_store       ::= "STORE" SPACE "(" 1#("FLAGS" SPACE
                       "(" 1#(recent_flag / flag) "))"
                       ;; Obsolete

   mstring         ::= text_line
                       ;; Represents a mailbox

   nil             ::= "NIL"

   noop            ::= "NOOP"

   number          ::= 1*DIGIT

   partial         ::= "PARTIAL" SPACE number SPACE fetch_att_text SPACE
                       number SPACE number

   password        ::= astring / "@KERBEROS:" kerberos_authenticator

   QCHAR           ::= <any CHAR except qspecials, CR, and LF>

   qspecials       ::= <"> / "%" / "\"

   quoted_string   ::= <"> *QCHAR <">

   recent_flag     ::= "\RECENT"

   ready           ::= "+" SPACE response_text

   rename          ::= "RENAME" SPACE mailbox SPACE mailbox_other




Crispin                                                        [Page 42]

Internet Draft                  IMAP2bis                 August 13, 1993


   request         ::= tag SPACE (noop / login / logout / create /
                       delete / rename / find / subscribe / unsubscribe /
                       select / examine / bboard / check / expunge /
                       copy / append / fetch / partial / store / uid /
                       search / x_command ) CRLF

   response        ::= tag SPACE ("OK" / "NO" / "BAD") SPACE response_text CRLF

   response_code   ::= "PARSE" / "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
                       "X" atom / kerberos_response

   response_text   ::= ("[" response_code "]" text_line) / text_line

   search          ::= "SEARCH" SPACE 1#("ALL" / "ANSWERED" /
                       "BCC" SPACE istring / "BEFORE" SPACE day /
                       "BODY" SPACE istring / "CC" SPACE istring / "DELETED" /
                       "FLAGGED" / "KEYWORD" SPACE atom / "NEW" / "OLD" /
                       "ON" SPACE day / "RECENT" / "SEEN" /
                       "SINCE" SPACE day / "TEXT" SPACE istring /
                       "TO" SPACE istring / "UNANSWERED" / "UNDELETED" /
                       "UNFLAGGED" / "UNKEYWORD" / "UNSEEN")

   select          ::= "SELECT" SPACE mailbox

   sequence        ::= number / (sequence "," sequence) / (number ":" number)
                       ;; identifies a set of messages by consecutive numbers
                       ;; from 1 to the number of messages in the mailbox.
                       ;; Comma delimits individual numbers, colon delimits
                       ;; between two numbers inclusive.
                       ;; Example: 2,4:7,9,12:15 is 2,4,5,6,7,9,12,13,14,15

   SPACE           ::= <ASCII SP, space, 0x20>

   specials        ::= "{" / qspecials

   store           ::= "STORE" SPACE sequence SPACE store_att

   store_att       ::= "+FLAGS" SPACE flags / "-FLAGS" SPACE flags /
                       "FLAGS" SPACE flags

   string          ::= quoted_string / literal

   subscribe       ::= subscribe_mailbox / subscribe_bboard

   subscribe_bboard
                   ::= "SUBSCRIBE" SPACE "BBOARD" SPACE mailbox_bboard





Crispin                                                        [Page 43]

Internet Draft                  IMAP2bis                 August 13, 1993


   subscribe_mailbox
                   ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox

   system_flag     ::= "\ANSWERED" / "\FLAGGED" / "\DELETED" / "\SEEN"

   tag             ::= atom

   text_line       ::= 1*<any CHAR except CR and LF>

   time            ::= 2DIGIT ":" 2DIGIT ":" 2DIGIT
                       ;; hours minutes seconds

   uid             ::= "UID" SPACE (uid_after / uid_before / copy /
                       fetch / store)
                       ;; uniqueids used instead of message numbers

   uid_after       ::= "AFTER" SPACE uniqueid

   uid_before      ::= "BEFORE" SPACE uniqueid

   uniqueid        ::= number
                       ;;; strictly ascending

   unsolicited     ::= "*" SPACE (human_data / mailbox_data /
                       message_data) CRLF

   unsubscribe     ::= unsubscribe_mailbox / unsubscribe_bboard

   unsubscribe_bboard
                   ::= "UNSUBSCRIBE" SPACE "BBOARD" SPACE mailbox_bboard

   unsubscribe_mailbox
                   ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox_mailbox

   userid          ::= astring

   user_flag       ::= atom

   x_command       ::= "X" atom <optional arguments>
                       ;; experimental expansion commands

   zone            ::= ("+" / "-") 4DIGIT
                       ;; Signed four-digit value of hhmm representing
                       ;; hours and minutes west of Greenwich (that is,
                       ;; (the amount that the given time differs from
                       ;; Universal Time).  Subtracting the timezone
                       ;; from the given time will give the UT form.
                       ;; The Universal Time zone is "+0000".



Crispin                                                        [Page 44]

Internet Draft                  IMAP2bis                 August 13, 1993


   zone_old        ::= "UT" / "GMT" / "Z" /                ;; +0000
                       "AST" / "EST" / "CST" / "MST" /     ;; -0400 to -0700
                       "PST" / "YST" / "HST" / "BST" /     ;; -0800 to -1100
                       "ADT" / "EDT" / "CDT" / "MDT" /     ;; -0300 to -0600
                       "PDT" / "YDT" / "HDT" / "BDT" /     ;; -0700 to -1000
                       "A" / "B" / "C" / "D" / "E" / "F" / ;; +0100 to +0600
                       "G" / "H" / "I" / "K" / "L" / "M" / ;; +0700 to +1200
                       "N" / "O" / "P" / "Q" / "R" / "S" / ;; -0100 to -0600
                       "T" / "U" / "V" / "W" / "X" / "Y"   ;; -0700 to -1200
                       ;; Obsolete

   A protocol session is as follows:

    Server: greeting
    *<Client: request (first part, if it contains a literal)
      *<Server: ready
        Client: request (next part)
       >
      Server: *<unsolicited>
      Server: response
     >






























Crispin                                                        [Page 45]

Internet Draft                  IMAP2bis                 August 13, 1993


Acknowledgements

   Bill Yeager and Rich Acuff contributed invaluable suggestions in the
   evolution of IMAP2 from the original IMAP.  James Rice pointed out
   several ambiguities in the previous IMAP2 specification.

   My colleagues on the Pine team -- Steve Hubert, Laurence Lundblade,
   David Miller, and Mike Seibel -- worked long and hard to create a
   fantastic email user agent with worldwide popularity.  Without their
   efforts, IMAP2 would have languished in obscurity.  Terry Gray, our
   boss, provided much-needed moral support and guidance, while refusing
   to let us get away with "good enough" when "great" was possible.

   The present protocol would not have come into existance without the
   assistance of the IETF IMAP2 working group, and in particular Ned
   Freed, John Myers, Chris Newman, and Adam Treister.

   Any mistakes, flaws, or sins of omission in this IMAP2bis protocol
   specification are, however, strictly my own; and the mention of any
   name above does not imply an endorsement.

Security Considerations

   Security issues are discussed in this memo only as far as
   authentication for the purpose of accessing a server are concerned.

Author's Address

   Mark R. Crispin
   Networks and Distributed Computing, JE-30
   University of Washington
   Seattle, WA  98195

   Phone: (206) 543-5762

   EMail: MRC@CAC.Washington.EDU















Crispin                                                        [Page 46]