diff --git a/docs/rfcs/README.md b/docs/rfcs/README.md
new file mode 100644
index 0000000..70264ee
--- /dev/null
+++ b/docs/rfcs/README.md
@@ -0,0 +1,6 @@
+
+All RFCs related to IMAP.
+
+TODO:
+- rename the files to know what they are talking about.
+- Add a brief introduction here to introduce the most important RFCs.
diff --git a/docs/rfcs/rfc1731.txt b/docs/rfcs/rfc1731.txt
new file mode 100644
index 0000000..9cced5d
--- /dev/null
+++ b/docs/rfcs/rfc1731.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                           J. Myers
+Request for Comments: 1731                               Carnegie Mellon
+Category: Standards Track                                  December 1994
+
+
+                    IMAP4 Authentication Mechanisms
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+
+1. Introduction
+
+   The Internet Message Access Protocol, Version 4 [IMAP4] contains the
+   AUTHENTICATE command, for identifying and authenticating a user to an
+   IMAP4 server and for optionally negotiating a protection mechanism
+   for subsequent protocol interactions.  This document describes
+   several authentication mechanisms for use by the IMAP4 AUTHENTICATE
+   command.
+
+
+2. Kerberos version 4 authentication mechanism
+
+   The authentication type associated with Kerberos version 4 is
+   "KERBEROS_V4".
+
+   The data encoded in the first ready response contains a random 32-bit
+   number in network byte order.  The client should respond with a
+   Kerberos ticket and an authenticator for the principal
+   "imap.hostname@realm", where "hostname" is the first component of the
+   host name of the server with all letters in lower case and where
+   "realm" is the Kerberos realm of the server.  The encrypted checksum
+   field included within the Kerberos authenticator should contain the
+   server provided 32-bit number in network byte order.
+
+   Upon decrypting and verifying the ticket and authenticator, the
+   server should verify that the contained checksum field equals the
+   original server provided random 32-bit number.  Should the
+   verification be successful, the server must add one to the checksum
+   and construct 8 octets of data, with the first four octets containing
+   the incremented checksum in network byte order, the fifth octet
+   containing a bit-mask specifying the protection mechanisms supported
+   by the server, and the sixth through eighth octets containing, in
+
+
+
+Myers                                                           [Page 1]
+
+RFC 1731            IMAP4 Authentication Mechanisms        December 1994
+
+
+   network byte order, the maximum cipher-text buffer size the server is
+   able to receive.  The server must encrypt the 8 octets of data in the
+   session key and issue that encrypted data in a second ready response.
+   The client should consider the server authenticated if the first four
+   octets the un-encrypted data is equal to one plus the checksum it
+   previously sent.
+
+   The client must construct data with the first four octets containing
+   the original server-issued checksum in network byte order, the fifth
+   octet containing the bit-mask specifying the selected protection
+   mechanism, the sixth through eighth octets containing in network byte
+   order the maximum cipher-text buffer size the client is able to
+   receive, and the following octets containing a user name string.  The
+   client must then append from one to eight octets so that the length
+   of the data is a multiple of eight octets. The client must then PCBC
+   encrypt the data with the session key and respond to the second ready
+   response with the encrypted data.  The server decrypts the data and
+   verifies the contained checksum.  The username field identifies the
+   user for whom subsequent IMAP operations are to be performed; the
+   server must verify that the principal identified in the Kerberos
+   ticket is authorized to connect as that user.  After these
+   verifications, the authentication process is complete.
+
+   The protection mechanisms and their corresponding bit-masks are as
+   follows:
+
+      1 No protection mechanism
+      2 Integrity (krb_mk_safe) protection
+      4 Privacy (krb_mk_priv) protection
+
+
+   EXAMPLE: The following are two Kerberos version 4 login scenarios
+   (note that the line breaks in the sample authenticators are for
+   editorial clarity and are not in real authenticators)
+
+      S: * OK IMAP4 Server
+      C: A001 AUTHENTICATE KERBEROS_V4
+      S: + AmFYig==
+      C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+         +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
+         WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
+      S: + or//EoAADZI=
+      C: DiAF5A4gA+oOIALuBkAAmw==
+      S: A001 OK Kerberos V4 authentication successful
+
+
+
+
+
+
+
+Myers                                                           [Page 2]
+
+RFC 1731            IMAP4 Authentication Mechanisms        December 1994
+
+
+      S: * OK IMAP4 Server
+      C: A001 AUTHENTICATE KERBEROS_V4
+      S: + gcfgCA==
+      C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+         +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
+         WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
+      S: A001 NO Kerberos V4 authentication failed
+
+
+3. GSSAPI authentication mechanism
+
+   The authentication type associated with all mechanisms employing the
+   GSSAPI [RFC1508] is "GSSAPI".
+
+   The first ready response issued by the server contains no data.  The
+   client should call GSS_Init_sec_context, passing in 0 for
+   input_context_handle (initially) and a targ_name equal to output_name
+   from GSS_Import_Name called with input_name_type of NULL and
+   input_name_string of "SERVICE:imap@hostname" where "hostname" is the
+   fully qualified host name of the server with all letters in lower
+   case.  The client must then respond with the resulting output_token.
+   If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, then the client
+   should expect the server to issue a token in a subsequent ready
+   response.  The client must pass the token to another call to
+   GSS_Init_sec_context.
+
+   If GSS_Init_sec_context returns GSS_COMPLETE, then the client should
+   respond with any resulting output_token.  If there is no
+   output_token, the client should respond with no data.  The client
+   should then expect the server to issue a token in a subsequent ready
+   response.  The client should pass this token to GSS_Unseal and
+   interpret the first octet of resulting cleartext as a bit-mask
+   specifying the protection mechanisms supported by the server and the
+   second through fourth octets as the maximum size output_message to
+   send to the server.  The client should construct data, with the first
+   octet containing the bit-mask specifying the selected protection
+   mechanism, the second through fourth octets containing in network
+   byte order the maximum size output_message the client is able to
+   receive, and the remaining octets containing a user name string.  The
+   client must pass the data to GSS_Seal with conf_flag set to FALSE,
+   and respond with the generated output_message.  The client can then
+   consider the server authenticated.
+
+   The server must issue a ready response with no data and pass the
+   resulting client supplied token to GSS_Accept_sec_context as
+   input_token, setting acceptor_cred_handle to NULL (for "use default
+   credentials"), and 0 for input_context_handle (initially).  If
+   GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server should
+
+
+
+Myers                                                           [Page 3]
+
+RFC 1731            IMAP4 Authentication Mechanisms        December 1994
+
+
+   return the generated output_token to the client in a ready response
+   and pass the resulting client supplied token to another call to
+   GSS_Accept_sec_context.
+
+   If GSS_Accept_sec_context returns GSS_COMPLETE, then if an
+   output_token is returned, the server should return it to the client
+   in a ready response and expect a reply from the client with no data.
+   Whether or not an output_token was returned, the server then should
+   then construct 4 octets of data, with the first octet containing a
+   bit-mask specifying the protection mechanisms supported by the server
+   and the second through fourth octets containing in network byte order
+   the maximum size output_token the server is able to receive.  The
+   server must then pass the plaintext to GSS_Seal with conf_flag set to
+   FALSE and issue the generated output_message to the client in a ready
+   response.  The server must then pass the resulting client supplied
+   token to GSS_Unseal and interpret the first octet of resulting
+   cleartext as the bit-mask for the selected protection mechanism, the
+   second through fourth octets as the maximum size output_message to
+   send to the client, and the remaining octets as the user name.  Upon
+   verifying the src_name is authorized to authenticate as the user
+   name, The server should then consider the client authenticated.
+
+   The protection mechanisms and their corresponding bit-masks are as
+   follows:
+
+      1 No protection mechanism
+      2 Integrity protection.
+        Sender calls GSS_Seal with conf_flag set to FALSE
+      4 Privacy protection.
+        Sender calls GSS_Seal with conf_flag set to TRUE
+
+
+4. S/Key authentication mechanism
+
+   The authentication type associated with S/Key [SKEY] is "SKEY".
+
+   The first ready response issued by the server contains no data.  The
+   client responds with the user name string.
+
+   The data encoded in the second ready response contains the decimal
+   sequence number followed by a single space and the seed string for
+   the indicated user.  The client responds with the one-time-password,
+   as either a 64-bit value in network byte order or encoded in the "six
+   English words" format.
+
+   Upon successful verification of the one-time-password, the server
+   should consider the client authenticated.
+
+
+
+
+Myers                                                           [Page 4]
+
+RFC 1731            IMAP4 Authentication Mechanisms        December 1994
+
+
+   S/Key authentication does not provide for any protection mechanisms.
+
+
+   EXAMPLE: The following are two S/Key login scenarios.
+
+      S: * OK IMAP4 Server
+      C: A001 AUTHENTICATE SKEY
+      S: +
+      C: bW9yZ2Fu
+      S: + OTUgUWE1ODMwOA==
+      C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
+      S: A001 OK S/Key authentication successful
+
+
+      S: * OK IMAP4 Server
+      C: A001 AUTHENTICATE SKEY
+      S: +
+      C: c21pdGg=
+      S: + OTUgUWE1ODMwOA==
+      C: BsAY3g4gBNo=
+      S: A001 NO S/Key authentication failed
+
+
+5. References
+
+   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
+   RFC 1730, University of Washington, December 1994.
+
+   [RFC1508] Linn, J., "Generic Security Service Application Program
+   Interface", RFC 1508, Geer Zolot Associates, September 1993.
+
+   [SKEY] Haller, Neil M. "The S/Key One-Time Password System",
+   Bellcore, Morristown, New Jersey, October 1993,
+   thumper.bellcore.com:pub/nmh/docs/ISOC.symp.ps
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                                                           [Page 5]
+
+RFC 1731            IMAP4 Authentication Mechanisms        December 1994
+
+
+6. Security Considerations
+
+   Security issues are discussed throughout this memo.
+
+
+7. Author's Address
+
+   John G. Myers
+   Carnegie-Mellon University
+   5000 Forbes Ave.
+   Pittsburgh PA, 15213-3890
+
+   EMail: jgm+@cmu.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                                                           [Page 6]
+
diff --git a/docs/rfcs/rfc1732.txt b/docs/rfcs/rfc1732.txt
new file mode 100644
index 0000000..cfae89c
--- /dev/null
+++ b/docs/rfcs/rfc1732.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                         M. Crispin
+Request for Comments: 1732                      University of Washington
+Category: Informational                                    December 1994
+
+
+              IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS
+
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Introduction
+
+   This is a summary of hints and recommendations to enable an IMAP4
+   implementation to interoperate with implementations that conform to
+   earlier specifications.  None of these hints and recommendations are
+   required by the IMAP4 specification; implementors must decide for
+   themselves whether they want their implementation to fail if it
+   encounters old software.
+
+   IMAP4 has been designed to be upwards compatible with earlier
+   specifications.  For the most part, IMAP4 facilities that were not in
+   earlier specifications should be invisible to clients unless the
+   client asks for the facility.
+
+   In some cases, older servers may support some of the capabilities
+   listed as being "new in IMAP4" as experimental extensions to the
+   IMAP2 protocol described in RFC 1176.
+
+   This information may not be complete; it reflects current knowledge
+   of server and client implementations as well as "folklore" acquired
+   in the evolution of the protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                         [Page 1]
+
+RFC 1732                 IMAP4 - Compatibility             December 1994
+
+
+IMAP4 client interoperability with old servers
+
+   In general, a client should be able to discover whether an IMAP2
+   server supports a facility by trial-and-error; if an attempt to use a
+   facility generates a BAD response, the client can assume that the
+   server does not support the facility.
+
+   A quick way to check whether a server implementation supports the
+   IMAP4 specification is to try the CAPABILITY command.  An OK response
+   that includes the IMAP4 capability value indicates a server that
+   supports IMAP4; a BAD response or one without the IMAP4 capability
+   value indicates an older server.
+
+   The following is a list of facilities that are only in IMAP4, and
+   suggestions for how new clients might interoperate with old servers:
+
+   CAPABILITY command
+            A BAD response to this command indicates that the server
+            implements IMAP2 (or IMAP2bis) and not IMAP4.
+
+   AUTHENTICATE command.
+            Use the LOGIN command.
+
+   LSUB and LIST commands
+            Try the RFC 1176 FIND command.
+
+   * in a sequence
+            Use the number of messages in the mailbox from the EXISTS
+            unsolicited response.
+
+   SEARCH extensions (character set, additional criteria)
+            Reformulate the search request using only the searching
+            options listed in search_old in the IMAP4 grammar.  This may
+            entail doing multiple searches to achieve the desired
+            results.
+
+   BODYSTRUCTURE fetch data item
+            Try to fetch the non-extensible BODY data item.
+
+   body section number 0
+            Fetch the entire message and extract the header.
+
+   RFC822.HEADER.LINES and RFC822.HEADER.LINES.NOT fetch data items
+            Use RFC822.HEADER and remove the unwanted information.
+
+   BODY.PEEK[section], RFC822.PEEK, and RFC822.TEXT.PEEK fetch data
+            items Use the corresponding non-PEEK versions and manually
+            clear the \Seen flag as necessary.
+
+
+
+Crispin                                                         [Page 2]
+
+RFC 1732                 IMAP4 - Compatibility             December 1994
+
+
+   UID fetch data item and the UID commands
+            No equivalent capabilitity exists in older servers.
+
+   FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items
+            Use the corresponding non-SILENT versions and ignore the
+            untagged FETCH responses which com eback.
+
+
+   The following IMAP4 facilities were introduced in the experimental
+   IMAP2bis revisions to RFC-1176, and may be present in a server that
+   does not support the CAPABILITY command:
+
+   CREATE, DELETE, and RENAME commands
+            To test whether these commands are present, try a CREATE
+            INBOX command.  If the response is NO, these commands are
+            supported by the server.  If the response is BAD, they are
+            not.  Older servers without the CREATE capability may sup-
+            port implicit creation of a mailbox by a COPY command with a
+            non-existant name as the destination.
+
+   APPEND command
+            To test whether this command is present, try to append a
+            zero-length stream to a mailbox name that is known not to
+            exist (or at least, highly unlikely to exist) on the remote
+            system.
+
+   SUBSCRIBE and UNSUBSCRIBE commands
+            Try the form of these commands with the optional MAILBOX
+            keyword.
+
+   EXAMINE command
+            Use the SELECT command instead.
+
+   flags and internal date argument to APPEND command
+            Try the APPEND without any flag list and internal date argu-
+            ments.
+
+   BODY, BODY[section], and FULL fetch data items
+            Use RFC822.TEXT and ALL instead.  Server does not support
+            MIME.
+
+   PARTIAL command
+            Use the appropriate FETCH command and ignore the unwanted
+            data.
+
+
+   IMAP4 client implementations must accept all responses and data for-
+   mats documented in the IMAP4 specification, including those labeled
+
+
+
+Crispin                                                         [Page 3]
+
+RFC 1732                 IMAP4 - Compatibility             December 1994
+
+
+   as obsolete.  This includes the COPY and STORE unsolicited responses
+   and the old format of dates and times.  In particular, client imple-
+   mentations must not treat a date/time as a fixed format string; nor
+   may they assume that the time begins at a particular octet.
+
+   IMAP4 client implementations must not depend upon the presence of any
+   server extensions that are not in the base IMAP4 specification.
+
+   The experimental IMAP2bis version specified that the TRYCREATE spe-
+   cial information token is sent as a separate unsolicited OK response
+   instead of inside the NO response.
+
+   The FIND BBOARDS, FIND ALL.BBOARDS, and BBOARD commands of RFC 1176
+   are removed from IMAP4.  There is no equivalent to the bboard com-
+   mands, which provided a separate namespace with implicit restrictions
+   on what may be done in that namespace.
+
+   Older server implementations may automatically create the destination
+   mailbox on COPY if that mailbox does not already exist.  This was how
+   a new mailbox was created in older specifications.  If the server
+   does not support the CREATE command (see above for how to test for
+   this), it will probably create a mailbox on COPY.
+
+   Older server implementations may not preserve flags or internal dates
+   on COPY.  Some server implementations may not permit the preservation
+   of certain flags on COPY or their setting with APPEND as site policy.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                         [Page 4]
+
+RFC 1732                 IMAP4 - Compatibility             December 1994
+
+
+IMAP4 server interoperability with old clients
+
+   In general, there should be no interoperation problem between a
+   server conforming to the IMAP4 specification and a well-written
+   client that conforms to an earlier specification.  Known problems are
+   noted below:
+
+      Poor wording in the description of the CHECK command in earlier
+      specifications implied that a CHECK command is the way to get the
+      current number of messages in the mailbox.  This is incorrect.  A
+      CHECK command does not necessarily result in an EXISTS response.
+      Clients must remember the most recent EXISTS value sent from the
+      server, and should not generate unnecessary CHECK commands.
+
+      An incompatibility exists with COPY in IMAP4.  COPY in IMAP4
+      servers does not automatically create the destination mailbox if
+      that mailbox does not already exist.  This may cause problems with
+      old clients that expect automatic mailbox creation in COPY.
+
+      The PREAUTH unsolicited response is new in IMAP4.  It is highly
+      unlikely that an old client would ever see this response.
+
+      The format of dates and times has changed due to the impending end
+      of the century.  Clients that fail to accept a four-digit year or
+      a signed four-digit timezone value will not work properly with
+      IMAP4.
+
+      An incompatibility exists with the use of "\" in quoted strings.
+      This is best avoided by using literals instead of quoted strings
+      if "\" or <"> is embedded in the string.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+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 5]
+
diff --git a/docs/rfcs/rfc1733.txt b/docs/rfcs/rfc1733.txt
new file mode 100644
index 0000000..2ec385f
--- /dev/null
+++ b/docs/rfcs/rfc1733.txt
@@ -0,0 +1,171 @@
+
+
+
+
+
+
+Network Working Group                                         M. Crispin
+Request for Comments: 1733                      University of Washington
+Category: Informational                                    December 1994
+
+
+              DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4
+
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+
+Distributed Electronic Mail Models
+
+   There are three fundamental models of client/server email: offline,
+   online, and disconnected use.  IMAP4 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 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 session.  No mailbox data are
+   kept on the client; the client retrieves data from the server as is
+   needed.  IMAP4 introduces a form of the online model that 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.
+
+
+
+Crispin                                                         [Page 1]
+
+RFC 1733                     IMAP4 - Model                 December 1994
+
+
+   Each of these models have their own strengths and weaknesses:
+
+      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 IMAP4 has its origins as a protocol designed to accommodate
+   the online model, it can support the other two models as well.  This
+   makes possible the creation of clients that 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. owing to
+   travel).
+
+   IMAP4 is designed to transmit message data on demand, and to provide
+   the facilities necessary for a client to decide 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, IMAP4 supports server-based RFC 822 and MIME
+   processing.  With this information, it is possible for a client to
+   determine in advance whether it wishes to retrieve a particular
+   message or part of a message.  For example, a user connected to an
+   IMAP4 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 IMAP4, the client/server relationship lasts only for the duration
+   of the TCP connection.  There is no registration of clients.  Except
+   for any unique identifiers used in disconnected use operation, the
+   client initially has no knowledge of mailbox state and learns it from
+   the IMAP4 server when a mailbox is selected.  This initial transfer
+   is minimal; the client requests additional state data as it needs.
+
+   As noted above, the choice for the location of mailbox data depends
+   upon the model chosen.  The location of message state (e.g. whether
+   or not a message has been read or answered) is also determined by the
+   model, and is not necessarily the same as the location of the mailbox
+   data.  For example, in the online model message state can be co-
+   located with mailbox data; it can also be located elsewhere (on the
+   client or on a third agent) using unique identifiers to achieve
+
+
+
+Crispin                                                         [Page 2]
+
+RFC 1733                     IMAP4 - Model                 December 1994
+
+
+   common reference across sessions.  The latter is particularly useful
+   with a server that exports public data such as netnews and does not
+   maintain per-user state.
+
+   The IMAP4 protocol provides the generality to implement these
+   different models.  This is done by means of server and (especially)
+   client configuration, and not by requiring changes to the protocol or
+   the implementation of the protocol.
+
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+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 3]
+
diff --git a/docs/rfcs/rfc1939.txt b/docs/rfcs/rfc1939.txt
new file mode 100644
index 0000000..b11350e
--- /dev/null
+++ b/docs/rfcs/rfc1939.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group                                           J. Myers
+Request for Comments: 1939                               Carnegie Mellon
+STD: 53                                                          M. Rose
+Obsoletes: 1725                             Dover Beach Consulting, Inc.
+Category: Standards Track                                       May 1996
+
+
+                    Post Office Protocol - Version 3
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Table of Contents
+
+   1. Introduction ................................................    2
+   2. A Short Digression ..........................................    2
+   3. Basic Operation .............................................    3
+   4. The AUTHORIZATION State .....................................    4
+      QUIT Command ................................................    5
+   5. The TRANSACTION State .......................................    5
+      STAT Command ................................................    6
+      LIST Command ................................................    6
+      RETR Command ................................................    8
+      DELE Command ................................................    8
+      NOOP Command ................................................    9
+      RSET Command ................................................    9
+   6. The UPDATE State ............................................   10
+      QUIT Command ................................................   10
+   7. Optional POP3 Commands ......................................   11
+      TOP Command .................................................   11
+      UIDL Command ................................................   12
+      USER Command ................................................   13
+      PASS Command ................................................   14
+      APOP Command ................................................   15
+   8. Scaling and Operational Considerations ......................   16
+   9. POP3 Command Summary ........................................   18
+   10. Example POP3 Session .......................................   19
+   11. Message Format .............................................   19
+   12. References .................................................   20
+   13. Security Considerations ....................................   20
+   14. Acknowledgements ...........................................   20
+   15. Authors' Addresses .........................................   21
+   Appendix A. Differences from RFC 1725 ..........................   22
+
+
+
+Myers & Rose                Standards Track                     [Page 1]
+
+RFC 1939                          POP3                          May 1996
+
+
+   Appendix B. Command Index ......................................   23
+
+1. Introduction
+
+   On certain types of smaller nodes in the Internet it is often
+   impractical to maintain a message transport system (MTS).  For
+   example, a workstation may not have sufficient resources (cycles,
+   disk space) in order to permit a SMTP server [RFC821] and associated
+   local mail delivery system to be kept resident and continuously
+   running.  Similarly, it may be expensive (or impossible) to keep a
+   personal computer interconnected to an IP-style network for long
+   amounts of time (the node is lacking the resource known as
+   "connectivity").
+
+   Despite this, it is often very useful to be able to manage mail on
+   these smaller nodes, and they often support a user agent (UA) to aid
+   the tasks of mail handling.  To solve this problem, a node which can
+   support an MTS entity offers a maildrop service to these less endowed
+   nodes.  The Post Office Protocol - Version 3 (POP3) is intended to
+   permit a workstation to dynamically access a maildrop on a server
+   host in a useful fashion.  Usually, this means that the POP3 protocol
+   is used to allow a workstation to retrieve mail that the server is
+   holding for it.
+
+   POP3 is not intended to provide extensive manipulation operations of
+   mail on the server; normally, mail is downloaded and then deleted.  A
+   more advanced (and complex) protocol, IMAP4, is discussed in
+   [RFC1730].
+
+   For the remainder of this memo, the term "client host" refers to a
+   host making use of the POP3 service, while the term "server host"
+   refers to a host which offers the POP3 service.
+
+2. A Short Digression
+
+   This memo does not specify how a client host enters mail into the
+   transport system, although a method consistent with the philosophy of
+   this memo is presented here:
+
+      When the user agent on a client host wishes to enter a message
+      into the transport system, it establishes an SMTP connection to
+      its relay host and sends all mail to it.  This relay host could
+      be, but need not be, the POP3 server host for the client host.  Of
+      course, the relay host must accept mail for delivery to arbitrary
+      recipient addresses, that functionality is not required of all
+      SMTP servers.
+
+
+
+
+
+Myers & Rose                Standards Track                     [Page 2]
+
+RFC 1939                          POP3                          May 1996
+
+
+3. Basic Operation
+
+   Initially, the server host starts the POP3 service by listening on
+   TCP port 110.  When a client host wishes to make use of the service,
+   it establishes a TCP connection with the server host.  When the
+   connection is established, the POP3 server sends a greeting.  The
+   client and POP3 server then exchange commands and responses
+   (respectively) until the connection is closed or aborted.
+
+   Commands in the POP3 consist of a case-insensitive keyword, possibly
+   followed by one or more arguments.  All commands are terminated by a
+   CRLF pair.  Keywords and arguments consist of printable ASCII
+   characters.  Keywords and arguments are each separated by a single
+   SPACE character.  Keywords are three or four characters long. Each
+   argument may be up to 40 characters long.
+
+   Responses in the POP3 consist of a status indicator and a keyword
+   possibly followed by additional information.  All responses are
+   terminated by a CRLF pair.  Responses may be up to 512 characters
+   long, including the terminating CRLF.  There are currently two status
+   indicators: positive ("+OK") and negative ("-ERR").  Servers MUST
+   send the "+OK" and "-ERR" in upper case.
+
+   Responses to certain commands are multi-line.  In these cases, which
+   are clearly indicated below, after sending the first line of the
+   response and a CRLF, any additional lines are sent, each terminated
+   by a CRLF pair.  When all lines of the response have been sent, a
+   final line is sent, consisting of a termination octet (decimal code
+   046, ".") and a CRLF pair.  If any line of the multi-line response
+   begins with the termination octet, the line is "byte-stuffed" by
+   pre-pending the termination octet to that line of the response.
+   Hence a multi-line response is terminated with the five octets
+   "CRLF.CRLF".  When examining a multi-line response, the client checks
+   to see if the line begins with the termination octet.  If so and if
+   octets other than CRLF follow, the first octet of the line (the
+   termination octet) is stripped away.  If so and if CRLF immediately
+   follows the termination character, then the response from the POP
+   server is ended and the line containing ".CRLF" is not considered
+   part of the multi-line response.
+
+   A POP3 session progresses through a number of states during its
+   lifetime.  Once the TCP connection has been opened and the POP3
+   server has sent the greeting, the session enters the AUTHORIZATION
+   state.  In this state, the client must identify itself to the POP3
+   server.  Once the client has successfully done this, the server
+   acquires resources associated with the client's maildrop, and the
+   session enters the TRANSACTION state.  In this state, the client
+   requests actions on the part of the POP3 server.  When the client has
+
+
+
+Myers & Rose                Standards Track                     [Page 3]
+
+RFC 1939                          POP3                          May 1996
+
+
+   issued the QUIT command, the session enters the UPDATE state.  In
+   this state, the POP3 server releases any resources acquired during
+   the TRANSACTION state and says goodbye.  The TCP connection is then
+   closed.
+
+   A server MUST respond to an unrecognized, unimplemented, or
+   syntactically invalid command by responding with a negative status
+   indicator.  A server MUST respond to a command issued when the
+   session is in an incorrect state by responding with a negative status
+   indicator.  There is no general method for a client to distinguish
+   between a server which does not implement an optional command and a
+   server which is unwilling or unable to process the command.
+
+   A POP3 server MAY have an inactivity autologout timer.  Such a timer
+   MUST be of at least 10 minutes' duration.  The receipt of any command
+   from the client during that interval should suffice to reset the
+   autologout timer.  When the timer expires, the session does NOT enter
+   the UPDATE state--the server should close the TCP connection without
+   removing any messages or sending any response to the client.
+
+4. The AUTHORIZATION State
+
+   Once the TCP connection has been opened by a POP3 client, the POP3
+   server issues a one line greeting.  This can be any positive
+   response.  An example might be:
+
+      S:  +OK POP3 server ready
+
+   The POP3 session is now in the AUTHORIZATION state.  The client must
+   now identify and authenticate itself to the POP3 server.  Two
+   possible mechanisms for doing this are described in this document,
+   the USER and PASS command combination and the APOP command.  Both
+   mechanisms are described later in this document.  Additional
+   authentication mechanisms are described in [RFC1734].  While there is
+   no single authentication mechanism that is required of all POP3
+   servers, a POP3 server must of course support at least one
+   authentication mechanism.
+
+   Once the POP3 server has determined through the use of any
+   authentication command that the client should be given access to the
+   appropriate maildrop, the POP3 server then acquires an exclusive-
+   access lock on the maildrop, as necessary to prevent messages from
+   being modified or removed before the session enters the UPDATE state.
+   If the lock is successfully acquired, the POP3 server responds with a
+   positive status indicator.  The POP3 session now enters the
+   TRANSACTION state, with no messages marked as deleted.  If the
+   maildrop cannot be opened for some reason (for example, a lock can
+   not be acquired, the client is denied access to the appropriate
+
+
+
+Myers & Rose                Standards Track                     [Page 4]
+
+RFC 1939                          POP3                          May 1996
+
+
+   maildrop, or the maildrop cannot be parsed), the POP3 server responds
+   with a negative status indicator.  (If a lock was acquired but the
+   POP3 server intends to respond with a negative status indicator, the
+   POP3 server must release the lock prior to rejecting the command.)
+   After returning a negative status indicator, the server may close the
+   connection.  If the server does not close the connection, the client
+   may either issue a new authentication command and start again, or the
+   client may issue the QUIT command.
+
+   After the POP3 server has opened the maildrop, it assigns a message-
+   number to each message, and notes the size of each message in octets.
+   The first message in the maildrop is assigned a message-number of
+   "1", the second is assigned "2", and so on, so that the nth message
+   in a maildrop is assigned a message-number of "n".  In POP3 commands
+   and responses, all message-numbers and message sizes are expressed in
+   base-10 (i.e., decimal).
+
+   Here is the summary for the QUIT command when used in the
+   AUTHORIZATION state:
+
+      QUIT
+
+         Arguments: none
+
+         Restrictions: none
+
+         Possible Responses:
+             +OK
+
+         Examples:
+             C: QUIT
+             S: +OK dewey POP3 server signing off
+
+5. The TRANSACTION State
+
+   Once the client has successfully identified itself to the POP3 server
+   and the POP3 server has locked and opened the appropriate maildrop,
+   the POP3 session is now in the TRANSACTION state.  The client may now
+   issue any of the following POP3 commands repeatedly.  After each
+   command, the POP3 server issues a response.  Eventually, the client
+   issues the QUIT command and the POP3 session enters the UPDATE state.
+
+
+
+
+
+
+
+
+
+
+Myers & Rose                Standards Track                     [Page 5]
+
+RFC 1939                          POP3                          May 1996
+
+
+   Here are the POP3 commands valid in the TRANSACTION state:
+
+      STAT
+
+         Arguments: none
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             The POP3 server issues a positive response with a line
+             containing information for the maildrop.  This line is
+             called a "drop listing" for that maildrop.
+
+             In order to simplify parsing, all POP3 servers are
+             required to use a certain format for drop listings.  The
+             positive response consists of "+OK" followed by a single
+             space, the number of messages in the maildrop, a single
+             space, and the size of the maildrop in octets.  This memo
+             makes no requirement on what follows the maildrop size.
+             Minimal implementations should just end that line of the
+             response with a CRLF pair.  More advanced implementations
+             may include other information.
+
+                NOTE: This memo STRONGLY discourages implementations
+                from supplying additional information in the drop
+                listing.  Other, optional, facilities are discussed
+                later on which permit the client to parse the messages
+                in the maildrop.
+
+             Note that messages marked as deleted are not counted in
+             either total.
+
+         Possible Responses:
+             +OK nn mm
+
+         Examples:
+             C: STAT
+             S: +OK 2 320
+
+
+      LIST [msg]
+
+         Arguments:
+             a message-number (optional), which, if present, may NOT
+             refer to a message marked as deleted
+
+
+
+
+
+Myers & Rose                Standards Track                     [Page 6]
+
+RFC 1939                          POP3                          May 1996
+
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             If an argument was given and the POP3 server issues a
+             positive response with a line containing information for
+             that message.  This line is called a "scan listing" for
+             that message.
+
+             If no argument was given and the POP3 server issues a
+             positive response, then the response given is multi-line.
+             After the initial +OK, for each message in the maildrop,
+             the POP3 server responds with a line containing
+             information for that message.  This line is also called a
+             "scan listing" for that message.  If there are no
+             messages in the maildrop, then the POP3 server responds
+             with no scan listings--it issues a positive response
+             followed by a line containing a termination octet and a
+             CRLF pair.
+
+             In order to simplify parsing, all POP3 servers are
+             required to use a certain format for scan listings.  A
+             scan listing consists of the message-number of the
+             message, followed by a single space and the exact size of
+             the message in octets.  Methods for calculating the exact
+             size of the message are described in the "Message Format"
+             section below.  This memo makes no requirement on what
+             follows the message size in the scan listing.  Minimal
+             implementations should just end that line of the response
+             with a CRLF pair.  More advanced implementations may
+             include other information, as parsed from the message.
+
+                NOTE: This memo STRONGLY discourages implementations
+                from supplying additional information in the scan
+                listing.  Other, optional, facilities are discussed
+                later on which permit the client to parse the messages
+                in the maildrop.
+
+             Note that messages marked as deleted are not listed.
+
+         Possible Responses:
+             +OK scan listing follows
+             -ERR no such message
+
+         Examples:
+             C: LIST
+             S: +OK 2 messages (320 octets)
+             S: 1 120
+
+
+
+Myers & Rose                Standards Track                     [Page 7]
+
+RFC 1939                          POP3                          May 1996
+
+
+             S: 2 200
+             S: .
+               ...
+             C: LIST 2
+             S: +OK 2 200
+               ...
+             C: LIST 3
+             S: -ERR no such message, only 2 messages in maildrop
+
+
+      RETR msg
+
+         Arguments:
+             a message-number (required) which may NOT refer to a
+             message marked as deleted
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             If the POP3 server issues a positive response, then the
+             response given is multi-line.  After the initial +OK, the
+             POP3 server sends the message corresponding to the given
+             message-number, being careful to byte-stuff the termination
+             character (as with all multi-line responses).
+
+         Possible Responses:
+             +OK message follows
+             -ERR no such message
+
+         Examples:
+             C: RETR 1
+             S: +OK 120 octets
+             S: <the POP3 server sends the entire message here>
+             S: .
+
+
+      DELE msg
+
+         Arguments:
+             a message-number (required) which may NOT refer to a
+             message marked as deleted
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+
+
+
+
+
+Myers & Rose                Standards Track                     [Page 8]
+
+RFC 1939                          POP3                          May 1996
+
+
+         Discussion:
+             The POP3 server marks the message as deleted.  Any future
+             reference to the message-number associated with the message
+             in a POP3 command generates an error.  The POP3 server does
+             not actually delete the message until the POP3 session
+             enters the UPDATE state.
+
+         Possible Responses:
+             +OK message deleted
+             -ERR no such message
+
+         Examples:
+             C: DELE 1
+             S: +OK message 1 deleted
+                ...
+             C: DELE 2
+             S: -ERR message 2 already deleted
+
+
+      NOOP
+
+         Arguments: none
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             The POP3 server does nothing, it merely replies with a
+             positive response.
+
+         Possible Responses:
+             +OK
+
+         Examples:
+             C: NOOP
+             S: +OK
+
+
+      RSET
+
+         Arguments: none
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             If any messages have been marked as deleted by the POP3
+             server, they are unmarked.  The POP3 server then replies
+
+
+
+Myers & Rose                Standards Track                     [Page 9]
+
+RFC 1939                          POP3                          May 1996
+
+
+             with a positive response.
+
+         Possible Responses:
+             +OK
+
+         Examples:
+             C: RSET
+             S: +OK maildrop has 2 messages (320 octets)
+
+6. The UPDATE State
+
+   When the client issues the QUIT command from the TRANSACTION state,
+   the POP3 session enters the UPDATE state.  (Note that if the client
+   issues the QUIT command from the AUTHORIZATION state, the POP3
+   session terminates but does NOT enter the UPDATE state.)
+
+   If a session terminates for some reason other than a client-issued
+   QUIT command, the POP3 session does NOT enter the UPDATE state and
+   MUST not remove any messages from the maildrop.
+
+      QUIT
+
+         Arguments: none
+
+         Restrictions: none
+
+         Discussion:
+             The POP3 server removes all messages marked as deleted
+             from the maildrop and replies as to the status of this
+             operation.  If there is an error, such as a resource
+             shortage, encountered while removing messages, the
+             maildrop may result in having some or none of the messages
+             marked as deleted be removed.  In no case may the server
+             remove any messages not marked as deleted.
+
+             Whether the removal was successful or not, the server
+             then releases any exclusive-access lock on the maildrop
+             and closes the TCP connection.
+
+         Possible Responses:
+             +OK
+             -ERR some deleted messages not removed
+
+         Examples:
+             C: QUIT
+             S: +OK dewey POP3 server signing off (maildrop empty)
+                ...
+             C: QUIT
+
+
+
+Myers & Rose                Standards Track                    [Page 10]
+
+RFC 1939                          POP3                          May 1996
+
+
+             S: +OK dewey POP3 server signing off (2 messages left)
+                ...
+
+7. Optional POP3 Commands
+
+   The POP3 commands discussed above must be supported by all minimal
+   implementations of POP3 servers.
+
+   The optional POP3 commands described below permit a POP3 client
+   greater freedom in message handling, while preserving a simple POP3
+   server implementation.
+
+      NOTE: This memo STRONGLY encourages implementations to support
+      these commands in lieu of developing augmented drop and scan
+      listings.  In short, the philosophy of this memo is to put
+      intelligence in the part of the POP3 client and not the POP3
+      server.
+
+      TOP msg n
+
+         Arguments:
+             a message-number (required) which may NOT refer to to a
+             message marked as deleted, and a non-negative number
+             of lines (required)
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             If the POP3 server issues a positive response, then the
+             response given is multi-line.  After the initial +OK, the
+             POP3 server sends the headers of the message, the blank
+             line separating the headers from the body, and then the
+             number of lines of the indicated message's body, being
+             careful to byte-stuff the termination character (as with
+             all multi-line responses).
+
+             Note that if the number of lines requested by the POP3
+             client is greater than than the number of lines in the
+             body, then the POP3 server sends the entire message.
+
+         Possible Responses:
+             +OK top of message follows
+             -ERR no such message
+
+         Examples:
+             C: TOP 1 10
+             S: +OK
+
+
+
+Myers & Rose                Standards Track                    [Page 11]
+
+RFC 1939                          POP3                          May 1996
+
+
+             S: <the POP3 server sends the headers of the
+                message, a blank line, and the first 10 lines
+                of the body of the message>
+             S: .
+                ...
+             C: TOP 100 3
+             S: -ERR no such message
+
+
+      UIDL [msg]
+
+      Arguments:
+          a message-number (optional), which, if present, may NOT
+          refer to a message marked as deleted
+
+      Restrictions:
+          may only be given in the TRANSACTION state.
+
+      Discussion:
+          If an argument was given and the POP3 server issues a positive
+          response with a line containing information for that message.
+          This line is called a "unique-id listing" for that message.
+
+          If no argument was given and the POP3 server issues a positive
+          response, then the response given is multi-line.  After the
+          initial +OK, for each message in the maildrop, the POP3 server
+          responds with a line containing information for that message.
+          This line is called a "unique-id listing" for that message.
+
+          In order to simplify parsing, all POP3 servers are required to
+          use a certain format for unique-id listings.  A unique-id
+          listing consists of the message-number of the message,
+          followed by a single space and the unique-id of the message.
+          No information follows the unique-id in the unique-id listing.
+
+          The unique-id of a message is an arbitrary server-determined
+          string, consisting of one to 70 characters in the range 0x21
+          to 0x7E, which uniquely identifies a message within a
+          maildrop and which persists across sessions.  This
+          persistence is required even if a session ends without
+          entering the UPDATE state.  The server should never reuse an
+          unique-id in a given maildrop, for as long as the entity
+          using the unique-id exists.
+
+          Note that messages marked as deleted are not listed.
+
+          While it is generally preferable for server implementations
+          to store arbitrarily assigned unique-ids in the maildrop,
+
+
+
+Myers & Rose                Standards Track                    [Page 12]
+
+RFC 1939                          POP3                          May 1996
+
+
+          this specification is intended to permit unique-ids to be
+          calculated as a hash of the message.  Clients should be able
+          to handle a situation where two identical copies of a
+          message in a maildrop have the same unique-id.
+
+      Possible Responses:
+          +OK unique-id listing follows
+          -ERR no such message
+
+      Examples:
+          C: UIDL
+          S: +OK
+          S: 1 whqtswO00WBw418f9t5JxYwZ
+          S: 2 QhdPYR:00WBw1Ph7x7
+          S: .
+             ...
+          C: UIDL 2
+          S: +OK 2 QhdPYR:00WBw1Ph7x7
+             ...
+          C: UIDL 3
+          S: -ERR no such message, only 2 messages in maildrop
+
+
+      USER name
+
+         Arguments:
+             a string identifying a mailbox (required), which is of
+             significance ONLY to the server
+
+         Restrictions:
+             may only be given in the AUTHORIZATION state after the POP3
+             greeting or after an unsuccessful USER or PASS command
+
+         Discussion:
+             To authenticate using the USER and PASS command
+             combination, the client must first issue the USER
+             command.  If the POP3 server responds with a positive
+             status indicator ("+OK"), then the client may issue
+             either the PASS command to complete the authentication,
+             or the QUIT command to terminate the POP3 session.  If
+             the POP3 server responds with a negative status indicator
+             ("-ERR") to the USER command, then the client may either
+             issue a new authentication command or may issue the QUIT
+             command.
+
+             The server may return a positive response even though no
+             such mailbox exists.  The server may return a negative
+             response if mailbox exists, but does not permit plaintext
+
+
+
+Myers & Rose                Standards Track                    [Page 13]
+
+RFC 1939                          POP3                          May 1996
+
+
+             password authentication.
+
+         Possible Responses:
+             +OK name is a valid mailbox
+             -ERR never heard of mailbox name
+
+         Examples:
+             C: USER frated
+             S: -ERR sorry, no mailbox for frated here
+                ...
+             C: USER mrose
+             S: +OK mrose is a real hoopy frood
+
+
+      PASS string
+
+         Arguments:
+             a server/mailbox-specific password (required)
+
+         Restrictions:
+             may only be given in the AUTHORIZATION state immediately
+             after a successful USER command
+
+         Discussion:
+             When the client issues the PASS command, the POP3 server
+             uses the argument pair from the USER and PASS commands to
+             determine if the client should be given access to the
+             appropriate maildrop.
+
+             Since the PASS command has exactly one argument, a POP3
+             server may treat spaces in the argument as part of the
+             password, instead of as argument separators.
+
+         Possible Responses:
+             +OK maildrop locked and ready
+             -ERR invalid password
+             -ERR unable to lock maildrop
+
+         Examples:
+             C: USER mrose
+             S: +OK mrose is a real hoopy frood
+             C: PASS secret
+             S: -ERR maildrop already locked
+               ...
+             C: USER mrose
+             S: +OK mrose is a real hoopy frood
+             C: PASS secret
+             S: +OK mrose's maildrop has 2 messages (320 octets)
+
+
+
+Myers & Rose                Standards Track                    [Page 14]
+
+RFC 1939                          POP3                          May 1996
+
+
+      APOP name digest
+
+         Arguments:
+             a string identifying a mailbox and a MD5 digest string
+             (both required)
+
+         Restrictions:
+             may only be given in the AUTHORIZATION state after the POP3
+             greeting or after an unsuccessful USER or PASS command
+
+         Discussion:
+             Normally, each POP3 session starts with a USER/PASS
+             exchange.  This results in a server/user-id specific
+             password being sent in the clear on the network.  For
+             intermittent use of POP3, this may not introduce a sizable
+             risk.  However, many POP3 client implementations connect to
+             the POP3 server on a regular basis -- to check for new
+             mail.  Further the interval of session initiation may be on
+             the order of five minutes.  Hence, the risk of password
+             capture is greatly enhanced.
+
+             An alternate method of authentication is required which
+             provides for both origin authentication and replay
+             protection, but which does not involve sending a password
+             in the clear over the network.  The APOP command provides
+             this functionality.
+
+             A POP3 server which implements the APOP command will
+             include a timestamp in its banner greeting.  The syntax of
+             the timestamp corresponds to the `msg-id' in [RFC822], and
+             MUST be different each time the POP3 server issues a banner
+             greeting.  For example, on a UNIX implementation in which a
+             separate UNIX process is used for each instance of a POP3
+             server, the syntax of the timestamp might be:
+
+                <process-ID.clock@hostname>
+
+             where `process-ID' is the decimal value of the process's
+             PID, clock is the decimal value of the system clock, and
+             hostname is the fully-qualified domain-name corresponding
+             to the host where the POP3 server is running.
+
+             The POP3 client makes note of this timestamp, and then
+             issues the APOP command.  The `name' parameter has
+             identical semantics to the `name' parameter of the USER
+             command. The `digest' parameter is calculated by applying
+             the MD5 algorithm [RFC1321] to a string consisting of the
+             timestamp (including angle-brackets) followed by a shared
+
+
+
+Myers & Rose                Standards Track                    [Page 15]
+
+RFC 1939                          POP3                          May 1996
+
+
+             secret.  This shared secret is a string known only to the
+             POP3 client and server.  Great care should be taken to
+             prevent unauthorized disclosure of the secret, as knowledge
+             of the secret will allow any entity to successfully
+             masquerade as the named user.  The `digest' parameter
+             itself is a 16-octet value which is sent in hexadecimal
+             format, using lower-case ASCII characters.
+
+             When the POP3 server receives the APOP command, it verifies
+             the digest provided.  If the digest is correct, the POP3
+             server issues a positive response, and the POP3 session
+             enters the TRANSACTION state.  Otherwise, a negative
+             response is issued and the POP3 session remains in the
+             AUTHORIZATION state.
+
+             Note that as the length of the shared secret increases, so
+             does the difficulty of deriving it.  As such, shared
+             secrets should be long strings (considerably longer than
+             the 8-character example shown below).
+
+         Possible Responses:
+             +OK maildrop locked and ready
+             -ERR permission denied
+
+         Examples:
+             S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
+             C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
+             S: +OK maildrop has 1 message (369 octets)
+
+             In this example, the shared  secret  is  the  string  `tan-
+             staaf'.  Hence, the MD5 algorithm is applied to the string
+
+                <1896.697170952@dbc.mtview.ca.us>tanstaaf
+
+             which produces a digest value of
+
+                c4c9334bac560ecc979e58001b3e22fb
+
+8. Scaling and Operational Considerations
+
+   Since some of the optional features described above were added to the
+   POP3 protocol, experience has accumulated in using them in large-
+   scale commercial post office operations where most of the users are
+   unrelated to each other.  In these situations and others, users and
+   vendors of POP3 clients have discovered that the combination of using
+   the UIDL command and not issuing the DELE command can provide a weak
+   version of the "maildrop as semi-permanent repository" functionality
+   normally associated with IMAP.  Of course the other capabilities of
+
+
+
+Myers & Rose                Standards Track                    [Page 16]
+
+RFC 1939                          POP3                          May 1996
+
+
+   IMAP, such as polling an existing connection for newly arrived
+   messages and supporting multiple folders on the server, are not
+   present in POP3.
+
+   When these facilities are used in this way by casual users, there has
+   been a tendency for already-read messages to accumulate on the server
+   without bound.  This is clearly an undesirable behavior pattern from
+   the standpoint of the server operator.  This situation is aggravated
+   by the fact that the limited capabilities of the POP3 do not permit
+   efficient handling of maildrops which have hundreds or thousands of
+   messages.
+
+   Consequently, it is recommended that operators of large-scale multi-
+   user servers, especially ones in which the user's only access to the
+   maildrop is via POP3, consider such options as:
+
+   *  Imposing a per-user maildrop storage quota or the like.
+
+      A disadvantage to this option is that accumulation of messages may
+      result in the user's inability to receive new ones into the
+      maildrop.  Sites which choose this option should be sure to inform
+      users of impending or current exhaustion of quota, perhaps by
+      inserting an appropriate message into the user's maildrop.
+
+   *  Enforce a site policy regarding mail retention on the server.
+
+      Sites are free to establish local policy regarding the storage and
+      retention of messages on the server, both read and unread.  For
+      example, a site might delete unread messages from the server after
+      60 days and delete read messages after 7 days.  Such message
+      deletions are outside the scope of the POP3 protocol and are not
+      considered a protocol violation.
+
+      Server operators enforcing message deletion policies should take
+      care to make all users aware of the policies in force.
+
+      Clients must not assume that a site policy will automate message
+      deletions, and should continue to explicitly delete messages using
+      the DELE command when appropriate.
+
+      It should be noted that enforcing site message deletion policies
+      may be confusing to the user community, since their POP3 client
+      may contain configuration options to leave mail on the server
+      which will not in fact be supported by the server.
+
+      One special case of a site policy is that messages may only be
+      downloaded once from the server, and are deleted after this has
+      been accomplished.  This could be implemented in POP3 server
+
+
+
+Myers & Rose                Standards Track                    [Page 17]
+
+RFC 1939                          POP3                          May 1996
+
+
+      software by the following mechanism: "following a POP3 login by a
+      client which was ended by a QUIT, delete all messages downloaded
+      during the session with the RETR command".  It is important not to
+      delete messages in the event of abnormal connection termination
+      (ie, if no QUIT was received from the client) because the client
+      may not have successfully received or stored the messages.
+      Servers implementing a download-and-delete policy may also wish to
+      disable or limit the optional TOP command, since it could be used
+      as an alternate mechanism to download entire messages.
+
+9. POP3 Command Summary
+
+      Minimal POP3 Commands:
+
+         USER name               valid in the AUTHORIZATION state
+         PASS string
+         QUIT
+
+         STAT                    valid in the TRANSACTION state
+         LIST [msg]
+         RETR msg
+         DELE msg
+         NOOP
+         RSET
+         QUIT
+
+      Optional POP3 Commands:
+
+         APOP name digest        valid in the AUTHORIZATION state
+
+         TOP msg n               valid in the TRANSACTION state
+         UIDL [msg]
+
+      POP3 Replies:
+
+         +OK
+         -ERR
+
+      Note that with the exception of the STAT, LIST, and UIDL commands,
+      the reply given by the POP3 server to any command is significant
+      only to "+OK" and "-ERR".  Any text occurring after this reply
+      may be ignored by the client.
+
+
+
+
+
+
+
+
+
+Myers & Rose                Standards Track                    [Page 18]
+
+RFC 1939                          POP3                          May 1996
+
+
+10. Example POP3 Session
+
+      S: <wait for connection on TCP port 110>
+      C: <open connection>
+      S:    +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
+      C:    APOP mrose c4c9334bac560ecc979e58001b3e22fb
+      S:    +OK mrose's maildrop has 2 messages (320 octets)
+      C:    STAT
+      S:    +OK 2 320
+      C:    LIST
+      S:    +OK 2 messages (320 octets)
+      S:    1 120
+      S:    2 200
+      S:    .
+      C:    RETR 1
+      S:    +OK 120 octets
+      S:    <the POP3 server sends message 1>
+      S:    .
+      C:    DELE 1
+      S:    +OK message 1 deleted
+      C:    RETR 2
+      S:    +OK 200 octets
+      S:    <the POP3 server sends message 2>
+      S:    .
+      C:    DELE 2
+      S:    +OK message 2 deleted
+      C:    QUIT
+      S:    +OK dewey POP3 server signing off (maildrop empty)
+      C:  <close connection>
+      S:  <wait for next connection>
+
+11. Message Format
+
+   All messages transmitted during a POP3 session are assumed to conform
+   to the standard for the format of Internet text messages [RFC822].
+
+   It is important to note that the octet count for a message on the
+   server host may differ from the octet count assigned to that message
+   due to local conventions for designating end-of-line.  Usually,
+   during the AUTHORIZATION state of the POP3 session, the POP3 server
+   can calculate the size of each message in octets when it opens the
+   maildrop.  For example, if the POP3 server host internally represents
+   end-of-line as a single character, then the POP3 server simply counts
+   each occurrence of this character in a message as two octets.  Note
+   that lines in the message which start with the termination octet need
+   not (and must not) be counted twice, since the POP3 client will
+   remove all byte-stuffed termination characters when it receives a
+   multi-line response.
+
+
+
+Myers & Rose                Standards Track                    [Page 19]
+
+RFC 1939                          POP3                          May 1996
+
+
+12. References
+
+   [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+       821, USC/Information Sciences Institute, August 1982.
+
+   [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text
+       Messages", STD 11, RFC 822, University of Delaware, August 1982.
+
+   [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+       MIT Laboratory for Computer Science, April 1992.
+
+   [RFC1730] Crispin, M., "Internet Message Access Protocol - Version
+       4", RFC 1730, University of Washington, December 1994.
+
+   [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,
+       Carnegie Mellon, December 1994.
+
+13. Security Considerations
+
+   It is conjectured that use of the APOP command provides origin
+   identification and replay protection for a POP3 session.
+   Accordingly, a POP3 server which implements both the PASS and APOP
+   commands should not allow both methods of access for a given user;
+   that is, for a given mailbox name, either the USER/PASS command
+   sequence or the APOP command is allowed, but not both.
+
+   Further, note that as the length of the shared secret increases, so
+   does the difficulty of deriving it.
+
+   Servers that answer -ERR to the USER command are giving potential
+   attackers clues about which names are valid.
+
+   Use of the PASS command sends passwords in the clear over the
+   network.
+
+   Use of the RETR and TOP commands sends mail in the clear over the
+   network.
+
+   Otherwise, security issues are not discussed in this memo.
+
+14. Acknowledgements
+
+   The POP family has a long and checkered history.  Although primarily
+   a minor revision to RFC 1460, POP3 is based on the ideas presented in
+   RFCs 918, 937, and 1081.
+
+   In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff
+   provided significant comments on the APOP command.
+
+
+
+Myers & Rose                Standards Track                    [Page 20]
+
+RFC 1939                          POP3                          May 1996
+
+
+15. Authors' Addresses
+
+   John G. Myers
+   Carnegie-Mellon University
+   5000 Forbes Ave
+   Pittsburgh, PA 15213
+
+   EMail: jgm+@cmu.edu
+
+
+   Marshall T. Rose
+   Dover Beach Consulting, Inc.
+   420 Whisman Court
+   Mountain View, CA  94043-2186
+
+   EMail: mrose@dbc.mtview.ca.us
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers & Rose                Standards Track                    [Page 21]
+
+RFC 1939                          POP3                          May 1996
+
+
+Appendix A. Differences from RFC 1725
+
+   This memo is a revision to RFC 1725, a Draft Standard.  It makes the
+   following changes from that document:
+
+      - clarifies that command keywords are case insensitive.
+
+      - specifies that servers must send "+OK" and "-ERR" in
+        upper case.
+
+      - specifies that the initial greeting is a positive response,
+        instead of any string which should be a positive response.
+
+      - clarifies behavior for unimplemented commands.
+
+      - makes the USER and PASS commands optional.
+
+      - clarified the set of possible responses to the USER command.
+
+      - reverses the order of the examples in the USER and PASS
+        commands, to reduce confusion.
+
+      - clarifies that the PASS command may only be given immediately
+        after a successful USER command.
+
+      - clarified the persistence requirements of UIDs and added some
+        implementation notes.
+
+      - specifies a UID length limitation of one to 70 octets.
+
+      - specifies a status indicator length limitation
+        of 512 octets, including the CRLF.
+
+      - clarifies that LIST with no arguments on an empty mailbox
+        returns success.
+
+      - adds a reference from the LIST command to the Message Format
+        section
+
+      - clarifies the behavior of QUIT upon failure
+
+      - clarifies the security section to not imply the use of the
+        USER command with the APOP command.
+
+      - adds references to RFCs 1730 and 1734
+
+      - clarifies the method by which a UA may enter mail into the
+        transport system.
+
+
+
+Myers & Rose                Standards Track                    [Page 22]
+
+RFC 1939                          POP3                          May 1996
+
+
+      - clarifies that the second argument to the TOP command is a
+        number of lines.
+
+      - changes the suggestion in the Security Considerations section
+        for a server to not accept both PASS and APOP for a given user
+        from a "must" to a "should".
+
+      - adds a section on scaling and operational considerations
+
+Appendix B. Command Index
+
+       APOP .......................................................   15
+       DELE .......................................................    8
+       LIST .......................................................    6
+       NOOP .......................................................    9
+       PASS .......................................................   14
+       QUIT .......................................................    5
+       QUIT .......................................................   10
+       RETR .......................................................    8
+       RSET .......................................................    9
+       STAT .......................................................    6
+       TOP ........................................................   11
+       UIDL .......................................................   12
+       USER .......................................................   13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers & Rose                Standards Track                    [Page 23]
+
diff --git a/docs/rfcs/rfc2061.txt b/docs/rfcs/rfc2061.txt
new file mode 100644
index 0000000..7cb02bb
--- /dev/null
+++ b/docs/rfcs/rfc2061.txt
@@ -0,0 +1,171 @@
+
+
+
+
+
+
+Network Working Group                                         M. Crispin
+Request for Comments: 2061                      University of Washington
+Category: Informational                                    December 1996
+
+
+                   IMAP4 COMPATIBILITY WITH IMAP2BIS
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Introduction
+
+   The Internet Message Access Protocol (IMAP) has been through several
+   revisions and variants in its 10-year history.  Many of these are
+   either extinct or extremely rare; in particular, several undocumented
+   variants and the variants described in RFC 1064, RFC 1176, and RFC
+   1203 fall into this category.
+
+   One variant, IMAP2bis, is at the time of this writing very common and
+   has been widely distributed with the Pine mailer.  Unfortunately,
+   there is no definite document describing IMAP2bis.  This document is
+   intended to be read along with RFC 1176 and the most recent IMAP4
+   specification (RFC 2060) to assist implementors in creating an IMAP4
+   implementation to interoperate with implementations that conform to
+   earlier specifications.  Nothing in this document is required by the
+   IMAP4 specification; implementors must decide for themselves whether
+   they want their implementation to fail if it encounters old software.
+
+   At the time of this writing, IMAP4 has been updated from the version
+   described in RFC 1730.  An implementor who wishes to interoperate
+   with both RFC 1730 and RFC 2060 should refer to both documents.
+
+   This information is not complete; it reflects current knowledge of
+   server and client implementations as well as "folklore" acquired in
+   the evolution of the protocol.  It is NOT a description of how to
+   interoperate with all variants of IMAP, but rather with the old
+   variant that is most likely to be encountered.  For detailed
+   information on interoperating with other old variants, refer to RFC
+   1732.
+
+IMAP4 client interoperability with IMAP2bis servers
+
+   A quick way to check whether a server implementation supports the
+   IMAP4 specification is to try the CAPABILITY command.  An OK response
+   will indicate which variant(s) of IMAP4 are supported by the server.
+
+
+
+Crispin                      Informational                      [Page 1]
+
+RFC 2061                  IMAP4 Compatibility              December 1996
+
+
+   If the client does not find any of its known variant in the response,
+   it should treat the server as IMAP2bis.  A BAD response indicates an
+   IMAP2bis or older server.
+
+   Most IMAP4 facilities are in IMAP2bis.  The following exceptions
+   exist:
+
+   CAPABILITY command
+            The absense of this command indicates IMAP2bis (or older).
+
+   AUTHENTICATE command.
+            Use the LOGIN command.
+
+   LSUB, SUBSCRIBE, and UNSUBSCRIBE commands
+            No direct functional equivalent.  IMAP2bis had a concept
+            called "bboards" which is not in IMAP4.  RFC 1176 supported
+            these with the BBOARD and FIND BBOARDS commands.  IMAP2bis
+            augmented these with the FIND ALL.BBOARDS, SUBSCRIBE BBOARD,
+            and UNSUBSCRIBE BBOARD commands.  It is recommended that
+            none of these commands be implemented in new software,
+            including servers that support old clients.
+
+   LIST command
+            Use the command FIND ALL.MAILBOXES, which has a similar syn-
+            tax and response to the FIND MAILBOXES command described in
+            RFC 1176.  The FIND MAILBOXES command is unlikely to produce
+            useful information.
+
+   * in a sequence
+            Use the number of messages in the mailbox from the EXISTS
+            unsolicited response.
+
+   SEARCH extensions (character set, additional criteria)
+            Reformulate the search request using only the RFC 1176 syn-
+            tax.  This may entail doing multiple searches to achieve the
+            desired results.
+
+   BODYSTRUCTURE fetch data item
+            Use the non-extensible BODY data item.
+
+   body sections HEADER, TEXT, MIME, HEADER.FIELDS, HEADER.FIELDS.NOT
+            Use body section numbers only.
+
+   BODY.PEEK[section]
+            Use BODY[section] and manually clear the \Seen flag as
+            necessary.
+
+
+
+
+
+Crispin                      Informational                      [Page 2]
+
+RFC 2061                  IMAP4 Compatibility              December 1996
+
+
+   FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items
+            Use the corresponding non-SILENT versions and ignore the
+            untagged FETCH responses which come back.
+
+   UID fetch data item and the UID commands
+            No functional equivalent.
+
+   CLOSE command
+            No functional equivalent.
+
+
+   In IMAP2bis, the TRYCREATE special information token is sent as a
+   separate unsolicited OK response instead of inside the NO response.
+
+   IMAP2bis is ambiguous about whether or not flags or internal dates
+   are preserved on COPY.  It is impossible to know what behavior is
+   supported by the server.
+
+IMAP4 server interoperability with IMAP2bis clients
+
+   The only interoperability problem between an IMAP4 server and a
+   well-written IMAP2bis client is an incompatibility with the use of
+   "\" in quoted strings.  This is best avoided by using literals
+   instead of quoted strings if "\" or <"> is embedded in the string.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Author's Address
+
+   Mark R. Crispin
+   Networks and Distributed Computing
+   University of Washington
+   4545 15th Aveneue NE
+   Seattle, WA  98105-4527
+
+   Phone: (206) 543-5762
+   EMail: MRC@CAC.Washington.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                      Informational                      [Page 3]
+
diff --git a/docs/rfcs/rfc2062.txt b/docs/rfcs/rfc2062.txt
new file mode 100644
index 0000000..865d1da
--- /dev/null
+++ b/docs/rfcs/rfc2062.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                         M. Crispin
+Request for Comments: 2062                      University of Washington
+Category: Informational                                    December 1996
+
+
+           Internet Message Access Protocol - Obsolete Syntax
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   This document describes obsolete syntax which may be encountered by
+   IMAP4 implementations which deal with older versions of the Internet
+   Mail Access Protocol.  IMAP4 implementations MAY implement this
+   syntax in order to maximize interoperability with older
+   implementations.
+
+   This document repeats information from earlier documents, most
+   notably RFC 1176 and RFC 1730.
+
+Obsolete Commands and Fetch Data Items
+
+   The following commands are OBSOLETE.  It is NOT required to support
+   any of these commands or fetch data items in new server
+   implementations.  These commands are documented here for the benefit
+   of implementors who may wish to support them for compatibility with
+   old client implementations.
+
+   The section headings of these commands are intended to correspond
+   with where they would be located in the main document if they were
+   not obsoleted.
+
+6.3.OBS.1.      FIND ALL.MAILBOXES Command
+
+   Arguments:  mailbox name with possible wildcards
+
+   Data:       untagged responses: MAILBOX
+
+   Result:     OK - find completed
+               NO - find failure: can't list that name
+               BAD - command unknown or arguments invalid
+
+
+
+
+
+
+Crispin                      Informational                      [Page 1]
+
+RFC 2062                     IMAP4 Obsolete                December 1996
+
+
+      The FIND ALL.MAILBOXES command returns a subset of names from the
+      complete set of all names available to the user.  It returns zero
+      or more untagged MAILBOX replies.  The mailbox argument to FIND
+      ALL.MAILBOXES is similar to that for LIST with an empty reference,
+      except that the characters "%" and "?" match a single character.
+
+   Example:    C: A002 FIND ALL.MAILBOXES *
+               S: * MAILBOX blurdybloop
+               S: * MAILBOX INBOX
+               S: A002 OK FIND ALL.MAILBOXES completed
+
+6.3.OBS.2.      FIND MAILBOXES Command
+
+   Arguments:  mailbox name with possible wildcards
+
+   Data:       untagged responses: MAILBOX
+
+   Result:     OK - find completed
+               NO - find failure: can't list that name
+               BAD - command unknown or arguments invalid
+
+      The FIND MAILBOXES command returns a subset of names from the set
+      of names that the user has declared as being "active" or
+      "subscribed".  It returns zero or more untagged MAILBOX replies.
+      The mailbox argument to FIND MAILBOXES is similar to that for LSUB
+      with an empty reference, except that the characters "%" and "?"
+      match a single character.
+
+   Example:    C: A002 FIND MAILBOXES *
+               S: * MAILBOX blurdybloop
+               S: * MAILBOX INBOX
+               S: A002 OK FIND MAILBOXES completed
+
+6.3.OBS.3.      SUBSCRIBE MAILBOX Command
+
+   Arguments:  mailbox name
+
+   Data:       no specific data for this command
+
+   Result:     OK - subscribe completed
+               NO - subscribe failure: can't subscribe to that name
+               BAD - command unknown or arguments invalid
+
+      The SUBSCRIBE MAILBOX command is identical in effect to the
+      SUBSCRIBE command.  A server which implements this command must be
+      able to distinguish between a SUBSCRIBE MAILBOX command and a
+      SUBSCRIBE command with a mailbox name argument of "MAILBOX".
+
+
+
+
+Crispin                      Informational                      [Page 2]
+
+RFC 2062                     IMAP4 Obsolete                December 1996
+
+
+   Example:    C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime
+               S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime
+               completed
+               C: A003 SUBSCRIBE MAILBOX
+               S: A003 OK SUBSCRIBE to MAILBOX completed
+
+
+6.3.OBS.4.      UNSUBSCRIBE MAILBOX Command
+
+   Arguments:  mailbox name
+
+   Data:       no specific data for this command
+
+   Result:     OK - unsubscribe completed
+               NO - unsubscribe failure: can't unsubscribe that name
+               BAD - command unknown or arguments invalid
+
+      The UNSUBSCRIBE MAILBOX command is identical in effect to the
+      UNSUBSCRIBE command.  A server which implements this command must
+      be able to distinguish between a UNSUBSCRIBE MAILBOX command and
+      an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX".
+
+   Example:    C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime
+               S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime
+               completed
+               C: A003 UNSUBSCRIBE MAILBOX
+               S: A003 OK UNSUBSCRIBE from MAILBOX completed
+
+6.4.OBS.1       PARTIAL Command
+
+   Arguments:  message sequence number
+               message data item name
+               position of first octet
+               number of octets
+
+   Data:       untagged responses: FETCH
+
+   Result:     OK - partial completed
+               NO - partial error: can't fetch that data
+               BAD - command unknown or arguments invalid
+
+      The PARTIAL command is equivalent to the associated FETCH command,
+      with the added functionality that only the specified number of
+      octets, beginning at the specified starting octet, are returned.
+      Only a single message can be fetched at a time.  The first octet
+      of a message, and hence the minimum for the starting octet, is
+      octet 1.
+
+
+
+
+Crispin                      Informational                      [Page 3]
+
+RFC 2062                     IMAP4 Obsolete                December 1996
+
+
+      The following FETCH items are valid data for PARTIAL: RFC822,
+      RFC822.HEADER, RFC822.TEXT, BODY[<section>], as well as any .PEEK
+      forms of these.
+
+      Any partial fetch that attempts to read beyond the end of the text
+      is truncated as appropriate.  If the starting octet is beyond the
+      end of the text, an empty string is returned.
+
+      The data are returned with the FETCH response.  There is no
+      indication of the range of the partial data in this response.  It
+      is not possible to stream multiple PARTIAL commands of the same
+      data item without processing and synchronizing at each step, since
+      streamed commands may be executed out of order.
+
+      There is no requirement that partial fetches follow any sequence.
+      For example, if a partial fetch of octets 1 through 10000 breaks
+      in an awkward place for BASE64 decoding, it is permitted to
+      continue with a partial fetch of 9987 through 19987, etc.
+
+      The handling of the \Seen flag is the same as in the associated
+      FETCH command.
+
+   Example:    C: A005 PARTIAL 4 RFC822 1 1024
+               S: * 1 FETCH (RFC822 {1024}
+               S: Return-Path: <gray@cac.washington.edu>
+               S: ...
+               S: .........  FLAGS (\Seen))
+               S: A005 OK PARTIAL completed
+
+6.4.5.OBS.1     Obsolete FETCH Data Items
+
+   The following FETCH data items are obsolete:
+
+      BODY[<...>0]   A body part number of 0 is the [RFC-822] header of
+                     the message.  BODY[0] is functionally equivalent to
+                     BODY[HEADER], differing in the syntax of the
+                     resulting untagged FETCH data (BODY[0] is
+                     returned).
+
+      RFC822.HEADER.LINES <header_list>
+                     Functionally equivalent to BODY.PEEK[HEADER.LINES
+                     <header_list>], differing in the syntax of the
+                     resulting untagged FETCH data (RFC822.HEADER is
+                     returned).
+
+
+
+
+
+
+
+Crispin                      Informational                      [Page 4]
+
+RFC 2062                     IMAP4 Obsolete                December 1996
+
+
+      RFC822.HEADER.LINES.NOT <header_list>
+                     Functionally equivalent to
+                     BODY.PEEK[HEADER.LINES.NOT <header_list>],
+                     differing in the syntax of the resulting untagged
+                     FETCH data (RFC822.HEADER is returned).
+
+      RFC822.PEEK    Functionally equivalent to BODY.PEEK[], except for
+                     the syntax of the resulting untagged FETCH data
+                     (RFC822 is returned).
+
+      RFC822.TEXT.PEEK
+                     Functionally equivalent to BODY.PEEK[TEXT], except
+                     for the syntax of the resulting untagged FETCH data
+                     (RFC822.TEXT is returned).
+
+Obsolete Responses
+
+   The following responses are OBSOLETE.  Except as noted below, these
+   responses MUST NOT be transmitted by new server implementations.
+   Client implementations SHOULD accept these responses.
+
+   The section headings of these responses are intended to correspond
+   with where they would be located in the main document if they were
+   not obsoleted.
+
+7.2.OBS.1.      MAILBOX Response
+
+   Data:       name
+
+      The MAILBOX response MUST NOT be transmitted by server
+      implementations except in response to the obsolete FIND MAILBOXES
+      and FIND ALL.MAILBOXES commands.  Client implementations that do
+      not use these commands MAY ignore this response.  It is documented
+      here for the benefit of implementors who may wish to support it
+      for compatibility with old client implementations.
+
+      This response occurs as a result of the FIND MAILBOXES and FIND
+      ALL.MAILBOXES commands.  It returns a single name that matches the
+      FIND specification.  There are no attributes or hierarchy
+      delimiter.
+
+   Example:    S: * MAILBOX blurdybloop
+
+
+
+
+
+
+
+
+
+Crispin                      Informational                      [Page 5]
+
+RFC 2062                     IMAP4 Obsolete                December 1996
+
+
+7.3.OBS.1.      COPY Response
+
+   Data:       none
+
+      The COPY response MUST NOT be transmitted by new server
+      implementations.  Client implementations MUST ignore the COPY
+      response.  It is documented here for the benefit of client
+      implementors who may encounter this response from old server
+      implementations.
+
+      In some experimental versions of this protocol, this response was
+      returned in response to a COPY command to indicate on a
+      per-message basis that the message was copied successfully.
+
+   Example:    S: * 44 COPY
+
+7.3.OBS.2.      STORE Response
+
+   Data:       message data
+
+      The STORE response MUST NOT be transmitted by new server
+      implementations.  Client implementations MUST treat the STORE
+      response as equivalent to the FETCH response.  It is documented
+      here for the benefit of client implementors who may encounter this
+      response from old server implementations.
+
+      In some experimental versions of this protocol, this response was
+      returned instead of FETCH in response to a STORE command to report
+      the new value of the flags.
+
+   Example:    S: * 69 STORE (FLAGS (\Deleted))
+
+Formal Syntax of Obsolete Commands and Responses
+
+   Each obsolete syntax rule that is suffixed with "_old" is added to
+   the corresponding name in the formal syntax.  For example,
+   command_auth_old adds the FIND command to command_auth.
+
+   command_auth_old ::= find
+
+   command_select_old
+                   ::= partial
+
+   date_year_old   ::= 2digit
+                       ;; (year - 1900)
+
+   date_time_old   ::= <"> date_day_fixed "-" date_month "-" date_year
+                       SPACE time "-" zone_name <">
+
+
+
+Crispin                      Informational                      [Page 6]
+
+RFC 2062                     IMAP4 Obsolete                December 1996
+
+
+   find            ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE
+                       list_mailbox
+
+   fetch_att_old   ::= "RFC822.HEADER.LINES" [".NOT"] SPACE header_list /
+                       fetch_text_old
+
+   fetch_text_old  ::= "BODY" [".PEEK"] section_old /
+                       "RFC822" [".HEADER" / ".TEXT" [".PEEK"]]
+
+   msg_data_old    ::= "COPY" / ("STORE" SPACE msg_att)
+
+   partial         ::= "PARTIAL" SPACE nz_number SPACE fetch_text_old SPACE
+                       number SPACE number
+
+   section_old     ::= "[" (number ["." number]) "]"
+
+   subscribe_old   ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
+
+   unsubscribe_old ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
+
+   zone_name       ::= "UT" / "GMT" / "Z" /                ;; +0000
+                       "AST" / "EDT" /                     ;; -0400
+                       "EST" / "CDT" /                     ;; -0500
+                       "CST" / "MDT" /                     ;; -0600
+                       "MST" / "PDT" /                     ;; -0700
+                       "PST" / "YDT" /                     ;; -0800
+                       "YST" / "HDT" /                     ;; -0900
+                       "HST" / "BDT" /                     ;; -1000
+                       "BST" /                             ;; -1100
+                       "A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6
+                       "G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12
+                       "N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6
+                       "T" / "U" / "V" / "W" / "X" / "Y"   ;; -7 to -12
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                      Informational                      [Page 7]
+
+RFC 2062                     IMAP4 Obsolete                December 1996
+
+
+Author's Address
+
+   Mark R. Crispin
+   Networks and Distributed Computing
+   University of Washington
+   4545 15th Aveneue NE
+   Seattle, WA  98105-4527
+
+   Phone: (206) 543-5762
+   EMail: MRC@CAC.Washington.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                      Informational                      [Page 8]
+
diff --git a/docs/rfcs/rfc2086.txt b/docs/rfcs/rfc2086.txt
new file mode 100644
index 0000000..b6a98b5
--- /dev/null
+++ b/docs/rfcs/rfc2086.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                           J. Myers
+Request for Comments: 2086                               Carnegie Mellon
+Category: Standards Track                                   January 1997
+
+
+                          IMAP4 ACL extension
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+1.   Abstract
+
+   The ACL extension of the Internet Message Access Protocol [IMAP4]
+   permits access control lists to be manipulated through the IMAP
+   protocol.
+
+Table of Contents
+
+   1.   Abstract............................................... 1
+   2.   Conventions Used in this Document...................... 1
+   3.   Introduction and Overview.............................. 2
+   4.   Commands............................................... 3
+   4.1. SETACL................................................. 3
+   4.2. DELETEACL.............................................. 4
+   4.3. GETACL................................................. 4
+   4.4. LISTRIGHTS............................................. 4
+   4.5. MYRIGHTS............................................... 5
+   5.   Responses.............................................. 5
+   5.1. ACL.................................................... 5
+   5.2. LISTRIGHTS............................................. 6
+   5.3. MYRIGHTS............................................... 6
+   6.   Formal Syntax.......................................... 6
+   7.   References............................................. 7
+   8.   Security Considerations................................ 7
+   9.   Author's Address....................................... 8
+
+2.   Conventions Used in this Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 1]
+
+RFC 2086                     ACL extension                  January 1997
+
+
+3.   Introduction and Overview
+
+   The ACL extension is present in any IMAP4 implementation which
+   returns "ACL" as one of the supported capabilities to the CAPABILITY
+   command.
+
+   An access control list is a set of <identifier,rights> pairs.
+
+   Identifier is a US-ASCII string.  The identifier anyone is reserved
+   to refer to the universal identity (all authentications, including
+   anonymous). All user name strings accepted by the LOGIN or
+   AUTHENTICATE commands to authenticate to the IMAP server are reserved
+   as identifiers for the corresponding user.  Identifiers starting with
+   a dash ("-") are reserved for "negative rights", described below.
+   All other identifier strings are interpreted in an implementation-
+   defined manner.
+
+   Rights is a string listing a (possibly empty) set of alphanumeric
+   characters, each character listing a set of operations which is being
+   controlled. Letters are reserved for ``standard'' rights, listed
+   below.  The set of standard rights may only be extended by a
+   standards-track document.  Digits are reserved for implementation or
+   site defined rights.  The currently defined standard rights are:
+
+   l - lookup (mailbox is visible to LIST/LSUB commands)
+   r - read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL,
+       SEARCH, COPY from mailbox)
+   s - keep seen/unseen information across sessions (STORE SEEN flag)
+   w - write (STORE flags other than SEEN and DELETED)
+   i - insert (perform APPEND, COPY into mailbox)
+   p - post (send mail to submission address for mailbox,
+       not enforced by IMAP4 itself)
+   c - create (CREATE new sub-mailboxes in any implementation-defined
+       hierarchy)
+   d - delete (STORE DELETED flag, perform EXPUNGE)
+   a - administer (perform SETACL)
+
+   An implementation may tie rights together or may force rights to
+   always or never be granted to particular identifiers.  For example,
+   in an implementation that uses unix mode bits, the rights "wisd" are
+   tied, the "a" right is always granted to the owner of a mailbox and
+   is never granted to another user.  If rights are tied in an
+   implementation, the implementation must be conservative in granting
+   rights in response to SETACL commands--unless all rights in a tied
+   set are specified, none of that set should be included in the ACL
+   entry for that identifier.  A client may discover the set of rights
+   which may be granted to a given identifier in the ACL for a given
+   mailbox by using the LISTRIGHTS command.
+
+
+
+Myers                       Standards Track                     [Page 2]
+
+RFC 2086                     ACL extension                  January 1997
+
+
+   It is possible for multiple identifiers in an access control list to
+   apply to a given user (or other authentication identity).  For
+   example, an ACL may include rights to be granted to the identifier
+   matching the user, one or more implementation-defined identifiers
+   matching groups which include the user, and/or the identifier
+   "anyone".  How these rights are combined to determine the user's
+   access is implementation-defined.  An implementation may choose, for
+   example, to use the union of the rights granted to the applicable
+   identifiers.  An implementation may instead choose, for example, to
+   only use those rights granted to the most specific identifier present
+   in the ACL. A client may determine the set of rights granted to the
+   logged-in user for a given mailbox by using the MYRIGHTS command.
+
+   When an identifier in an ACL starts with a dash ("-"), that indicates
+   that associated rights are to be removed from the identifier that is
+   prefixed by the dash.  For example, if the identifier "-fred" is
+   granted the "w" right, that indicates that the "w" right is to be
+   removed from users matching the identifier "fred".  Implementations
+   need not support having identifiers which start with a dash in ACLs.
+
+4.   Commands
+
+4.1. SETACL
+
+   Arguments:  mailbox name
+               authentication identifier
+               access right modification
+
+   Data:       no specific data for this command
+
+   Result:     OK - setacl completed
+               NO - setacl failure: can't set acl
+              BAD - command unknown or arguments invalid
+
+      The SETACL command changes the access control list on the
+      specified mailbox so that the specified identifier is granted
+      permissions as specified in the third argument.
+
+      The third argument is a string containing an optional plus ("+")
+      or minus ("-") prefix, followed by zero or more rights characters.
+      If the string starts with a plus, the following rights are added
+      to any existing rights for the identifier.  If the string starts
+      with a minus, the following rights are removed from any existing
+      rights for the identifier.  If the string does not start with a
+      plus or minus, the rights replace any existing rights for the
+      identifier.
+
+
+
+
+
+Myers                       Standards Track                     [Page 3]
+
+RFC 2086                     ACL extension                  January 1997
+
+
+4.2. DELETEACL
+
+   Arguments:  mailbox name
+               authentication identifier
+
+   Data:       no specific data for this command
+
+   Result:     OK - deleteacl completed
+               NO - deleteacl failure: can't delete acl
+              BAD - command unknown or arguments invalid
+
+      The DELETEACL command removes any <identifier,rights> pair for the
+      specified identifier from the access control list for the specified
+      mailbox.
+
+4.3. GETACL
+
+   Arguments:  mailbox name
+
+   Data:       untagged responses: ACL
+
+   Result:     OK - getacl completed
+               NO - getacl failure: can't get acl
+              BAD - command unknown or arguments invalid
+
+      The GETACL command returns the access control list for mailbox in
+      an untagged ACL reply.
+
+   Example:    C: A002 GETACL INBOX
+               S: * ACL INBOX Fred rwipslda
+               S: A002 OK Getacl complete
+
+4.4. LISTRIGHTS
+
+   Arguments:  mailbox name
+               authentication identifier
+
+   Data:       untagged responses: LISTRIGHTS
+
+   Result:     OK - listrights completed
+               NO - listrights failure: can't get rights list
+              BAD - command unknown or arguments invalid
+
+      The LISTRIGHTS command takes a mailbox name and an identifier and
+      returns information about what rights may be granted to the identifier
+      in the ACL for the mailbox.
+
+
+
+
+
+Myers                       Standards Track                     [Page 4]
+
+RFC 2086                     ACL extension                  January 1997
+
+
+   Example:    C: a001 LISTRIGHTS ~/Mail/saved smith
+               S: * LISTRIGHTS ~/Mail/saved smith la r swicd
+               S: a001 OK Listrights completed
+
+
+               C: a005 LISTRIGHTS archive.imap anyone
+               S: * LISTRIGHTS archive.imap anyone "" l r s w i p c d a
+               0 1 2 3 4 5 6 7 8 9
+
+4.5. MYRIGHTS
+
+   Arguments:  mailbox name
+
+   Data:       untagged responses: MYRIGHTS
+
+   Result:     OK - myrights completed
+               NO - myrights failure: can't get rights
+              BAD - command unknown or arguments invalid
+
+      The MYRIGHTS command returns the set of rights that the user has
+      to mailbox in an untagged MYRIGHTS reply.
+
+   Example:    C: A003 MYRIGHTS INBOX
+               S: * MYRIGHTS INBOX rwipslda
+               S: A003 OK Myrights complete
+
+5.   Responses
+
+5.1. ACL
+
+   Data:       mailbox name
+               zero or more identifier rights pairs
+
+      The ACL response occurs as a result of a GETACL command. The first
+      string is the mailbox name for which this ACL applies.  This is
+      followed by zero or more pairs of strings, each pair contains the
+      identifier for which the entry applies followed by the set of
+      rights that the identifier has.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 5]
+
+RFC 2086                     ACL extension                  January 1997
+
+
+5.2. LISTRIGHTS
+
+   Data:       mailbox name
+               identifier
+               required rights
+               list of optional rights
+
+      The LISTRIGHTS response occurs as a result of a LISTRIGHTS
+      command. The first two strings are the mailbox name and identifier
+      for which this rights list applies.  Following the identifier is a
+      string containing the (possibly empty) set of rights the
+      identifier will always be granted in the mailbox.
+
+      Following this are zero or more strings each containing a set of
+      rights the identifier may be granted in the mailbox.  Rights
+      mentioned in the same string are tied together--either all must be
+      granted to the identifier in the mailbox or none may be granted.
+
+      The same right may not be listed more than once in the LISTRIGHTS
+      command.
+
+5.3. MYRIGHTS
+
+   Data:       mailbox name
+               rights
+
+      The MYRIGHTS response occurs as a result of a MYRIGHTS command.
+      The first string is the mailbox name for which these rights apply.
+      The second string is the set of rights that the client has.
+
+6.   Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
+   Non-terminals referenced but not defined below are as defined by
+   [IMAP4].
+
+   Except as noted otherwise, all alphabetic characters are case-
+   insensitive.  The use of upper or lower case characters to define
+   token strings is for editorial clarity only. Implementations MUST
+   accept these strings in a case-insensitive fashion.
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 6]
+
+RFC 2086                     ACL extension                  January 1997
+
+
+   acl_data        ::= "ACL" SPACE mailbox *(SPACE identifier SPACE
+                        rights)
+
+   deleteacl       ::= "DELETEACL" SPACE mailbox SPACE identifier
+
+   getacl          ::= "GETACL" SPACE mailbox
+
+   identifier      ::= astring
+
+   listrights      ::= "LISTRIGHTS" SPACE mailbox SPACE identifier
+
+   listrights_data ::= "LISTRIGHTS" SPACE mailbox SPACE identifier
+                           SPACE rights *(SPACE rights)
+
+   mod_rights      ::= astring
+                           ;; +rights to add, -rights to remove
+                           ;; rights to replace
+
+   myrights        ::= "MYRIGHTS" SPACE mailbox
+
+   myrights_data   ::= "MYRIGHTS" SPACE mailbox SPACE rights
+
+   rights          ::= astring
+
+   setacl          ::= "SETACL" SPACE mailbox SPACE identifier
+                       SPACE mod_rights
+
+7.   References
+
+   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
+   RFC 1730, University of Washington, December 1994.
+
+   [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
+   Messages", STD 11, RFC 822.
+
+8.   Security Considerations
+
+   An implementation must make sure the ACL commands themselves do not
+   give information about mailboxes with appropriately restricted ACL's.
+   For example, a GETACL command on a mailbox for which the user has
+   insufficient rights should not admit the mailbox exists, much less
+   return the mailbox's ACL.
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 7]
+
+RFC 2086                     ACL extension                  January 1997
+
+
+9.   Author's Address
+
+   John G. Myers
+   Carnegie-Mellon University
+   5000 Forbes Ave.
+   Pittsburgh PA, 15213-3890
+
+   Email: jgm+@cmu.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 8]
+
diff --git a/docs/rfcs/rfc2087.txt b/docs/rfcs/rfc2087.txt
new file mode 100644
index 0000000..1db5b57
--- /dev/null
+++ b/docs/rfcs/rfc2087.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                           J. Myers
+Request for Comments: 2087                               Carnegie Mellon
+Category: Standards Track                                   January 1997
+
+
+                         IMAP4 QUOTA extension
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+1.   Abstract
+
+   The QUOTA extension of the Internet Message Access Protocol [IMAP4]
+   permits administrative limits on resource usage (quotas) to be
+   manipulated through the IMAP protocol.
+
+Table of Contents
+
+   1.   Abstract........................................... 1
+   2.   Conventions Used in this Document.................. 1
+   3.   Introduction and Overview.......................... 2
+   4.   Commands........................................... 2
+   4.1. SETQUOTA Command................................... 2
+   4.2. GETQUOTA Command................................... 2
+   4.3. GETQUOTAROOT Command............................... 3
+   5.   Responses.......................................... 3
+   5.1. QUOTA Response..................................... 3
+   5.2. QUOTAROOT Response................................. 4
+   6.   Formal syntax...................................... 4
+   7.   References......................................... 5
+   8.   Security Considerations............................ 5
+   9.   Author's Address................................... 5
+
+
+2.   Conventions Used in this Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 1]
+
+RFC 2087                         QUOTA                      January 1997
+
+
+3.   Introduction and Overview
+
+   The QUOTA extension is present in any IMAP4 implementation which
+   returns "QUOTA" as one of the supported capabilities to the
+   CAPABILITY command.
+
+   An IMAP4 server which supports the QUOTA capability may support
+   limits on any number of resources.  Each resource has an atom name
+   and an implementation-defined interpretation which evaluates to an
+   integer.  Examples of such resources are:
+
+      Name       Interpretation
+
+      STORAGE    Sum of messages' RFC822.SIZE, in units of 1024 octets
+      MESSAGE    Number of messages
+
+
+   Each mailbox has zero or more implementation-defined named "quota
+   roots".  Each quota root has zero or more resource limits.  All
+   mailboxes that share the same named quota root share the resource
+   limits of the quota root.
+
+   Quota root names do not necessarily have to match the names of
+   existing mailboxes.
+
+4.   Commands
+
+4.1. SETQUOTA Command
+
+   Arguments:  quota root
+               list of resource limits
+
+   Data:       untagged responses: QUOTA
+
+   Result:     OK - setquota completed
+               NO - setquota error: can't set that data
+               BAD - command unknown or arguments invalid
+
+   The SETQUOTA command takes the name of a mailbox quota root and a
+   list of resource limits. The resource limits for the named quota root
+   are changed to be the specified limits.  Any previous resource limits
+   for the named quota root are discarded.
+
+   If the named quota root did not previously exist, an implementation
+   may optionally create it and change the quota roots for any number of
+   existing mailboxes in an implementation-defined manner.
+
+
+
+
+
+Myers                       Standards Track                     [Page 2]
+
+RFC 2087                         QUOTA                      January 1997
+
+
+   Example:    C: A001 SETQUOTA "" (STORAGE 512)
+               S: * QUOTA "" (STORAGE 10 512)
+               S: A001 OK Setquota completed
+
+4.2. GETQUOTA Command
+
+   Arguments:  quota root
+
+   Data:       untagged responses: QUOTA
+
+   Result:     OK - getquota completed
+               NO - getquota  error:  no  such  quota  root,  permission
+               denied
+               BAD - command unknown or arguments invalid
+
+   The GETQUOTA command takes the name of a quota root and returns the
+   quota root's resource usage and limits in an untagged QUOTA response.
+
+   Example:    C: A003 GETQUOTA ""
+               S: * QUOTA "" (STORAGE 10 512)
+               S: A003 OK Getquota completed
+
+4.3. GETQUOTAROOT Command
+
+   Arguments:  mailbox name
+
+   Data:       untagged responses: QUOTAROOT, QUOTA
+
+   Result:     OK - getquota completed
+               NO - getquota error: no such mailbox, permission denied
+               BAD - command unknown or arguments invalid
+
+   The GETQUOTAROOT command takes the name of a mailbox and returns the
+   list of quota roots for the mailbox in an untagged QUOTAROOT
+   response.  For each listed quota root, it also returns the quota
+   root's resource usage and limits in an untagged QUOTA response.
+
+   Example:    C: A003 GETQUOTAROOT INBOX
+               S: * QUOTAROOT INBOX ""
+               S: * QUOTA "" (STORAGE 10 512)
+               S: A003 OK Getquota completed
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 3]
+
+RFC 2087                         QUOTA                      January 1997
+
+
+5.   Responses
+
+5.1. QUOTA Response
+
+   Data:       quota root name
+               list of resource names, usages, and limits
+
+      This response occurs as a result of a GETQUOTA or GETQUOTAROOT
+      command. The first string is the name of the quota root for which
+      this quota applies.
+
+      The name is followed by a S-expression format list of the resource
+      usage and limits of the quota root.  The list contains zero or
+      more triplets.  Each triplet conatins a resource name, the current
+      usage of the resource, and the resource limit.
+
+      Resources not named in the list are not limited in the quota root.
+      Thus, an empty list means there are no administrative resource
+      limits in the quota root.
+
+      Example:    S: * QUOTA "" (STORAGE 10 512)
+
+5.2. QUOTAROOT Response
+
+   Data:       mailbox name
+               zero or more quota root names
+
+      This response occurs as a result of a GETQUOTAROOT command.  The
+      first string is the mailbox and the remaining strings are the
+      names of the quota roots for the mailbox.
+
+      Example:    S: * QUOTAROOT INBOX ""
+                  S: * QUOTAROOT comp.mail.mime
+
+6.   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 (SP) and not
+   one or more commas.
+
+   Except as noted otherwise, all alphabetic characters are case-
+   insensitive.  The use of upper or lower case characters to define
+   token strings is for editorial clarity only.  Implementations MUST
+   accept these strings in a case-insensitive fashion.
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 4]
+
+RFC 2087                         QUOTA                      January 1997
+
+
+   getquota        ::= "GETQUOTA" SP astring
+
+   getquotaroot    ::= "GETQUOTAROOT" SP astring
+
+   quota_list      ::= "(" #quota_resource ")"
+
+   quota_resource  ::= atom SP number SP number
+
+   quota_response  ::= "QUOTA" SP astring SP quota_list
+
+   quotaroot_response
+                   ::= "QUOTAROOT" SP astring *(SP astring)
+
+   setquota        ::= "SETQUOTA" SP astring SP setquota_list
+
+   setquota_list   ::= "(" 0#setquota_resource ")"
+
+   setquota_resource ::= atom SP number
+
+7.   References
+
+   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
+   RFC 1730, University of Washington, December 1994.
+
+   [RFC-822] Crocker, D., "Standard for    the Format of ARPA Internet
+   Text Messages", STD 11, RFC 822.
+
+8.   Security Considerations
+
+   Implementors should be careful to make sure the implementation of
+   these commands does not violate the site's security policy. The
+   resource usage of other users is likely to be considered confidential
+   information and should not be divulged to unauthorized persons.
+
+9.   Author's Address
+
+   John G. Myers
+   Carnegie-Mellon University
+   5000 Forbes Ave.
+   Pittsburgh PA, 15213-3890
+
+   EMail: jgm+@cmu.edu
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 5]
+
diff --git a/docs/rfcs/rfc2088.txt b/docs/rfcs/rfc2088.txt
new file mode 100644
index 0000000..f36cc76
--- /dev/null
+++ b/docs/rfcs/rfc2088.txt
@@ -0,0 +1,115 @@
+
+
+
+
+
+
+Network Working Group                                           J. Myers
+Request for Comments: 2088                               Carnegie Mellon
+Cateogry: Standards Track                                   January 1997
+
+
+                    IMAP4 non-synchronizing literals
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+1.   Abstract
+
+   The Internet Message Access Protocol [IMAP4] contains the "literal"
+   syntactic construct for communicating strings.  When sending a
+   literal from client to server, IMAP4 requires the client to wait for
+   the server to send a command continuation request between sending the
+   octet count and the string data.  This document specifies an
+   alternate form of literal which does not require this network round
+   trip.
+
+2.   Conventions Used in this Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+3.   Specification
+
+   The non-synchronizing literal is added an alternate form of literal,
+   and may appear in communication from client to server instead of the
+   IMAP4 form of literal.  The IMAP4 form of literal, used in
+   communication from client to server, is referred to as a
+   synchronizing literal.
+
+   Non-synchronizing literals may be used with any IMAP4 server
+   implementation which returns "LITERAL+" as one of the supported
+   capabilities to the CAPABILITY command.  If the server does not
+   advertise the LITERAL+ capability, the client must use synchronizing
+   literals instead.
+
+   The non-synchronizing literal is distinguished from the original
+   synchronizing literal by having a plus ('+') between the octet count
+   and the closing brace ('}').  The server does not generate a command
+   continuation request in response to a non-synchronizing literal, and
+
+
+
+Myers                       Standards Track                     [Page 1]
+
+RFC 2088                        LITERAL                     January 1997
+
+
+   clients are not required to wait before sending the octets of a non-
+   synchronizing literal.
+
+   The protocol receiver of an IMAP4 server must check the end of every
+   received line for an open brace ('{') followed by an octet count, a
+   plus ('+'), and a close brace ('}') immediately preceeding the CRLF.
+   If it finds this sequence, it is the octet count of a non-
+   synchronizing literal and the server MUST treat the specified number
+   of following octets and the following line as part of the same
+   command.  A server MAY still process commands and reject errors on a
+   line-by-line basis, as long as it checks for non-synchronizing
+   literals at the end of each line.
+
+   Example:    C: A001 LOGIN {11+}
+               C: FRED FOOBAR {7+}
+               C: fat man
+               S: A001 OK LOGIN completed
+
+4.   Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
+   Non-terminals referenced but not defined below are as defined by
+   [IMAP4].
+
+   literal         ::= "{" number ["+"] "}" CRLF *CHAR8
+                       ;; Number represents the number of CHAR8 octets
+
+6.   References
+
+   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
+   draft-crispin-imap-base-XX.txt, University of Washington, April 1996.
+
+   [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
+   Messages", STD 11, RFC 822.
+
+7.   Security Considerations
+
+   There are no known security issues with this extension.
+
+8.   Author's Address
+
+   John G. Myers
+   Carnegie-Mellon University
+   5000 Forbes Ave.
+   Pittsburgh PA, 15213-3890
+
+   Email: jgm+@cmu.edu
+
+
+
+Myers                       Standards Track                     [Page 2]
+
diff --git a/docs/rfcs/rfc2095.txt b/docs/rfcs/rfc2095.txt
new file mode 100644
index 0000000..f1167f6
--- /dev/null
+++ b/docs/rfcs/rfc2095.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                       J. Klensin
+Request for Comments: 2095                                    R. Catoe
+Category: Standards Track                                 P. Krumviede
+                                                                   MCI
+                                                          January 1997
+
+
+       IMAP/POP AUTHorize Extension for Simple Challenge/Response
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   While IMAP4 supports a number of strong authentication mechanisms as
+   described in RFC 1731, it lacks any mechanism that neither passes
+   cleartext, reusable passwords across the network nor requires either
+   a significant security infrastructure or that the mail server update
+   a mail-system-wide user authentication file on each mail access.
+   This specification provides a simple challenge-response
+   authentication protocol that is suitable for use with IMAP4.  Since
+   it utilizes Keyed-MD5 digests and does not require that the secret be
+   stored in the clear on the server, it may also constitute an
+   improvement on APOP for POP3 use as specified in RFC 1734.
+
+1. Introduction
+
+   Existing Proposed Standards specify an AUTHENTICATE mechanism for the
+   IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for
+   the POP3 protocol [POP3-AUTH].  The AUTHENTICATE mechanism is
+   intended to be extensible; the four methods specified in [IMAP-AUTH]
+   are all fairly powerful and require some security infrastructure to
+   support.  The base POP3 specification [POP3] also contains a
+   lightweight challenge-response mechanism called APOP.  APOP is
+   associated with most of the risks associated with such protocols: in
+   particular, it requires that both the client and server machines have
+   access to the shared secret in cleartext form. CRAM offers a method
+   for avoiding such cleartext storage while retaining the algorithmic
+   simplicity of APOP in using only MD5, though in a "keyed" method.
+
+
+
+
+
+
+
+Klensin, Catoe & Krumviede  Standards Track                     [Page 1]
+
+RFC 2095              IMAP/POP AUTHorize Extension          January 1997
+
+
+   At present, IMAP [IMAP] lacks any facility corresponding to APOP.
+   The only alternative to the strong mechanisms identified in [IMAP-
+   AUTH] is a presumably cleartext username and password, supported
+   through the LOGIN command in [IMAP].  This document describes a
+   simple challenge-response mechanism, similar to APOP and PPP CHAP
+   [PPP], that can be used with IMAP (and, in principle, with POP3).
+
+   This mechanism also has the advantage over some possible alternatives
+   of not requiring that the server maintain information about email
+   "logins" on a per-login basis.  While mechanisms that do require such
+   per-login history records may offer enhanced security, protocols such
+   as IMAP, which may have several connections between a given client
+   and server open more or less simultaneous, may make their
+   implementation particularly challenging.
+
+2. Challenge-Response Authentication Mechanism (CRAM)
+
+   The authentication type associated with CRAM is "CRAM-MD5".
+
+   The data encoded in the first ready response contains an
+   presumptively arbitrary string of random digits, a timestamp, and the
+   fully-qualified primary host name of the server.  The syntax of the
+   unencoded form must correspond to that of an RFC 822 'msg-id'
+   [RFC822] as described in [POP3].
+
+   The client makes note of the data and then responds with a string
+   consisting of the user name, a space, and a 'digest'.  The latter is
+   computed by applying the keyed MD5 algorithm from [KEYED-MD5] where
+   the key is a shared secret and the digested text is the timestamp
+   (including angle-brackets).
+
+   This shared secret is a string known only to the client and server.
+   The `digest' parameter itself is a 16-octet value which is sent in
+   hexadecimal format, using lower-case ASCII characters.
+
+   When the server receives this client response, it verifies the digest
+   provided.  If the digest is correct, the server should consider the
+   client authenticated and respond appropriately.
+
+   Keyed MD5 is chosen for this application because of the greater
+   security imparted to authentication of short messages. In addition,
+   the use of the techniques described in [KEYED-MD5] for precomputation
+   of intermediate results make it possible to avoid explicit cleartext
+   storage of the shared secret on the server system by instead storing
+   the intermediate results which are known as "contexts".
+
+
+
+
+
+
+Klensin, Catoe & Krumviede  Standards Track                     [Page 2]
+
+RFC 2095              IMAP/POP AUTHorize Extension          January 1997
+
+
+   CRAM does not support a protection mechanism.
+
+   Example:
+
+   The examples in this document show the use of the CRAM mechanism with
+   the IMAP4 AUTHENTICATE command [IMAP-AUTH].  The base64 encoding of
+   the challenges and responses is part of the IMAP4 AUTHENTICATE
+   command, not part of the CRAM specification itself.
+
+     S: * OK IMAP4 Server
+     C: A0001 AUTHENTICATE CRAM-MD5
+     S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
+     C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
+     S: A0001 OK CRAM authentication successful
+
+      In this example, the shared secret is the string
+      'tanstaaftanstaaf'.  Hence, the Keyed MD5 digest is produced by
+      calculating
+
+        MD5((tanstaaftanstaaf XOR opad),
+            MD5((tanstaaftanstaaf XOR ipad),
+            <1896.697170952@postoffice.reston.mci.net>))
+
+      where ipad and opad are as defined in the keyed-MD5 Work in
+      Progress [KEYED-MD5] and the string shown in the challenge is the
+      base64 encoding of <1896.697170952@postoffice.reston.mci.net>. The
+      shared secret is null-padded to a length of 64 bytes. If the
+      shared secret is longer than 64 bytes, the MD5 digest of the
+      shared secret is used as a 16 byte input to the keyed MD5
+      calculation.
+
+      This produces a digest value (in hexadecimal) of
+
+           b913a602c7eda7a495b4e6e7334d3890
+
+      The user name is then prepended to it, forming
+
+           tim b913a602c7eda7a495b4e6e7334d3890
+
+      Which is then base64 encoded to meet the requirements of the IMAP4
+      AUTHENTICATE command (or the similar POP3 AUTH command), yielding
+
+           dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
+
+
+
+
+
+
+
+
+Klensin, Catoe & Krumviede  Standards Track                     [Page 3]
+
+RFC 2095              IMAP/POP AUTHorize Extension          January 1997
+
+
+3. References
+
+   [CHAP]  Lloyd, B., and W. Simpson, "PPP Authentication Protocols",
+       RFC 1334, October 1992.
+
+   [IMAP] Crispin, M., "Internet Message Access Protocol - Version
+       4rev1", RFC 2060, University of Washington, December 1996.
+
+   [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms",
+       RFC 1731, Carnegie Mellon, December 1994.
+
+   [KEYED-MD5] Krawczyk, H., "HMAC-MD5: Keyed-MD5 for Message
+       Authentication", Work in Progess.
+
+   [MD5]  Rivest, R., "The MD5 Message Digest Algorithm",
+       RFC 1321, MIT Laboratory for Computer Science, April 1992.
+
+   [POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3",
+       STD 53, RFC 1939, Carnegie Mellon, May 1996.
+
+   [POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
+       Carnegie Mellon, December, 1994.
+
+4. Security Considerations
+
+   It is conjectured that use of the CRAM authentication mechanism
+   provides origin identification and replay protection for a session.
+   Accordingly, a server that implements both a cleartext password
+   command and this authentication type should not allow both methods of
+   access for a given user.
+
+   While the saving, on the server, of "contexts" (see section 2) is
+   marginally better than saving the shared secrets in cleartext as is
+   required by CHAP [CHAP] and APOP [POP3], it is not sufficient to
+   protect the secrets if the server itself is compromised.
+   Consequently, servers that store the secrets or contexts must both be
+   protected to a level appropriate to the potential information value
+   in user mailboxes and identities.
+
+   As the length of the shared secret increases, so does the difficulty
+   of deriving it.
+
+   While there are now suggestions in the literature that the use of MD5
+   and keyed MD5 in authentication procedures probably has a limited
+   effective lifetime, the technique is now widely deployed and widely
+   understood.  It is believed that this general understanding may
+   assist with the rapid replacement, by CRAM-MD5, of the current uses
+   of permanent cleartext passwords in IMAP.   This document has been
+
+
+
+Klensin, Catoe & Krumviede  Standards Track                     [Page 4]
+
+RFC 2095              IMAP/POP AUTHorize Extension          January 1997
+
+
+   deliberately written to permit easy upgrading to use SHA (or whatever
+   alternatives emerge) when they are considered to be widely available
+   and adequately safe.
+
+   Even with the use of CRAM, users are still vulnerable to active
+   attacks.  An example of an increasingly common active attack is 'TCP
+   Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95].
+
+   See section 1 above for additional discussion.
+
+5. Acknowledgements
+
+   This memo borrows ideas and some text liberally from [POP3] and
+   [RFC-1731] and thanks are due the authors of those documents.  Ran
+   Atkinson made a number of valuable technical and editorial
+   contributions to the document.
+
+6. Authors' Addresses
+
+   John C. Klensin
+   MCI Telecommunications
+   800 Boylston St, 7th floor
+   Boston, MA 02199
+   USA
+
+   EMail: klensin@mci.net
+   Phone: +1 617 960 1011
+
+   Randy Catoe
+   MCI Telecommunications
+   2100 Reston Parkway
+   Reston, VA 22091
+   USA
+
+   EMail: randy@mci.net
+   Phone: +1 703 715 7366
+
+   Paul Krumviede
+   MCI Telecommunications
+   2100 Reston Parkway
+   Reston, VA 22091
+   USA
+
+   EMail: paul@mci.net
+   Phone: +1 703 715 7251
+
+
+
+
+
+
+Klensin, Catoe & Krumviede  Standards Track                     [Page 5]
+
diff --git a/docs/rfcs/rfc2177.txt b/docs/rfcs/rfc2177.txt
new file mode 100644
index 0000000..c11c765
--- /dev/null
+++ b/docs/rfcs/rfc2177.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                           B. Leiba
+Request for Comments: 2177               IBM T.J. Watson Research Center
+Category: Standards Track                                      June 1997
+
+
+                           IMAP4 IDLE command
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+1.   Abstract
+
+   The Internet Message Access Protocol [IMAP4] requires a client to
+   poll the server for changes to the selected mailbox (new mail,
+   deletions).  It's often more desirable to have the server transmit
+   updates to the client in real time.  This allows a user to see new
+   mail immediately.  It also helps some real-time applications based on
+   IMAP, which might otherwise need to poll extremely often (such as
+   every few seconds).  (While the spec actually does allow a server to
+   push EXISTS responses aysynchronously, a client can't expect this
+   behaviour and must poll.)
+
+   This document specifies the syntax of an IDLE command, which will
+   allow a client to tell the server that it's ready to accept such
+   real-time updates.
+
+2.   Conventions Used in this Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+   in this document are to be interpreted as described in RFC 2060
+   [IMAP4].
+
+3.   Specification
+
+   IDLE Command
+
+   Arguments:  none
+
+   Responses:  continuation data will be requested; the client sends
+               the continuation data "DONE" to end the command
+
+
+
+Leiba                       Standards Track                     [Page 1]
+
+RFC 2177                   IMAP4 IDLE command                  June 1997
+
+
+
+   Result:     OK - IDLE completed after client sent "DONE"
+               NO - failure: the server will not allow the IDLE
+                    command at this time
+              BAD - command unknown or arguments invalid
+
+   The IDLE command may be used with any IMAP4 server implementation
+   that returns "IDLE" as one of the supported capabilities to the
+   CAPABILITY command.  If the server does not advertise the IDLE
+   capability, the client MUST NOT use the IDLE command and must poll
+   for mailbox updates.  In particular, the client MUST continue to be
+   able to accept unsolicited untagged responses to ANY command, as
+   specified in the base IMAP specification.
+
+   The IDLE command is sent from the client to the server when the
+   client is ready to accept unsolicited mailbox update messages.  The
+   server requests a response to the IDLE command using the continuation
+   ("+") response.  The IDLE command remains active until the client
+   responds to the continuation, and as long as an IDLE command is
+   active, the server is now free to send untagged EXISTS, EXPUNGE, and
+   other messages at any time.
+
+   The IDLE command is terminated by the receipt of a "DONE"
+   continuation from the client; such response satisfies the server's
+   continuation request.  At that point, the server MAY send any
+   remaining queued untagged responses and then MUST immediately send
+   the tagged response to the IDLE command and prepare to process other
+   commands. As in the base specification, the processing of any new
+   command may cause the sending of unsolicited untagged responses,
+   subject to the ambiguity limitations.  The client MUST NOT send a
+   command while the server is waiting for the DONE, since the server
+   will not be able to distinguish a command from a continuation.
+
+   The server MAY consider a client inactive if it has an IDLE command
+   running, and if such a server has an inactivity timeout it MAY log
+   the client off implicitly at the end of its timeout period.  Because
+   of that, clients using IDLE are advised to terminate the IDLE and
+   re-issue it at least every 29 minutes to avoid being logged off.
+   This still allows a client to receive immediate mailbox updates even
+   though it need only "poll" at half hour intervals.
+
+
+
+
+
+
+
+
+
+
+
+Leiba                       Standards Track                     [Page 2]
+
+RFC 2177                   IMAP4 IDLE command                  June 1997
+
+
+   Example:    C: A001 SELECT INBOX
+               S: * FLAGS (Deleted Seen)
+               S: * 3 EXISTS
+               S: * 0 RECENT
+               S: * OK [UIDVALIDITY 1]
+               S: A001 OK SELECT completed
+               C: A002 IDLE
+               S: + idling
+               ...time passes; new mail arrives...
+               S: * 4 EXISTS
+               C: DONE
+               S: A002 OK IDLE terminated
+               ...another client expunges message 2 now...
+               C: A003 FETCH 4 ALL
+               S: * 4 FETCH (...)
+               S: A003 OK FETCH completed
+               C: A004 IDLE
+               S: * 2 EXPUNGE
+               S: * 3 EXISTS
+               S: + idling
+               ...time passes; another client expunges message 3...
+               S: * 3 EXPUNGE
+               S: * 2 EXISTS
+               ...time passes; new mail arrives...
+               S: * 3 EXISTS
+               C: DONE
+               S: A004 OK IDLE terminated
+               C: A005 FETCH 3 ALL
+               S: * 3 FETCH (...)
+               S: A005 OK FETCH completed
+               C: A006 IDLE
+
+4.   Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
+   Non-terminals referenced but not defined below are as defined by
+   [IMAP4].
+
+   command_auth    ::= append / create / delete / examine / list / lsub /
+                       rename / select / status / subscribe / unsubscribe
+                       / idle
+                       ;; Valid only in Authenticated or Selected state
+
+   idle            ::= "IDLE" CRLF "DONE"
+
+
+
+
+
+
+Leiba                       Standards Track                     [Page 3]
+
+RFC 2177                   IMAP4 IDLE command                  June 1997
+
+
+5.   References
+
+   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
+   4rev1", RFC 2060, December 1996.
+
+6.   Security Considerations
+
+   There are no known security issues with this extension.
+
+7.   Author's Address
+
+   Barry Leiba
+   IBM T.J. Watson Research Center
+   30 Saw Mill River Road
+   Hawthorne, NY  10532
+
+   Email: leiba@watson.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Leiba                       Standards Track                     [Page 4]
+
diff --git a/docs/rfcs/rfc2180.txt b/docs/rfcs/rfc2180.txt
new file mode 100644
index 0000000..5760700
--- /dev/null
+++ b/docs/rfcs/rfc2180.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                          M. Gahrns
+Request for Comments: 2180                                     Microsoft
+Category: Informational                                        July 1997
+
+
+                 IMAP4 Multi-Accessed Mailbox Practice
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+1. Abstract
+
+   IMAP4[RFC-2060] is rich client/server protocol that allows a client
+   to access and manipulate electronic mail messages on a server.
+   Within the protocol framework, it is possible to have differing
+   results for particular client/server interactions. If a protocol does
+   not allow for this, it is often unduly restrictive.
+
+   For example, when multiple clients are accessing a mailbox and one
+   attempts to delete the mailbox, an IMAP4 server may choose to
+   implement a solution based upon server architectural constraints or
+   individual preference.
+
+   With this flexibility comes greater client responsibility.  It is not
+   sufficient for a client to be written based upon the behavior of a
+   particular IMAP server.  Rather the client must be based upon the
+   behavior allowed by the protocol.
+
+   By documenting common IMAP4 server practice for the case of
+   simultaneous client access to a mailbox, we hope to ensure the widest
+   amount of inter-operation between IMAP4 clients and servers.
+
+   The behavior described in this document reflects the practice of some
+   existing servers or behavior that the consensus of the IMAP mailing
+   list has deemed to be reasonable.  The behavior described within this
+   document is believed to be [RFC-2060] compliant. However, this
+   document is not meant to define IMAP4 compliance, nor is it an
+   exhaustive list of valid IMAP4 behavior. [RFC-2060] must always be
+   consulted to determine IMAP4 compliance, especially for server
+   behavior not described within this document.
+
+
+
+
+
+
+
+
+Gahrns                       Informational                      [Page 1]
+
+RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
+
+
+2. Conventions used in this document
+
+   In examples,"C1:", "C2:" and "C3:" indicate lines sent by 3 different
+   clients (client #1, client #2 and client #3) that are connected to a
+   server.  "S1:", "S2:" and "S3:" indicated lines sent by the server to
+   client #1, client #2 and client #3 respectively.
+
+   A shared mailbox, is a mailbox that can be used by multiple users.
+
+   A multi-accessed mailbox, is a mailbox that has multiple clients
+   simultaneously accessing it.
+
+   A client is said to have accessed a mailbox after a successful SELECT
+   or EXAMINE command.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC-2119].
+
+
+3. Deletion/Renaming of a multi-accessed mailbox
+
+   If an external agent or multiple clients are accessing a mailbox,
+   care must be taken when handling the deletion or renaming of the
+   mailbox. Following are some strategies an IMAP server may choose to
+   use when dealing with this situation.
+
+
+3.1. The server MAY fail the DELETE/RENAME command of a multi-accessed
+     mailbox
+
+   In some cases, this behavior may not be practical.  For example, if a
+   large number of clients are accessing a shared mailbox, the window in
+   which no clients have the mailbox accessed may be small or non-
+   existent, effectively rendering the mailbox undeletable or
+   unrenamable.
+
+   Example:
+
+   <Client #1 and Client #2 have mailbox FOO accessed. Client #1 tries
+   to DELETE the mailbox and is refused>
+
+             C1: A001 DELETE FOO
+             S1: A001 NO Mailbox FOO is in use by another user.
+
+
+
+
+
+
+
+Gahrns                       Informational                      [Page 2]
+
+RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
+
+
+3.2. The server MAY allow the DELETE command of a multi-accessed
+     mailbox, but keep the information in the mailbox available for
+     those clients that currently have access to the mailbox.
+
+   When all clients have finished accessing the mailbox, it is
+   permanently removed.  For clients that do not already have access to
+   the mailbox, the 'ghosted' mailbox would not be available.  For
+   example, it would not be returned to these clients in a subsequent
+   LIST or LSUB command and would not be a valid mailbox argument to any
+   other IMAP command until the reference count of clients accessing the
+   mailbox reached 0.
+
+   In some cases, this behavior may not be desirable. For example if
+   someone created a mailbox with offensive or sensitive information,
+   one might prefer to have the mailbox deleted and all access to the
+   information contained within removed immediately, rather than
+   continuing to allow access until the client closes the mailbox.
+
+   Furthermore, this behavior, may prevent 'recycling' of the same
+   mailbox name until all clients have finished accessing the original
+   mailbox.
+
+   Example:
+
+   <Client #1 and Client #2 have mailbox FOO selected. Client #1 DELETEs
+   mailbox FOO>
+
+             C1: A001 DELETE FOO
+             S1: A001 OK Mailbox FOO is deleted.
+
+   <Client #2 is still able to operate on the deleted mailbox>
+
+             C2: B001 STORE 1 +FLAGS (\Seen)
+             S2: * 1 FETCH FLAGS (\Seen)
+             S2: B001 OK STORE completed
+
+   <Client #3 which did not have access to the mailbox prior to the
+   deletion by client #1 does not have access to the mailbox>
+
+             C3: C001 STATUS FOO (MESSAGES)
+             S3: C001 NO Mailbox does not exist
+
+   <Nor is client #3 able to create a mailbox with the name FOO, while
+   the reference count is non zero>
+
+             C3: C002 CREATE FOO
+             S3: C002 NO Mailbox FOO is still in use. Try again later.
+
+
+
+
+Gahrns                       Informational                      [Page 3]
+
+RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
+
+
+   <Client #2 closes its access to the mailbox, no other clients have
+   access to the mailbox FOO and reference count becomes 0>
+
+             C2: B002 CLOSE
+             S2: B002 OK CLOSE Completed
+
+   <Now that the reference count on FOO has reached 0, the mailbox name
+   can be recycled>
+
+             C3: C003 CREATE FOO
+             S3: C003 OK CREATE Completed
+
+
+3.3. The server MAY allow the DELETE/RENAME of a multi-accessed
+     mailbox, but disconnect all other clients who have the mailbox
+     accessed by sending a untagged BYE response.
+
+   A server may often choose to disconnect clients in the DELETE case,
+   but may choose to implement a "friendlier" method for the RENAME
+   case.
+
+   Example:
+
+   <Client #1 and Client #2 have mailbox FOO accessed. Client #1 DELETEs
+   the mailbox FOO>
+
+             C1: A002 DELETE FOO
+             S1: A002 OK DELETE completed.
+
+   <Server disconnects all other users of the mailbox>
+             S2: * BYE Mailbox FOO has been deleted.
+
+
+3.4. The server MAY allow the RENAME of a multi-accessed mailbox by
+     simply changing the name attribute on the mailbox.
+
+   Other clients that have access to the mailbox can continue issuing
+   commands such as FETCH that do not reference the mailbox name.
+   Clients would discover the renaming the next time they referred to
+   the old mailbox name.  Some servers MAY choose to include the
+   [NEWNAME] response code in their tagged NO response to a command that
+   contained the old mailbox name, as a hint to the client that the
+   operation can succeed if the command is issued with the new mailbox
+   name.
+
+
+
+
+
+
+
+Gahrns                       Informational                      [Page 4]
+
+RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
+
+
+   Example:
+
+   <Client #1 and Client #2 have mailbox FOO accessed. Client #1 RENAMEs
+   the mailbox.>
+
+             C1: A001 RENAME FOO BAR
+             S1: A001 OK RENAME completed.
+
+   <Client #2 is still able to do operations that do not reference the
+   mailbox name>
+
+             C2: B001 FETCH 2:4 (FLAGS)
+             S2: * 2 FETCH . . .
+             S2: * 3 FETCH . . .
+             S2: * 4 FETCH . . .
+             S2: B001 OK FETCH completed
+
+   <Client #2 is not able to do operations that reference the mailbox
+   name>
+
+             C2: B002 APPEND FOO {300} C2: Date: Mon, 7 Feb 1994
+             21:52:25 0800 (PST) C2: . . .  S2: B002 NO [NEWNAME FOO
+             BAR] Mailbox has been renamed
+
+
+4. Expunging of messages on a multi-accessed mailbox
+
+   If an external agent or multiple clients are accessing a mailbox,
+   care must be taken when handling the EXPUNGE of messages.  Other
+   clients accessing the mailbox may be in the midst of issuing a
+   command that depends upon message sequence numbers.  Because an
+   EXPUNGE response can not be sent while responding to a FETCH, STORE
+   or SEARCH command, it is not possible to immediately notify the
+   client of the EXPUNGE.  This can result in ambiguity if the client
+   issues a FETCH, STORE or SEARCH operation on a message that has been
+   EXPUNGED.
+
+
+4.1. Fetching of expunged messages
+
+   Following are some strategies an IMAP server may choose to use when
+   dealing with a FETCH command on expunged messages.
+
+
+
+
+
+
+
+
+
+Gahrns                       Informational                      [Page 5]
+
+RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
+
+
+   Consider the following scenario:
+
+   - Client #1 and Client #2 have mailbox FOO selected.
+   - There are 7 messages in the mailbox.
+   - Messages 4:7 are marked for deletion.
+   - Client #1 issues an EXPUNGE, to expunge messages 4:7
+
+
+4.1.1. The server MAY allow the EXPUNGE of a multi-accessed mailbox but
+       keep the messages available to satisfy subsequent FETCH commands
+       until it is able to send an EXPUNGE response to each client.
+
+   In some cases, the behavior of keeping "ghosted" messages may not be
+   desirable.  For example if a message contained offensive or sensitive
+   information, one might prefer to instantaneously remove all access to
+   the information, regardless of whether another client is in the midst
+   of accessing it.
+
+   Example:  (Building upon the scenario outlined in 4.1.)
+
+   <Client #2 is still able to access the expunged messages because the
+   server has kept a 'ghosted' copy of the messages until it is able to
+   notify client #2 of the EXPUNGE>
+
+             C2: B001 FETCH 4:7 RFC822
+             S2: * 4 FETCH RFC822 . . . (RFC822 info returned)
+             S2: * 5 FETCH RFC822 . . . (RFC822 info returned)
+             S2: * 6 FETCH RFC822 . . . (RFC822 info returned)
+             S2: * 7 FETCH RFC822 . . . (RFC822 info returned)
+             S2: B001 OK FETCH Completed
+
+   <Client #2 issues a command where it can get notified of the EXPUNGE>
+
+             C2: B002 NOOP
+             S2: * 4 EXPUNGE
+             S2: * 4 EXPUNGE
+             S2: * 4 EXPUNGE
+             S2: * 4 EXPUNGE
+             S2: * 3 EXISTS
+             S2: B002 OK NOOP Complete
+
+   <Client #2 no longer has access to the expunged messages>
+
+             C2: B003 FETCH 4:7 RFC822
+             S2: B003 NO Messages 4:7 are no longer available.
+
+
+
+
+
+
+Gahrns                       Informational                      [Page 6]
+
+RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
+
+
+4.1.2 The server MAY allow the EXPUNGE of a multi-accessed mailbox,
+      and on subsequent FETCH commands return FETCH responses only for
+      non-expunged messages and a tagged NO.
+
+   After receiving a tagged NO FETCH response, the client SHOULD issue a
+   NOOP command so that it will be informed of any pending EXPUNGE
+   responses.  The client may then either reissue the failed FETCH
+   command, or by examining the EXPUNGE response from the NOOP and the
+   FETCH response from the FETCH, determine that the FETCH failed
+   because of pending expunges.
+
+   Example:  (Building upon the scenario outlined in 4.1.)
+
+   <Client #2 attempts to FETCH a mix of expunged and non-expunged
+   messages.  A FETCH response is returned only for then non-expunged
+   messages along with a tagged NO>
+
+             C2: B001 FETCH 3:5 ENVELOPE
+             S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)
+             S2: B001 NO Some of the requested messages no longer exist
+
+   <Upon receiving a tagged NO FETCH response, Client #2 issues a NOOP
+   to be informed of any pending EXPUNGE responses>
+
+             C2: B002 NOOP
+             S2: * 4 EXPUNGE
+             S2: * 4 EXPUNGE
+             S2: * 4 EXPUNGE
+             S2: * 4 EXPUNGE
+             S2: * 3 EXISTS
+             S2: B002 OK NOOP Completed.
+
+   <By receiving a FETCH response for message 3, and an EXPUNGE response
+   that indicates messages 4:7 have been expunged, the client does not
+   need to re-issue the FETCH>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gahrns                       Informational                      [Page 7]
+
+RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
+
+
+4.1.3 The server MAY allow the EXPUNGE of a multi-accessed mailbox, and
+      on subsequent FETCH commands return the usual FETCH responses for
+      non-expunged messages, "NIL FETCH Responses" for expunged
+      messages, and a tagged OK response.
+
+   If all of the messages in the subsequent FETCH command have been
+   expunged, the server SHOULD return only a tagged NO.  In this case,
+   the client SHOULD issue a NOOP command so that it will be informed of
+   any pending EXPUNGE responses.  The client may then either reissue
+   the failed FETCH command, or by examining the EXPUNGE response from
+   the NOOP, determine that the FETCH failed because of pending
+   expunges.
+
+   "NIL FETCH responses" are a representation of empty data as
+   appropriate for the FETCH argument specified.
+
+   Example:
+
+   * 1 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL))
+   * 1 FETCH (FLAGS ())
+   * 1 FETCH (INTERNALDATE "00-Jan-0000 00:00:00 +0000")
+   * 1 FETCH (RFC822 "")
+   * 1 FETCH (RFC822.HEADER "")
+   * 1 FETCH (RFC822.TEXT "")
+   * 1 FETCH (RFC822.SIZE 0)
+   * 1 FETCH (BODY ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
+   * 1 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
+   * 1 FETCH (BODY[<section>] "")
+   * 1 FETCH (BODY[<section>]<partial> "")
+
+   In some cases, a client may not be able to distinguish between "NIL
+   FETCH responses" received because a message was expunged and those
+   received because the data actually was NIL.  For example, a  * 5
+   FETCH (FLAGS ()) response could be received if no flags were set on
+   message 5, or because message 5 was expunged. In a case of potential
+   ambiguity, the client SHOULD issue a command such as NOOP to force
+   the sending of the EXPUNGE responses to resolve any ambiguity.
+
+   Example:  (Building upon the scenario outlined in 4.1.)
+
+   <Client #2 attempts to access a mix of expunged and non-expunged
+   messages.  Normal data is returned for non-expunged message, "NIL
+   FETCH responses" are returned for expunged messages>
+
+
+
+
+
+
+
+
+Gahrns                       Informational                      [Page 8]
+
+RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
+
+
+             C2: B002 FETCH 3:5 ENVELOPE
+             S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)
+             S2: * 4 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL
+                   NIL NIL)
+             S2: * 5 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL
+                   NIL NIL)
+             S2: B002 OK FETCH Completed
+
+   <Client #2 attempts to FETCH only expunged messages and receives a
+   tagged NO response>
+
+             C2: B002 FETCH 4:7 ENVELOPE
+             S2: B002 NO Messages 4:7 have been expunged.
+
+
+4.1.4 To avoid the situation altogether, the server MAY fail the
+      EXPUNGE of a multi-accessed mailbox
+
+   In some cases, this behavior may not be practical.  For example, if a
+   large number of clients are accessing a shared mailbox, the window in
+   which no clients have the mailbox accessed may be small or non-
+   existent, effectively rendering the message unexpungeable.
+
+
+4.2. Storing of expunged messages
+
+   Following are some strategies an IMAP server may choose to use when
+   dealing with a STORE command on expunged messages.
+
+
+4.2.1 If the ".SILENT" suffix is used, and the STORE completed
+      successfully for all the non-expunged messages, the server SHOULD
+      return a tagged OK.
+
+   Example:  (Building upon the scenario outlined in 4.1.)
+
+   <Client #2 tries to silently STORE flags on expunged and non-
+   expunged messages.  The server sets the flags on the non-expunged
+   messages and returns OK>
+
+             C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN)
+             S2: B001 OK
+
+
+
+
+
+
+
+
+
+Gahrns                       Informational                      [Page 9]
+
+RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
+
+
+4.2.2. If the ".SILENT" suffix is not used, and only expunged messages
+       are referenced, the server SHOULD return only a tagged NO.
+
+   Example:  (Building upon the scenario outlined in 4.1.)
+
+   <Client #2 tries to STORE flags only on expunged messages>
+
+             C2: B001 STORE 5:7 +FLAGS (\SEEN)
+             S2: B001 NO  Messages have been expunged
+
+
+4.2.3. If the ".SILENT" suffix is not used, and a mixture of expunged
+       and non-expunged messages are referenced, the server MAY set the
+       flags and return a FETCH response for the non-expunged messages
+       along with a tagged NO.
+
+   After receiving a tagged NO STORE response, the client SHOULD issue a
+   NOOP command so that it will be informed of any pending EXPUNGE
+   responses.  The client may then either reissue the failed STORE
+   command, or by examining the EXPUNGE responses from the NOOP and
+   FETCH responses from the STORE, determine that the STORE failed
+   because of pending expunges.
+
+   Example:  (Building upon the scenario outlined in 4.1.)
+
+   <Client #2 tries to STORE flags on a mixture of expunged and non-
+   expunged messages>
+
+             C2: B001 STORE 1:7 +FLAGS (\SEEN)
+             S2: * FETCH 1 FLAGS (\SEEN)
+             S2: * FETCH 2 FLAGS (\SEEN)
+             S2: * FETCH 3 FLAGS (\SEEN)
+             S2: B001 NO Some of the messages no longer exist.
+
+             C2: B002 NOOP
+             S2: * 4 EXPUNGE
+             S2: * 4 EXPUNGE
+             S2: * 4 EXPUNGE
+             S2: * 4 EXPUNGE
+             S2: * 3 EXISTS
+             S2: B002 OK NOOP Completed.
+
+   <By receiving FETCH responses for messages 1:3, and an EXPUNGE
+   response that indicates messages 4:7 have been expunged, the client
+   does not need to re-issue the STORE>
+
+
+
+
+
+
+Gahrns                       Informational                     [Page 10]
+
+RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
+
+
+4.2.4. If the ".SILENT" suffix is not used, and a mixture of expunged
+       and non-expunged messages are referenced, the server MAY return
+       an untagged NO and not set any flags.
+
+   After receiving a tagged NO STORE response, the client SHOULD issue a
+   NOOP command so that it will be informed of any pending EXPUNGE
+   responses.  The client would then re-issue the STORE command after
+   updating its message list per any EXPUNGE response.
+
+   If a large number of clients are accessing a shared mailbox, the
+   window in which there are no pending expunges may be small or non-
+   existent, effectively disallowing a client from setting the flags on
+   all messages at once.
+
+   Example:  (Building upon the scenario outlined in 4.1.)
+
+   <Client #2 tries to STORE flags on a mixture of expunged and non-
+   expunged messages>
+
+             C2: B001 STORE 1:7 +FLAGS (\SEEN)
+             S2: B001 NO  Some of the messages no longer exist.
+
+   <Client #2 issues a NOOP to be informed of the EXPUNGED messages>
+
+             C2: B002 NOOP
+             S2: * 4 EXPUNGE
+             S2: * 4 EXPUNGE
+             S2: * 4 EXPUNGE
+             S2: * 4 EXPUNGE
+             S2: * 3 EXISTS
+             S2: B002 OK NOOP Completed.
+
+   <Client #2 updates its message list and re-issues the STORE on only
+   those messages that have not been expunged>
+
+             C2: B003 STORE 1:3 +FLAGS (\SEEN) S2: * FETCH 1 FLAGS
+             (\SEEN) S2: * FETCH 2 FLAGS (\SEEN) S2: * FETCH 3 FLAGS
+             (\SEEN) S2: B003 OK  STORE Completed
+
+
+4.3. Searching of expunged messages
+
+   A server MAY simply not return a search response for messages that
+   have been expunged and it has not been able to inform the client
+   about.  If a client was expecting a particular message to be returned
+   in a search result, and it was not, the client SHOULD issue a NOOP
+   command to see if the message was expunged by another client.
+
+
+
+
+Gahrns                       Informational                     [Page 11]
+
+RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
+
+
+4.4 Copying of expunged messages
+
+   COPY is the only IMAP4 sequence number command that is safe to allow
+   an EXPUNGE response on.  This is because a client is not permitted to
+   cascade several COPY commands together. A client is required to wait
+   and confirm that the copy worked before issuing another one.
+
+4.4.1 The server MAY disallow the COPY of messages in a multi-access
+      mailbox that contains expunged messages.
+
+   Pending EXPUNGE response(s) MUST be returned to the COPY command.
+
+   Example:
+
+             C: A001 COPY 2,4,6,8 FRED
+             S: * 4 EXPUNGE
+             S: A001 NO COPY rejected, because some of the requested
+                messages were expunged
+
+   Note: Non of the above messages are copied because if a COPY command
+   is unsuccessful, the server MUST restore the destination mailbox to
+   its state before the COPY attempt.
+
+
+4.4.2 The server MAY allow the COPY of messages in a multi-access
+      mailbox that contains expunged messages.
+
+   Pending EXPUNGE response(s) MUST be returned to the COPY command.
+   Messages that are copied are messages corresponding to sequence
+   numbers before any EXPUNGE response.
+
+   Example:
+
+             C: A001 COPY 2,4,6,8 FRED
+             S: * 3 EXPUNGE
+             S: A001 OK COPY completed
+
+   In the above example, the messages that are copied to FRED are
+   messages 2,4,6,8 at the start of the COPY command.  These are
+   equivalent to messages 2,3,5,7 at the end of the COPY command.  The
+   EXPUNGE response can't take place until after the messages from the
+   COPY command are identified (because of the "no expunge while no
+   commands in progress" rule).
+
+
+
+
+
+
+
+
+Gahrns                       Informational                     [Page 12]
+
+RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
+
+
+   Example:
+
+             C: A001 COPY 2,4,6,8 FRED
+             S: * 4 EXPUNGE
+             S: A001 OK COPY completed
+
+   In the above example, message 4 was copied before it was expunged,
+   and MUST appear in the destination mailbox FRED.
+
+
+5. Security Considerations
+
+   This document describes behavior of servers that use the IMAP4
+   protocol, and as such, has the same security considerations as
+   described in [RFC-2060].
+
+   In particular, some described server behavior does not allow for the
+   immediate deletion of information when a mailbox is accessed by
+   multiple clients.  This may be a consideration when dealing with
+   sensitive information where immediate deletion would be preferred.
+
+
+6. References
+
+   [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
+   4rev1", RFC 2060, University of Washington, December 1996.
+
+   [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
+   Requirement Levels", RFC 2119, Harvard University, March 1997.
+
+
+7.  Acknowledgments
+
+   This document is the result of discussions on the IMAP4 mailing list
+   and is meant to reflect consensus of this group.  In particular,
+   Raymond Cheng, Mark Crispin, Jim Evans, Erik Forsberg, Steve Hole,
+   Mark Keasling, Barry Leiba, Syd Logan, John Mani, Pat Moran, Larry
+   Osterman, Chris Newman, Bart Schaefer, Vladimir Vulovic, and Jack De
+   Winter were active participants in this discussion or made
+   suggestions to this document.
+
+
+
+
+
+
+
+
+
+
+
+Gahrns                       Informational                     [Page 13]
+
+RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
+
+
+8. Author's Address
+
+   Mike Gahrns
+   Microsoft
+   One Microsoft Way
+   Redmond, WA, 98072
+
+   Phone: (206) 936-9833
+   EMail: mikega@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gahrns                       Informational                     [Page 14]
+
diff --git a/docs/rfcs/rfc2192.txt b/docs/rfcs/rfc2192.txt
new file mode 100644
index 0000000..1b5a1d4
--- /dev/null
+++ b/docs/rfcs/rfc2192.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                          C. Newman
+Request for Comments: 2192                                      Innosoft
+Category: Standards Track                                 September 1997
+
+
+                            IMAP URL Scheme
+
+
+Status of this memo
+
+     This document specifies an Internet standards track protocol for
+     the Internet community, and requests discussion and suggestions for
+     improvements.  Please refer to the current edition of the "Internet
+     Official Protocol Standards" (STD 1) for the standardization state
+     and status of this protocol.  Distribution of this memo is
+     unlimited.
+
+
+Abstract
+
+     IMAP [IMAP4] is a rich protocol for accessing remote message
+     stores.  It provides an ideal mechanism for accessing public
+     mailing list archives as well as private and shared message stores.
+     This document defines a URL scheme for referencing objects on an
+     IMAP server.
+
+
+1. Conventions used in this document
+
+     The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+     in this document are to be interpreted as defined in "Key words for
+     use in RFCs to Indicate Requirement Levels" [KEYWORDS].
+
+
+2. IMAP scheme
+
+     The IMAP URL scheme is used to designate IMAP servers, mailboxes,
+     messages, MIME bodies [MIME], and search programs on Internet hosts
+     accessible using the IMAP protocol.
+
+     The IMAP URL follows the common Internet scheme syntax as defined
+     in RFC 1738 [BASIC-URL] except that clear text passwords are not
+     permitted.  If :<port> is omitted, the port defaults to 143.
+
+
+
+
+
+
+
+
+Newman                      Standards Track                     [Page 1]
+
+RFC 2192                    IMAP URL Scheme               September 1997
+
+
+     An IMAP URL takes one of the following forms:
+
+         imap://<iserver>/
+         imap://<iserver>/<enc_list_mailbox>;TYPE=<list_type>
+         imap://<iserver>/<enc_mailbox>[uidvalidity][?<enc_search>]
+         imap://<iserver>/<enc_mailbox>[uidvalidity]<iuid>[isection]
+
+     The first form is used to refer to an IMAP server, the second form
+     refers to a list of mailboxes, the third form refers to the
+     contents of a mailbox or a set of messages resulting from a search,
+     and the final form refers to a specific message or message part.
+     Note that the syntax here is informal.  The authoritative formal
+     syntax for IMAP URLs is defined in section 11.
+
+
+3. IMAP User Name and Authentication Mechanism
+
+     A user name and/or authentication mechanism may be supplied.  They
+     are used in the "LOGIN" or "AUTHENTICATE" commands after making the
+     connection to the IMAP server.  If no user name or authentication
+     mechanism is supplied, the user name "anonymous" is used with the
+     "LOGIN" command and the password is supplied as the Internet e-mail
+     address of the end user accessing the resource.  If the URL doesn't
+     supply a user name, the program interpreting the IMAP URL SHOULD
+     request one from the user if necessary.
+
+     An authentication mechanism can be expressed by adding
+     ";AUTH=<enc_auth_type>" to the end of the user name.  When such an
+     <enc_auth_type> is indicated, the client SHOULD request appropriate
+     credentials from that mechanism and use the "AUTHENTICATE" command
+     instead of the "LOGIN" command.  If no user name is specified, one
+     SHOULD be obtained from the mechanism or requested from the user as
+     appropriate.
+
+     The string ";AUTH=*" indicates that the client SHOULD select an
+     appropriate authentication mechanism.  It MAY use any mechanism
+     listed in the CAPABILITY command or use an out of band security
+     service resulting in a PREAUTH connection.  If no user name is
+     specified and no appropriate authentication mechanisms are
+     available, the client SHOULD fall back to anonymous login as
+     described above.  This allows a URL which grants read-write access
+     to authorized users, and read-only anonymous access to other users.
+
+     If a user name is included with no authentication mechanism, then
+     ";AUTH=*" is assumed.
+
+
+
+
+
+
+Newman                      Standards Track                     [Page 2]
+
+RFC 2192                    IMAP URL Scheme               September 1997
+
+
+     Since URLs can easily come from untrusted sources, care must be
+     taken when resolving a URL which requires or requests any sort of
+     authentication.  If authentication credentials are supplied to the
+     wrong server, it may compromise the security of the user's account.
+     The program resolving the URL should make sure it meets at least
+     one of the following criteria in this case:
+
+     (1) The URL comes from a trusted source, such as a referral server
+     which the client has validated and trusts according to site policy.
+     Note that user entry of the URL may or may not count as a trusted
+     source, depending on the experience level of the user and site
+     policy.
+     (2) Explicit local site policy permits the client to connect to the
+     server in the URL.  For example, if the client knows the site
+     domain name, site policy may dictate that any hostname ending in
+     that domain is trusted.
+     (3) The user confirms that connecting to that domain name with the
+     specified credentials and/or mechanism is permitted.
+     (4) A mechanism is used which validates the server before passing
+     potentially compromising client credentials.
+     (5) An authentication mechanism is used which will not reveal
+     information to the server which could be used to compromise future
+     connections.
+
+     URLs which do not include a user name must be treated with extra
+     care, since they are more likely to compromise the user's primary
+     account.  A URL containing ";AUTH=*" must also be treated with
+     extra care since it might fall back on a weaker security mechanism.
+     Finally, clients are discouraged from using a plain text password
+     as a fallback with ";AUTH=*" unless the connection has strong
+     encryption (e.g. a key length of greater than 56 bits).
+
+     A program interpreting IMAP URLs MAY cache open connections to an
+     IMAP server for later re-use.  If a URL contains a user name, only
+     connections authenticated as that user may be re-used.  If a URL
+     does not contain a user name or authentication mechanism, then only
+     an anonymous connection may be re-used.  If a URL contains an
+     authentication mechanism without a user name, then any non-
+     anonymous connection may be re-used.
+
+     Note that if unsafe or reserved characters such as " " or ";" are
+     present in the user name or authentication mechanism, they MUST be
+     encoded as described in RFC 1738 [BASIC-URL].
+
+
+
+
+
+
+
+
+Newman                   Standards Track                        [Page 3]
+
+RFC 2192                    IMAP URL Scheme               September 1997
+
+
+4. IMAP server
+
+     An IMAP URL referring to an IMAP server has the following form:
+
+         imap://<iserver>/
+
+     A program interpreting this URL would issue the standard set of
+     commands it uses to present a view of the contents of an IMAP
+     server.  This is likely to be semanticly equivalent to one of the
+     following URLs:
+
+         imap://<iserver>/;TYPE=LIST
+         imap://<iserver>/;TYPE=LSUB
+
+     The program interpreting this URL SHOULD use the LSUB form if it
+     supports mailbox subscriptions.
+
+
+5. Lists of mailboxes
+
+     An IMAP URL referring to a list of mailboxes has the following
+     form:
+
+         imap://<iserver>/<enc_list_mailbox>;TYPE=<list_type>
+
+     The <list_type> may be either "LIST" or "LSUB", and is case
+     insensitive.  The field ";TYPE=<list_type>" MUST be included.
+
+     The <enc_list_mailbox> is any argument suitable for the
+     list_mailbox field of the IMAP [IMAP4] LIST or LSUB commands.  The
+     field <enc_list_mailbox> may be omitted, in which case the program
+     interpreting the IMAP URL may use "*" or "%" as the
+     <enc_list_mailbox>.  The program SHOULD use "%" if it supports a
+     hierarchical view, otherwise it SHOULD use "*".
+
+     Note that if unsafe or reserved characters such as " " or "%" are
+     present in <enc_list_mailbox> they MUST be encoded as described in
+     RFC 1738 [BASIC-URL].  If the character "/" is present in
+     enc_list_mailbox, it SHOULD NOT be encoded.
+
+
+6. Lists of messages
+
+     An IMAP URL referring to a list of messages has the following form:
+
+         imap://<iserver>/<enc_mailbox>[uidvalidity][?<enc_search>]
+
+
+
+
+
+Newman                      Standards Track                     [Page 4]
+
+RFC 2192                    IMAP URL Scheme               September 1997
+
+
+     The <enc_mailbox> field is used as the argument to the IMAP4
+     "SELECT" command.  Note that if unsafe or reserved characters such
+     as " ", ";", or "?" are present in <enc_mailbox> they MUST be
+     encoded as described in RFC 1738 [BASIC-URL].  If the character "/"
+     is present in enc_mailbox, it SHOULD NOT be encoded.
+
+     The [uidvalidity] field is optional.  If it is present, it MUST be
+     the argument to the IMAP4 UIDVALIDITY status response at the time
+     the URL was created.  This SHOULD be used by the program
+     interpreting the IMAP URL to determine if the URL is stale.
+
+     The [?<enc_search>] field is optional.  If it is not present, the
+     contents of the mailbox SHOULD be presented by the program
+     interpreting the URL.  If it is present, it SHOULD be used as the
+     arguments following an IMAP4 SEARCH command with unsafe characters
+     such as " " (which are likely to be present in the <enc_search>)
+     encoded as described in RFC 1738 [BASIC-URL].
+
+
+7. A specific message or message part
+
+     An IMAP URL referring to a specific message or message part has the
+     following form:
+
+         imap://<iserver>/<enc_mailbox>[uidvalidity]<iuid>[isection]
+
+     The <enc_mailbox> and [uidvalidity] are as defined above.
+
+     If [uidvalidity] is present in this form, it SHOULD be used by the
+     program interpreting the URL to determine if the URL is stale.
+
+     The <iuid> refers to an IMAP4 message UID, and SHOULD be used as
+     the <set> argument to the IMAP4 "UID FETCH" command.
+
+     The [isection] field is optional.  If not present, the URL refers
+     to the entire Internet message as returned by the IMAP command "UID
+     FETCH <uid> BODY.PEEK[]".  If present, the URL refers to the object
+     returned by a "UID FETCH <uid> BODY.PEEK[<section>]" command.  The
+     type of the object may be determined with a "UID FETCH <uid>
+     BODYSTRUCTURE" command and locating the appropriate part in the
+     resulting BODYSTRUCTURE.  Note that unsafe characters in [isection]
+     MUST be encoded as described in [BASIC-URL].
+
+
+
+
+
+
+
+
+
+Newman                   Standards Track                        [Page 5]
+
+RFC 2192                    IMAP URL Scheme               September 1997
+
+
+8. Relative IMAP URLs
+
+     Relative IMAP URLs are permitted and are resolved according to the
+     rules defined in RFC 1808 [REL-URL] with one exception.  In IMAP
+     URLs, parameters are treated as part of the normal path with
+     respect to relative URL resolution.  This is believed to be the
+     behavior of the installed base and is likely to be documented in a
+     future revision of the relative URL specification.
+
+     The following observations are also important:
+
+     The <iauth> grammar element is considered part of the user name for
+     purposes of resolving relative IMAP URLs.  This means that unless a
+     new login/server specification is included in the relative URL, the
+     authentication mechanism is inherited from a base IMAP URL.
+
+     URLs always use "/" as the hierarchy delimiter for the purpose of
+     resolving paths in relative URLs.  IMAP4 permits the use of any
+     hierarchy delimiter in mailbox names.  For this reason, relative
+     mailbox paths will only work if the mailbox uses "/" as the
+     hierarchy delimiter.  Relative URLs may be used on mailboxes which
+     use other delimiters, but in that case, the entire mailbox name
+     MUST be specified in the relative URL or inherited as a whole from
+     the base URL.
+
+     The base URL for a list of mailboxes or messages which was referred
+     to by an IMAP URL is always the referring IMAP URL itself.  The
+     base URL for a message or message part which was referred to by an
+     IMAP URL may be more complicated to determine.  The program
+     interpreting the relative URL will have to check the headers of the
+     MIME entity and any enclosing MIME entities in order to locate the
+     "Content-Base" and "Content-Location" headers.  These headers are
+     used to determine the base URL as defined in [HTTP].  For example,
+     if the referring IMAP URL contains a "/;SECTION=1.2" parameter,
+     then the MIME headers for section 1.2, for section 1, and for the
+     enclosing message itself SHOULD be checked in that order for
+     "Content-Base" or "Content-Location" headers.
+
+
+9. Multinational Considerations
+
+     IMAP4 [IMAP4] section 5.1.3 includes a convention for encoding
+     non-US-ASCII characters in IMAP mailbox names.  Because this
+     convention is private to IMAP, it is necessary to convert IMAP's
+     encoding to one that can be more easily interpreted by a URL
+     display program.  For this reason, IMAP's modified UTF-7 encoding
+     for mailboxes MUST be converted to UTF-8 [UTF8].  Since 8-bit
+     characters are not permitted in URLs, the UTF-8 characters are
+
+
+
+Newman                      Standards Track                     [Page 6]
+
+RFC 2192                    IMAP URL Scheme               September 1997
+
+
+     encoded as required by the URL specification [BASIC-URL].  Sample
+     code is included in Appendix A to demonstrate this conversion.
+
+
+10. Examples
+
+     The following examples demonstrate how an IMAP4 client program
+     might translate various IMAP4 URLs into a series of IMAP4 commands.
+     Commands sent from the client to the server are prefixed with "C:",
+     and responses sent from the server to the client are prefixed with
+     "S:".
+
+     The URL:
+
+      <imap://minbari.org/gray-council;UIDVALIDITY=385759045/;UID=20>
+
+     Results in the following client commands:
+
+         <connect to minbari.org, port 143>
+         C: A001 LOGIN ANONYMOUS sheridan@babylon5.org
+         C: A002 SELECT gray-council
+         <client verifies the UIDVALIDITY matches>
+         C: A003 UID FETCH 20 BODY.PEEK[]
+
+     The URL:
+
+      <imap://michael@minbari.org/users.*;type=list>
+
+     Results in the following client commands:
+
+       <client requests password from user>
+       <connect to minbari.org imap server, activate strong encryption>
+       C: A001 LOGIN MICHAEL zipper
+       C: A002 LIST "" users.*
+
+     The URL:
+
+      <imap://psicorp.org/~peter/%E6%97%A5%E6%9C%AC%E8%AA%9E/
+      %E5%8F%B0%E5%8C%97>
+
+     Results in the following client commands:
+
+       <connect to psicorp.org, port 143>
+       C: A001 LOGIN ANONYMOUS bester@psycop.psicorp.org
+       C: A002 SELECT ~peter/&ZeVnLIqe-/&U,BTFw-
+       <commands the client uses for viewing the contents of a mailbox>
+
+
+
+
+
+Newman                      Standards Track                     [Page 7]
+
+RFC 2192                    IMAP URL Scheme               September 1997
+
+
+     The URL:
+
+      <imap://;AUTH=KERBEROS_V4@minbari.org/gray-council/;uid=20/
+      ;section=1.2>
+
+     Results in the following client commands:
+
+         <connect to minbari.org, port 143>
+         C: A001 AUTHENTICATE KERBEROS_V4
+         <authentication exchange>
+         C: A002 SELECT gray-council
+         C: A003 UID FETCH 20 BODY.PEEK[1.2]
+
+     If the following relative URL is located in that body part:
+
+      <;section=1.4>
+
+     This could result in the following client commands:
+
+         C: A004 UID FETCH 20 (BODY.PEEK[1.2.MIME]
+               BODY.PEEK[1.MIME]
+               BODY.PEEK[HEADER.FIELDS (Content-Base Content-Location)])
+         <Client looks for Content-Base or Content-Location headers in
+          result.  If no such headers, then it does the following>
+         C: A005 UID FETCH 20 BODY.PEEK[1.4]
+
+     The URL:
+
+      <imap://;AUTH=*@minbari.org/gray%20council?SUBJECT%20shadows>
+
+     Could result in the following:
+
+         <connect to minbari.org, port 143>
+         C: A001 CAPABILITY
+         S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI
+         S: A001 OK
+         C: A002 AUTHENTICATE GSSAPI
+         <authentication exchange>
+         S: A002 OK user lennier authenticated
+         C: A003 SELECT "gray council"
+         ...
+         C: A004 SEARCH SUBJECT shadows
+         S: * SEARCH 8 10 13 14 15 16
+         S: A004 OK SEARCH completed
+         C: A005 FETCH 8,10,13:16 ALL
+         ...
+
+
+
+
+
+Newman                      Standards Track                     [Page 8]
+
+RFC 2192                    IMAP URL Scheme               September 1997
+
+
+     NOTE: In this final example, the client has implementation
+     dependent choices.  The authentication mechanism could be anything,
+     including PREAUTH.  And the final FETCH command could fetch more or
+     less information about the messages, depending on what it wishes to
+     display to the user.
+
+
+11. Security Considerations
+
+     Security considerations discussed in the IMAP specification [IMAP4]
+     and the URL specification [BASIC-URL] are relevant.  Security
+     considerations related to authenticated URLs are discussed in
+     section 3 of this document.
+
+     Many email clients store the plain text password for later use
+     after logging into an IMAP server.  Such clients MUST NOT use a
+     stored password in response to an IMAP URL without explicit
+     permission from the user to supply that password to the specified
+     host name.
+
+
+12. ABNF for IMAP URL scheme
+
+     This uses ABNF as defined in RFC 822 [IMAIL].  Terminals from the
+     BNF for IMAP [IMAP4] and URLs [BASIC-URL] are also used.  Strings
+     are not case sensitive and free insertion of linear-white-space is
+     not permitted.
+
+     achar            = uchar / "&" / "=" / "~"
+                             ; see [BASIC-URL] for "uchar" definition
+
+     bchar            = achar / ":" / "@" / "/"
+
+     enc_auth_type    = 1*achar
+                           ; encoded version of [IMAP-AUTH] "auth_type"
+
+     enc_list_mailbox = 1*bchar
+                             ; encoded version of [IMAP4] "list_mailbox"
+
+     enc_mailbox      = 1*bchar
+                             ; encoded version of [IMAP4] "mailbox"
+
+     enc_search       = 1*bchar
+                             ; encoded version of search_program below
+
+     enc_section      = 1*bchar
+                             ; encoded version of section below
+
+
+
+
+Newman                   Standards Track                        [Page 9]
+
+RFC 2192                    IMAP URL Scheme               September 1997
+
+
+     enc_user         = 1*achar
+                             ; encoded version of [IMAP4] "userid"
+
+     imapurl          = "imap://" iserver "/" [ icommand ]
+
+     iauth            = ";AUTH=" ( "*" / enc_auth_type )
+
+     icommand         = imailboxlist / imessagelist / imessagepart
+
+     imailboxlist     = [enc_list_mailbox] ";TYPE=" list_type
+
+     imessagelist     = enc_mailbox [ "?" enc_search ] [uidvalidity]
+
+     imessagepart     = enc_mailbox [uidvalidity] iuid [isection]
+
+     isection         = "/;SECTION=" enc_section
+
+     iserver          = [iuserauth "@"] hostport
+                             ; See [BASIC-URL] for "hostport" definition
+
+     iuid             = "/;UID=" nz_number
+                             ; See [IMAP4] for "nz_number" definition
+
+     iuserauth        = enc_user [iauth] / [enc_user] iauth
+
+     list_type        = "LIST" / "LSUB"
+
+     search_program   = ["CHARSET" SPACE astring SPACE]
+                        search_key *(SPACE search_key)
+                           ; IMAP4 literals may not be used
+                           ; See [IMAP4] for "astring" and "search_key"
+
+     section          = section_text / (nz_number *["." nz_number]
+                         ["." (section_text / "MIME")])
+                        ; See [IMAP4] for "section_text" and "nz_number"
+
+     uidvalidity      = ";UIDVALIDITY=" nz_number
+                             ; See [IMAP4] for "nz_number" definition
+
+13. References
+
+     [BASIC-URL] Berners-Lee, Masinter, McCahill, "Uniform Resource
+     Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of
+     Minnesota, December 1994.
+
+         <ftp://ds.internic.net/rfc/rfc1738.txt>
+
+
+
+
+
+Newman                      Standards Track                    [Page 10]
+
+RFC 2192                    IMAP URL Scheme               September 1997
+
+
+     [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
+     4rev1", RFC 2060, University of Washington, December 1996.
+
+         <ftp://ds.internic.net/rfc/rfc2060.txt>
+
+     [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731,
+     Carnegie-Mellon University, December 1994.
+
+         <ftp://ds.internic.net/rfc/rfc1731.txt>
+
+     [HTTP] Fielding, Gettys, Mogul, Frystyk, Berners-Lee, "Hypertext
+     Transfer Protocol -- HTTP/1.1", RFC 2068, UC Irvine, DEC, MIT/LCS,
+     January 1997.
+
+         <ftp://ds.internic.net/rfc/rfc2068.txt>
+
+     [IMAIL] Crocker, "Standard for the Format of ARPA Internet Text
+     Messages", STD 11, RFC 822, University of Delaware, August 1982.
+
+         <ftp://ds.internic.net/rfc/rfc822.txt>
+
+     [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
+     Requirement Levels", RFC 2119, Harvard University, March 1997.
+
+         <ftp://ds.internic.net/rfc/rfc2119.txt>
+
+     [MIME] Freed, N., Borenstein, N., "Multipurpose Internet Mail
+     Extensions", RFC 2045, Innosoft, First Virtual, November 1996.
+
+        <ftp://ds.internic.net/rfc/rfc2045.txt>
+
+     [REL-URL] Fielding, "Relative Uniform Resource Locators", RFC 1808,
+     UC Irvine, June 1995.
+
+         <ftp://ds.internic.net/rfc/rfc1808.txt>
+
+     [UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and
+     ISO 10646", RFC 2044, Alis Technologies, October 1996.
+
+         <ftp://ds.internic.net/rfc/rfc2044.txt>
+
+14. Author's Address
+
+     Chris Newman
+     Innosoft International, Inc.
+     1050 Lakes Drive
+     West Covina, CA 91790 USA
+     EMail: chris.newman@innosoft.com
+
+
+
+Newman                      Standards Track                    [Page 11]
+
+RFC 2192                    IMAP URL Scheme               September 1997
+
+
+Appendix A.  Sample code
+
+Here is sample C source code to convert between URL paths and IMAP
+mailbox names, taking into account mapping between IMAP's modified UTF-7
+[IMAP4] and hex-encoded UTF-8 which is more appropriate for URLs.  This
+code has not been rigorously tested nor does it necessarily behave
+reasonably with invalid input, but it should serve as a useful example.
+This code just converts the mailbox portion of the URL and does not deal
+with parameters, query or server components of the URL.
+
+#include <stdio.h>
+#include <string.h>
+
+/* hexadecimal lookup table */
+static char hex[] = "0123456789ABCDEF";
+
+/* URL unsafe printable characters */
+static char urlunsafe[] = " \"#%&+:;<=>?@[\\]^`{|}";
+
+/* UTF7 modified base64 alphabet */
+static char base64chars[] =
+  "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+,";
+#define UNDEFINED 64
+
+/* UTF16 definitions */
+#define UTF16MASK       0x03FFUL
+#define UTF16SHIFT      10
+#define UTF16BASE       0x10000UL
+#define UTF16HIGHSTART  0xD800UL
+#define UTF16HIGHEND    0xDBFFUL
+#define UTF16LOSTART    0xDC00UL
+#define UTF16LOEND      0xDFFFUL
+
+/* Convert an IMAP mailbox to a URL path
+ *  dst needs to have roughly 4 times the storage space of src
+ *    Hex encoding can triple the size of the input
+ *    UTF-7 can be slightly denser than UTF-8
+ *     (worst case: 8 octets UTF-7 becomes 9 octets UTF-8)
+ */
+void MailboxToURL(char *dst, char *src)
+{
+    unsigned char c, i, bitcount;
+    unsigned long ucs4, utf16, bitbuf;
+    unsigned char base64[256], utf8[6];
+
+
+
+
+
+
+
+Newman                   Standards Track                       [Page 12]
+
+RFC 2192                    IMAP URL Scheme               September 1997
+
+
+    /* initialize modified base64 decoding table */
+    memset(base64, UNDEFINED, sizeof (base64));
+    for (i = 0; i < sizeof (base64chars); ++i) {
+        base64[base64chars[i]] = i;
+    }
+
+    /* loop until end of string */
+    while (*src != '\0') {
+        c = *src++;
+        /* deal with literal characters and &- */
+        if (c != '&' || *src == '-') {
+            if (c < ' ' || c > '~' || strchr(urlunsafe, c) != NULL) {
+                /* hex encode if necessary */
+                dst[0] = '%';
+                dst[1] = hex[c >> 4];
+                dst[2] = hex[c & 0x0f];
+                dst += 3;
+            } else {
+                /* encode literally */
+                *dst++ = c;
+            }
+            /* skip over the '-' if this is an &- sequence */
+            if (c == '&') ++src;
+        } else {
+        /* convert modified UTF-7 -> UTF-16 -> UCS-4 -> UTF-8 -> HEX */
+            bitbuf = 0;
+            bitcount = 0;
+            ucs4 = 0;
+            while ((c = base64[(unsigned char) *src]) != UNDEFINED) {
+                ++src;
+                bitbuf = (bitbuf << 6) | c;
+                bitcount += 6;
+                /* enough bits for a UTF-16 character? */
+                if (bitcount >= 16) {
+                    bitcount -= 16;
+                    utf16 = (bitcount ? bitbuf >> bitcount
+                             : bitbuf) & 0xffff;
+                    /* convert UTF16 to UCS4 */
+                    if
+                    (utf16 >= UTF16HIGHSTART && utf16 <= UTF16HIGHEND) {
+                        ucs4 = (utf16 - UTF16HIGHSTART) << UTF16SHIFT;
+                        continue;
+                    } else if
+                    (utf16 >= UTF16LOSTART && utf16 <= UTF16LOEND) {
+                        ucs4 += utf16 - UTF16LOSTART + UTF16BASE;
+                    } else {
+                        ucs4 = utf16;
+                    }
+
+
+
+Newman                   Standards Track                       [Page 13]
+
+RFC 2192                    IMAP URL Scheme               September 1997
+
+
+                    /* convert UTF-16 range of UCS4 to UTF-8 */
+                    if (ucs4 <= 0x7fUL) {
+                        utf8[0] = ucs4;
+                        i = 1;
+                    } else if (ucs4 <= 0x7ffUL) {
+                        utf8[0] = 0xc0 | (ucs4 >> 6);
+                        utf8[1] = 0x80 | (ucs4 & 0x3f);
+                        i = 2;
+                    } else if (ucs4 <= 0xffffUL) {
+                        utf8[0] = 0xe0 | (ucs4 >> 12);
+                        utf8[1] = 0x80 | ((ucs4 >> 6) & 0x3f);
+                        utf8[2] = 0x80 | (ucs4 & 0x3f);
+                        i = 3;
+                    } else {
+                        utf8[0] = 0xf0 | (ucs4 >> 18);
+                        utf8[1] = 0x80 | ((ucs4 >> 12) & 0x3f);
+                        utf8[2] = 0x80 | ((ucs4 >> 6) & 0x3f);
+                        utf8[3] = 0x80 | (ucs4 & 0x3f);
+                        i = 4;
+                    }
+                    /* convert utf8 to hex */
+                    for (c = 0; c < i; ++c) {
+                        dst[0] = '%';
+                        dst[1] = hex[utf8[c] >> 4];
+                        dst[2] = hex[utf8[c] & 0x0f];
+                        dst += 3;
+                    }
+                }
+            }
+            /* skip over trailing '-' in modified UTF-7 encoding */
+            if (*src == '-') ++src;
+        }
+    }
+    /* terminate destination string */
+    *dst = '\0';
+}
+
+/* Convert hex coded UTF-8 URL path to modified UTF-7 IMAP mailbox
+ *  dst should be about twice the length of src to deal with non-hex
+ *  coded URLs
+ */
+void URLtoMailbox(char *dst, char *src)
+{
+   unsigned int utf8pos, utf8total, i, c, utf7mode, bitstogo, utf16flag;
+   unsigned long ucs4, bitbuf;
+   unsigned char hextab[256];
+
+    /* initialize hex lookup table */
+
+
+
+Newman                   Standards Track                       [Page 14]
+
+RFC 2192                    IMAP URL Scheme               September 1997
+
+
+    memset(hextab, 0, sizeof (hextab));
+    for (i = 0; i < sizeof (hex); ++i) {
+        hextab[hex[i]] = i;
+        if (isupper(hex[i])) hextab[tolower(hex[i])] = i;
+    }
+
+    utf7mode = 0;
+    utf8total = 0;
+    bitstogo = 0;
+    while ((c = *src) != '\0') {
+        ++src;
+        /* undo hex-encoding */
+        if (c == '%' && src[0] != '\0' && src[1] != '\0') {
+            c = (hextab[src[0]] << 4) | hextab[src[1]];
+            src += 2;
+        }
+        /* normal character? */
+        if (c >= ' ' && c <= '~') {
+            /* switch out of UTF-7 mode */
+            if (utf7mode) {
+                if (bitstogo) {
+                *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F];
+                }
+                *dst++ = '-';
+                utf7mode = 0;
+            }
+            *dst++ = c;
+            /* encode '&' as '&-' */
+            if (c == '&') {
+                *dst++ = '-';
+            }
+            continue;
+        }
+        /* switch to UTF-7 mode */
+        if (!utf7mode) {
+            *dst++ = '&';
+            utf7mode = 1;
+        }
+        /* Encode US-ASCII characters as themselves */
+        if (c < 0x80) {
+            ucs4 = c;
+            utf8total = 1;
+        } else if (utf8total) {
+            /* save UTF8 bits into UCS4 */
+            ucs4 = (ucs4 << 6) | (c & 0x3FUL);
+            if (++utf8pos < utf8total) {
+                continue;
+            }
+
+
+
+Newman                   Standards Track                       [Page 15]
+
+RFC 2192                    IMAP URL Scheme               September 1997
+
+
+        } else {
+            utf8pos = 1;
+            if (c < 0xE0) {
+                utf8total = 2;
+                ucs4 = c & 0x1F;
+            } else if (c < 0xF0) {
+                utf8total = 3;
+                ucs4 = c & 0x0F;
+            } else {
+                /* NOTE: can't convert UTF8 sequences longer than 4 */
+                utf8total = 4;
+                ucs4 = c & 0x03;
+            }
+            continue;
+        }
+        /* loop to split ucs4 into two utf16 chars if necessary */
+        utf8total = 0;
+        do {
+            if (ucs4 >= UTF16BASE) {
+                ucs4 -= UTF16BASE;
+                bitbuf = (bitbuf << 16) | ((ucs4 >> UTF16SHIFT)
+                                           + UTF16HIGHSTART);
+                ucs4 = (ucs4 & UTF16MASK) + UTF16LOSTART;
+                utf16flag = 1;
+            } else {
+                bitbuf = (bitbuf << 16) | ucs4;
+                utf16flag = 0;
+            }
+            bitstogo += 16;
+            /* spew out base64 */
+            while (bitstogo >= 6) {
+                bitstogo -= 6;
+                *dst++ = base64chars[(bitstogo ? (bitbuf >> bitstogo)
+                               : bitbuf)
+                                     & 0x3F];
+            }
+        } while (utf16flag);
+    }
+    /* if in UTF-7 mode, finish in ASCII */
+    if (utf7mode) {
+        if (bitstogo) {
+            *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F];
+        }
+        *dst++ = '-';
+    }
+    /* tie off string */
+    *dst = '\0';
+}
+
+
+
+Newman                   Standards Track                       [Page 16]
+
diff --git a/docs/rfcs/rfc2193.txt b/docs/rfcs/rfc2193.txt
new file mode 100644
index 0000000..2fec58d
--- /dev/null
+++ b/docs/rfcs/rfc2193.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                        M. Gahrns
+Request for Comments: 2193                                   Microsoft
+Category: Standards Track                               September 1997
+
+
+                        IMAP4 Mailbox Referrals
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+1. Abstract
+
+   When dealing with large amounts of users, messages and geographically
+   dispersed IMAP4 [RFC-2060] servers, it is often desirable to
+   distribute messages amongst different servers within an organization.
+   For example an administrator may choose to store user's personal
+   mailboxes on a local IMAP4 server, while storing shared mailboxes
+   remotely on another server.  This type of configuration is common
+   when it is uneconomical to store all data centrally due to limited
+   bandwidth or disk resources.
+
+   Mailbox referrals allow clients to seamlessly access mailboxes that
+   are distributed across several IMAP4 servers.
+
+   A referral mechanism can provide efficiencies over the alternative
+   "proxy method", in which the local IMAP4 server contacts the remote
+   server on behalf of the client, and then transfers the data from the
+   remote server to itself, and then on to the client.  The referral
+   mechanism's direct client connection to the remote server is often a
+   more efficient use of bandwidth, and does not require the local
+   server to impersonate the client when authenticating to the remote
+   server.
+
+2. Conventions used in this document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+   A home server, is an IMAP4 server that contains the user's inbox.
+
+   A remote mailbox is a mailbox that is not hosted on the user's home
+   server.
+
+
+
+
+Gahrns                      Standards Track                     [Page 1]
+
+RFC 2193                IMAP4 Mailbox Referrals           September 1997
+
+
+   A remote server is a server that contains remote mailboxes.
+
+   A shared mailbox, is a mailbox that multiple users have access to.
+
+   An IMAP mailbox referral is when the server directs the client to
+   another IMAP mailbox.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC-2119].
+
+3. Introduction and Overview
+
+   IMAP4 servers that support this extension MUST list the keyword
+   MAILBOX-REFERRALS in their CAPABILITY response.  No client action is
+   needed to invoke the MAILBOX-REFERRALS capability in a server.
+
+   A MAILBOX-REFERRALS capable IMAP4 server MUST NOT return referrals
+   that result in a referrals loop.
+
+   A referral response consists of a tagged NO response and a REFERRAL
+   response code.  The REFERRAL response code MUST contain as an
+   argument a one or more valid URLs separated by a space as defined in
+   [RFC-1738]. If a server replies with multiple URLs for a particular
+   object, they MUST all be of the same type. In this case, the URL MUST
+   be an IMAP URL as defined in [RFC-2192].  A client that supports the
+   REFERRALS extension MUST be prepared for a URL of any type, but it
+   need only be able to process IMAP URLs.
+
+   A server MAY respond with multiple IMAP mailbox referrals if there is
+   more than one replica of the mailbox.  This allows the implementation
+   of a load balancing or failover scheme. How a server keeps multiple
+   replicas of a mailbox in sync is not addressed by this document.
+
+   If the server has a preferred order in which the client should
+   attempt to access the URLs, the preferred URL SHOULD be listed in the
+   first, with the remaining URLs presented in descending order of
+   preference.  If multiple referrals are given for a mailbox, a server
+   should be aware that there are synchronization issues for a client if
+   the UIDVALIDITY of the referred mailboxes are different.
+
+   An IMAP mailbox referral may be given in response to an IMAP command
+   that specifies a mailbox as an argument.
+
+
+
+
+
+
+
+
+Gahrns                      Standards Track                     [Page 2]
+
+RFC 2193                IMAP4 Mailbox Referrals           September 1997
+
+
+   Example:
+
+      A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE]Remote Mailbox
+
+   NOTE: user;AUTH=* is specified as required by [RFC-2192] to avoid a
+   client falling back to anonymous login.
+
+   Remote mailboxes and their inferiors, that are accessible only via
+   referrals SHOULD NOT appear in LIST and LSUB responses issued against
+   the user's home server.  They MUST appear in RLIST and RLSUB
+   responses issued against the user's home server. Hierarchy referrals,
+   in which a client would be required to connect to the remote server
+   to issue a LIST to discover the inferiors of a mailbox are not
+   addressed in this document.
+
+   For example, if shared mailboxes were only accessible via referrals
+   on a remote server, a RLIST "" "#SHARED/%" command would return the
+   same response if issued against the user's home server or the remote
+   server.
+
+   Note: Mailboxes that are available on the user's home server do not
+   need to be available on the remote server.  In addition, there may be
+   additional mailboxes available on the remote server, but they will
+   not accessible to the client via referrals unless they appear in the
+   LIST response to the RLIST command against the user's home server.
+
+   A MAILBOX-REFERRALS capable client will issue the RLIST and RLSUB
+   commands in lieu of LIST and LSUB.  The RLIST and RLSUB commands
+   behave identically to their LIST and LSUB counterparts, except remote
+   mailboxes are returned in addition to local mailboxes in the LIST and
+   LSUB responses.  This avoids displaying to a non MAILBOX-REFERRALS
+   enabled client inaccessible remote mailboxes.
+
+4.1. SELECT, EXAMINE, DELETE, SUBSCRIBE, UNSUBSCRIBE, STATUS and APPEND
+     Referrals
+
+   An IMAP4 server MAY respond to the SELECT, EXAMINE, DELETE,
+   SUBSCRIBE, UNSUBSCRIBE, STATUS or APPEND command with one or more
+   IMAP mailbox referrals to indicate to the client that the mailbox is
+   hosted on a remote server.
+
+   When a client processes an IMAP mailbox referral, it will open a new
+   connection or use an existing connection to the remote server so that
+   it is able to issue the commands necessary to process the remote
+   mailbox.
+
+
+
+
+
+
+Gahrns                      Standards Track                     [Page 3]
+
+RFC 2193                IMAP4 Mailbox Referrals           September 1997
+
+
+   Example:  <IMAP4 connection to home server>
+
+      C: A001 DELETE "SHARED/FOO"
+      S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO]
+             Remote mailbox. Try SERVER2.
+
+      <Client established a second connection to SERVER2 and
+      issues the DELETE command on the referred mailbox>
+
+      S: * OK IMAP4rev1 server ready
+      C: B001 AUTHENTICATE KERBEROS_V4
+      <authentication exchange>
+      S: B001 OK user is authenticated
+
+      C: B002 DELETE "SHARED/FOO"
+      S: B002 OK DELETE completed
+
+   Example:  <IMAP4 connection to home server>
+
+      C: A001 SELECT REMOTE
+      S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE
+          IMAP://user;AUTH=*@SERVER3/REMOTE] Remote mailbox.
+          Try SERVER2 or SERVER3.
+
+      <Client opens second connection to remote server, and
+       issues the commands needed to process the items in the
+       remote mailbox>
+
+      S: * OK IMAP4rev1 server ready
+      C: B001 AUTHENTICATE KERBEROS_V4
+      <authentication exchange>
+      S: B001 OK user is authenticated
+
+      C: B002 SELECT REMOTE
+      S: * 12 EXISTS
+      S: * 1 RECENT
+      S: * OK [UNSEEN 10] Message 10 is first unseen
+      S: * OK [UIDVALIDITY 123456789]
+      S: * FLAGS (Answered Flagged Deleted Seen Draft)
+      S: * OK [PERMANENTFLAGS (Answered Deleted Seen ]
+      S: B002 OK [READ-WRITE] Selected completed
+
+      C: B003 FETCH 10:12 RFC822
+      S: * 10 FETCH . . .
+      S: * 11 FETCH . . .
+      S: * 12 FETCH . . .
+      S: B003 OK FETCH Completed
+
+
+
+
+Gahrns                      Standards Track                     [Page 4]
+
+RFC 2193                IMAP4 Mailbox Referrals           September 1997
+
+
+      <Client is finished processing the REMOTE mailbox and
+       wants to process a mailbox on its home server>
+
+      C: B004 LOGOUT
+      S: * BYE IMAP4rev1 server logging out
+      S: B004 OK LOGOUT Completed
+
+      <Client continues with first connection>
+
+      C: A002 SELECT INBOX
+      S: * 16 EXISTS
+      S: * 2 RECENT
+      S: * OK [UNSEEN 10] Message 10 is first unseen
+      S: * OK [UIDVALIDITY 123456789]
+      S: * FLAGS (Answered Flagged Deleted Seen Draft)
+      S: * OK [PERMANENTFLAGS (Answered Deleted Seen ]
+      S: A002 OK [READ-WRITE] Selected completed
+
+4.2. CREATE Referrals
+
+   An IMAP4 server MAY respond to the CREATE command with one or more
+   IMAP mailbox referrals, if it wishes to direct the client to issue
+   the CREATE against another server.  The server can employ any means,
+   such as examining the hierarchy of the specified mailbox name, in
+   determining which server the mailbox should be created on.
+
+   Example:
+
+      C: A001 CREATE "SHARED/FOO"
+      S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO]
+         Mailbox should be created on remote server
+
+   Alternatively, because a home server is required to maintain a
+   listing of referred remote mailboxes, a server MAY allow the creation
+   of a mailbox that will ultimately reside on a remote server against
+   the home server, and provide referrals on subsequent commands that
+   manipulate the mailbox.
+
+   Example:
+
+      C: A001 CREATE "SHARED/FOO"
+      S: A001 OK CREATE succeeded
+
+      C: A002 SELECT "SHARED/FOO"
+      S: A002 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO]
+         Remote mailbox.  Try SERVER2
+
+
+
+
+
+Gahrns                      Standards Track                     [Page 5]
+
+RFC 2193                IMAP4 Mailbox Referrals           September 1997
+
+
+4.3. RENAME Referrals
+
+   An IMAP4 server MAY respond to the RENAME command with one or more
+   pairs of IMAP mailbox referrals.  In each pair of IMAP mailbox
+   referrals, the first one is an URL to the existing mailbox name and
+   the second is an URL to the requested new mailbox name.
+
+   If within an IMAP mailbox referral pair, the existing and new mailbox
+   URLs are on different servers, the remote servers are unable to
+   perform the RENAME operation.   To achieve the same behavior of
+   server RENAME, the client MAY issue the constituent CREATE, FETCH,
+   APPEND, and DELETE commands against both servers.
+
+   If within an IMAP mailbox referral pair, the existing and new mailbox
+   URLs are on the same server it is an indication that the currently
+   connected server is unable to perform the operation.  The client can
+   simply re-issue the RENAME command on the remote server.
+
+   Example:
+
+      C: A001 RENAME FOO BAR
+      S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER1/FOO
+              IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox
+              across servers
+
+   Since the existing and new mailbox names are on different servers,
+   the client would be required to make a connection to both servers and
+   issue the constituent commands require to achieve the RENAME.
+
+   Example:
+
+      C: A001 RENAME FOO BAR
+      S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/FOO
+              IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox
+              located on SERVER2
+
+   Since both the existing and new mailbox are on the same remote
+   server, the client can simply make a connection to the remote server
+   and re-issue the RENAME command.
+
+4.4. COPY Referrals
+
+   An IMAP4 server MAY respond to the COPY command with one or more IMAP
+   mailbox referrals.  This indicates that the destination mailbox is on
+   a remote server.  To achieve the same behavior of a server COPY, the
+   client MAY issue the constituent FETCH and APPEND commands against
+   both servers.
+
+
+
+
+Gahrns                      Standards Track                     [Page 6]
+
+RFC 2193                IMAP4 Mailbox Referrals           September 1997
+
+
+   Example:
+
+      C: A001 COPY 1 "SHARED/STUFF"
+      S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/STUFF]
+              Unable to copy message(s) to SERVER2.
+
+5.1 RLIST command
+
+   Arguments:  reference name
+               mailbox name with possible wildcards
+
+   Responses:  untagged responses: LIST
+
+   Result:     OK - RLIST Completed
+               NO - RLIST Failure
+               BAD - command unknown or arguments invalid
+
+   The RLIST command behaves identically to its LIST counterpart, except
+   remote mailboxes are returned in addition to local mailboxes in the
+   LIST responses.
+
+5.2 RLSUB Command
+
+   Arguments:  reference name
+               mailbox name with possible wildcards
+
+   Responses:  untagged responses: LSUB
+
+   Result:     OK - RLSUB Completed
+               NO - RLSUB Failure
+               BAD - command unknown or arguments invalid
+
+   The RLSUB command behaves identically to its LSUB counterpart, except
+   remote mailboxes are returned in addition to local mailboxes in the
+   LSUB responses.
+
+6. Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) as described in [ABNF].
+
+   list_mailbox = <list_mailbox> as defined in [RFC-2060]
+
+   mailbox = <mailbox> as defined in [RFC-2060]
+
+   mailbox_referral = <tag> SPACE "NO" SPACE
+      <referral_response_code> (text / text_mime2)
+      ; See [RFC-2060] for <tag>, text and text_mime2 definition
+
+
+
+Gahrns                      Standards Track                     [Page 7]
+
+RFC 2193                IMAP4 Mailbox Referrals           September 1997
+
+
+   referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]"
+      ; See [RFC-1738] for <url> definition
+
+   rlist = "RLIST" SPACE mailbox SPACE list_mailbox
+
+   rlsub = "RLSUB" SPACE mailbox SPACE list_mailbox
+
+6. Security Considerations
+
+   The IMAP4 referral mechanism makes use of IMAP URLs, and as such,
+   have the same security considerations as general internet URLs [RFC-
+   1738], and in particular IMAP URLs [RFC-2192].
+
+   With the MAILBOX-REFERRALS capability, it is potentially easier to
+   write a rogue server that injects a bogus referral response that
+   directs a user to an incorrect mailbox.  Although referrals reduce
+   the effort to write such a server, the referral response makes
+   detection of the intrusion easier.
+
+7. References
+
+   [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
+   4rev1", RFC 2060, University of Washington, December 1996.
+
+   [RFC-2192], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft,
+   September 1997.
+
+   [RFC-1738], Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
+   Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation,
+   University of Minnesota, December 1994.
+
+   [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
+   Requirement Levels", RFC 2119, Harvard University, March 1997.
+
+   [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for
+   Syntax Specifications: ABNF", Work in Progress, Internet Mail
+   Consortium, April 1997.
+
+8.  Acknowledgments
+
+   Many valuable suggestions were received from private discussions and
+   the IMAP4 mailing list.  In particular, Raymond Cheng, Mark Crispin,
+   Mark Keasling, Chris Newman and Larry Osterman made significant
+   contributions to this document.
+
+
+
+
+
+
+
+Gahrns                      Standards Track                     [Page 8]
+
+RFC 2193                IMAP4 Mailbox Referrals           September 1997
+
+
+9. Author's Address
+
+   Mike Gahrns
+   Microsoft
+   One Microsoft Way
+   Redmond, WA, 98072
+
+   Phone: (206) 936-9833
+   EMail: mikega@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gahrns                      Standards Track                     [Page 9]
+
diff --git a/docs/rfcs/rfc2195.txt b/docs/rfcs/rfc2195.txt
new file mode 100644
index 0000000..4a2725b
--- /dev/null
+++ b/docs/rfcs/rfc2195.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                       J. Klensin
+Request for Comments: 2195                                    R. Catoe
+Category: Standards Track                                 P. Krumviede
+Obsoletes: 2095                                                    MCI
+                                                        September 1997
+
+
+       IMAP/POP AUTHorize Extension for Simple Challenge/Response
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   While IMAP4 supports a number of strong authentication mechanisms as
+   described in RFC 1731, it lacks any mechanism that neither passes
+   cleartext, reusable passwords across the network nor requires either
+   a significant security infrastructure or that the mail server update
+   a mail-system-wide user authentication file on each mail access.
+   This specification provides a simple challenge-response
+   authentication protocol that is suitable for use with IMAP4.  Since
+   it utilizes Keyed-MD5 digests and does not require that the secret be
+   stored in the clear on the server, it may also constitute an
+   improvement on APOP for POP3 use as specified in RFC 1734.
+
+1. Introduction
+
+   Existing Proposed Standards specify an AUTHENTICATE mechanism for the
+   IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for
+   the POP3 protocol [POP3-AUTH].  The AUTHENTICATE mechanism is
+   intended to be extensible; the four methods specified in [IMAP-AUTH]
+   are all fairly powerful and require some security infrastructure to
+   support.  The base POP3 specification [POP3] also contains a
+   lightweight challenge-response mechanism called APOP.  APOP is
+   associated with most of the risks associated with such protocols: in
+   particular, it requires that both the client and server machines have
+   access to the shared secret in cleartext form. CRAM offers a method
+   for avoiding such cleartext storage while retaining the algorithmic
+   simplicity of APOP in using only MD5, though in a "keyed" method.
+
+
+
+
+
+
+
+Klensin, Catoe & Krumviede  Standards Track                     [Page 1]
+
+RFC 2195              IMAP/POP AUTHorize Extension        September 1997
+
+
+   At present, IMAP [IMAP] lacks any facility corresponding to APOP.
+   The only alternative to the strong mechanisms identified in [IMAP-
+   AUTH] is a presumably cleartext username and password, supported
+   through the LOGIN command in [IMAP].  This document describes a
+   simple challenge-response mechanism, similar to APOP and PPP CHAP
+   [PPP], that can be used with IMAP (and, in principle, with POP3).
+
+   This mechanism also has the advantage over some possible alternatives
+   of not requiring that the server maintain information about email
+   "logins" on a per-login basis.  While mechanisms that do require such
+   per-login history records may offer enhanced security, protocols such
+   as IMAP, which may have several connections between a given client
+   and server open more or less simultaneous, may make their
+   implementation particularly challenging.
+
+2. Challenge-Response Authentication Mechanism (CRAM)
+
+   The authentication type associated with CRAM is "CRAM-MD5".
+
+   The data encoded in the first ready response contains an
+   presumptively arbitrary string of random digits, a timestamp, and the
+   fully-qualified primary host name of the server.  The syntax of the
+   unencoded form must correspond to that of an RFC 822 'msg-id'
+   [RFC822] as described in [POP3].
+
+   The client makes note of the data and then responds with a string
+   consisting of the user name, a space, and a 'digest'.  The latter is
+   computed by applying the keyed MD5 algorithm from [KEYED-MD5] where
+   the key is a shared secret and the digested text is the timestamp
+   (including angle-brackets).
+
+   This shared secret is a string known only to the client and server.
+   The `digest' parameter itself is a 16-octet value which is sent in
+   hexadecimal format, using lower-case ASCII characters.
+
+   When the server receives this client response, it verifies the digest
+   provided.  If the digest is correct, the server should consider the
+   client authenticated and respond appropriately.
+
+   Keyed MD5 is chosen for this application because of the greater
+   security imparted to authentication of short messages. In addition,
+   the use of the techniques described in [KEYED-MD5] for precomputation
+   of intermediate results make it possible to avoid explicit cleartext
+   storage of the shared secret on the server system by instead storing
+   the intermediate results which are known as "contexts".
+
+
+
+
+
+
+Klensin, Catoe & Krumviede  Standards Track                     [Page 2]
+
+RFC 2195              IMAP/POP AUTHorize Extension        September 1997
+
+
+   CRAM does not support a protection mechanism.
+
+   Example:
+
+   The examples in this document show the use of the CRAM mechanism with
+   the IMAP4 AUTHENTICATE command [IMAP-AUTH].  The base64 encoding of
+   the challenges and responses is part of the IMAP4 AUTHENTICATE
+   command, not part of the CRAM specification itself.
+
+     S: * OK IMAP4 Server
+     C: A0001 AUTHENTICATE CRAM-MD5
+     S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
+     C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
+     S: A0001 OK CRAM authentication successful
+
+      In this example, the shared secret is the string
+      'tanstaaftanstaaf'.  Hence, the Keyed MD5 digest is produced by
+      calculating
+
+        MD5((tanstaaftanstaaf XOR opad),
+            MD5((tanstaaftanstaaf XOR ipad),
+            <1896.697170952@postoffice.reston.mci.net>))
+
+      where ipad and opad are as defined in the keyed-MD5 Work in
+      Progress [KEYED-MD5] and the string shown in the challenge is the
+      base64 encoding of <1896.697170952@postoffice.reston.mci.net>. The
+      shared secret is null-padded to a length of 64 bytes. If the
+      shared secret is longer than 64 bytes, the MD5 digest of the
+      shared secret is used as a 16 byte input to the keyed MD5
+      calculation.
+
+      This produces a digest value (in hexadecimal) of
+
+           b913a602c7eda7a495b4e6e7334d3890
+
+      The user name is then prepended to it, forming
+
+           tim b913a602c7eda7a495b4e6e7334d3890
+
+      Which is then base64 encoded to meet the requirements of the IMAP4
+      AUTHENTICATE command (or the similar POP3 AUTH command), yielding
+
+           dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
+
+
+
+
+
+
+
+
+Klensin, Catoe & Krumviede  Standards Track                     [Page 3]
+
+RFC 2195              IMAP/POP AUTHorize Extension        September 1997
+
+
+3. References
+
+   [CHAP]  Lloyd, B., and W. Simpson, "PPP Authentication Protocols",
+       RFC 1334, October 1992.
+
+   [IMAP] Crispin, M., "Internet Message Access Protocol - Version
+       4rev1", RFC 2060, University of Washington, December 1996.
+
+   [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms",
+       RFC 1731, Carnegie Mellon, December 1994.
+
+   [KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for
+       Message Authentication", RFC 2104, February 1997.
+
+   [MD5]  Rivest, R., "The MD5 Message Digest Algorithm",
+       RFC 1321, MIT Laboratory for Computer Science, April 1992.
+
+   [POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3",
+       STD 53, RFC 1939, Carnegie Mellon, May 1996.
+
+   [POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
+       Carnegie Mellon, December, 1994.
+
+4. Security Considerations
+
+   It is conjectured that use of the CRAM authentication mechanism
+   provides origin identification and replay protection for a session.
+   Accordingly, a server that implements both a cleartext password
+   command and this authentication type should not allow both methods of
+   access for a given user.
+
+   While the saving, on the server, of "contexts" (see section 2) is
+   marginally better than saving the shared secrets in cleartext as is
+   required by CHAP [CHAP] and APOP [POP3], it is not sufficient to
+   protect the secrets if the server itself is compromised.
+   Consequently, servers that store the secrets or contexts must both be
+   protected to a level appropriate to the potential information value
+   in user mailboxes and identities.
+
+   As the length of the shared secret increases, so does the difficulty
+   of deriving it.
+
+   While there are now suggestions in the literature that the use of MD5
+   and keyed MD5 in authentication procedures probably has a limited
+   effective lifetime, the technique is now widely deployed and widely
+   understood.  It is believed that this general understanding may
+   assist with the rapid replacement, by CRAM-MD5, of the current uses
+   of permanent cleartext passwords in IMAP.   This document has been
+
+
+
+Klensin, Catoe & Krumviede  Standards Track                     [Page 4]
+
+RFC 2195              IMAP/POP AUTHorize Extension        September 1997
+
+
+   deliberately written to permit easy upgrading to use SHA (or whatever
+   alternatives emerge) when they are considered to be widely available
+   and adequately safe.
+
+   Even with the use of CRAM, users are still vulnerable to active
+   attacks.  An example of an increasingly common active attack is 'TCP
+   Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95].
+
+   See section 1 above for additional discussion.
+
+5. Acknowledgements
+
+   This memo borrows ideas and some text liberally from [POP3] and
+   [RFC-1731] and thanks are due the authors of those documents.  Ran
+   Atkinson made a number of valuable technical and editorial
+   contributions to the document.
+
+6. Authors' Addresses
+
+   John C. Klensin
+   MCI Telecommunications
+   800 Boylston St, 7th floor
+   Boston, MA 02199
+   USA
+
+   EMail: klensin@mci.net
+   Phone: +1 617 960 1011
+
+   Randy Catoe
+   MCI Telecommunications
+   2100 Reston Parkway
+   Reston, VA 22091
+   USA
+
+   EMail: randy@mci.net
+   Phone: +1 703 715 7366
+
+   Paul Krumviede
+   MCI Telecommunications
+   2100 Reston Parkway
+   Reston, VA 22091
+   USA
+
+   EMail: paul@mci.net
+   Phone: +1 703 715 7251
+
+
+
+
+
+
+Klensin, Catoe & Krumviede  Standards Track                     [Page 5]
+
diff --git a/docs/rfcs/rfc2221.txt b/docs/rfcs/rfc2221.txt
new file mode 100644
index 0000000..81d0062
--- /dev/null
+++ b/docs/rfcs/rfc2221.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                           M. Gahrns
+Request for Comments: 2221                                      Microsoft
+Category: Standards Track                                    October 1997
+
+
+                         IMAP4 Login Referrals
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1997).  All Rights Reserved.
+
+1. Abstract
+
+   When dealing with large amounts of users and many IMAP4 [RFC-2060]
+   servers, it is often necessary to move users from one IMAP4 server to
+   another.  For example, hardware failures or organizational changes
+   may dictate such a move.
+
+   Login referrals allow clients to transparently connect to an
+   alternate IMAP4 server, if their home IMAP4 server has changed.
+
+   A referral mechanism can provide efficiencies over the alternative
+   'proxy method', in which the local IMAP4 server contacts the remote
+   server on behalf of the client, and then transfers the data from the
+   remote server to itself, and then on to the client.  The referral
+   mechanism's direct client connection to the remote server is often a
+   more efficient use of bandwidth, and does not require the local
+   server to impersonate the client when authenticating to the remote
+   server.
+
+2. Conventions used in this document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+   A home server, is an IMAP4 server that contains the user's inbox.
+
+   A remote server is a server that contains remote mailboxes.
+
+
+
+
+
+Gahrns                      Standards Track                     [Page 1]
+
+RFC 2221                 IMAP4 Login Referrals              October 1997
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC-2119].
+
+3. Introduction and Overview
+
+   IMAP4 servers that support this extension MUST list the keyword
+   LOGIN-REFERRALS in their CAPABILITY response.  No client action is
+   needed to invoke the LOGIN-REFERRALS capability in a server.
+
+   A LOGIN-REFERRALS capable IMAP4 server SHOULD NOT return a referral
+   to a server that will return a referral. A client MUST NOT follow
+   more than 10 levels of referral without consulting the user.
+
+   A LOGIN-REFERRALS response code MUST contain as an argument a valid
+   IMAP server URL as defined in [IMAP-URL].
+
+   A home server referral consists of either a tagged NO or OK, or an
+   untagged BYE response that contains a LOGIN-REFERRALS response code.
+
+   Example: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/] Remote Server
+
+   NOTE: user;AUTH=* is specified as required by [IMAP-URL] to avoid a
+   client falling back to anonymous login.
+
+4. Home Server Referrals
+
+   A home server referral may be returned in response to an AUTHENTICATE
+   or LOGIN command, or it may appear in the connection startup banner.
+   If a server returns a home server referral in a tagged NO response,
+   that server does not contain any mailboxes that are accessible to the
+   user.  If a server returns a home server referral in a tagged OK
+   response, it indicates that the user's personal mailboxes are
+   elsewhere, but the server contains public mailboxes which are
+   readable by the user.  After receiving a home server referral, the
+   client can not make any assumptions as to whether this was a
+   permanent or temporary move of the user.
+
+4.1.  LOGIN and AUTHENTICATE Referrals
+
+   An IMAP4 server MAY respond to a LOGIN or AUTHENTICATE command with a
+   home server referral if it wishes to direct the user to another IMAP4
+   server.
+
+   Example:  C: A001 LOGIN MIKE PASSWORD
+             S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified user
+                     is invalid on this server. Try SERVER2.
+
+
+
+
+Gahrns                      Standards Track                     [Page 2]
+
+RFC 2221                 IMAP4 Login Referrals              October 1997
+
+
+   Example:  C: A001 LOGIN MATTHEW PASSWORD
+             S: A001 OK [REFERRAL IMAP://MATTHEW@SERVER2/] Specified
+                     user's personal mailboxes located on Server2, but
+                     public mailboxes are available.
+
+   Example:  C: A001 AUTHENTICATE GSSAPI
+             <authentication exchange>
+             S: A001 NO [REFERRAL IMAP://user;AUTH=GSSAPI@SERVER2/]
+                     Specified user is invalid on this server. Try
+                     SERVER2.
+
+4.2. BYE at connection startup referral
+
+   An IMAP4 server MAY respond with an untagged BYE and a REFERRAL
+   response code that contains an IMAP URL to a home server if it is not
+   willing to accept connections and wishes to direct the client to
+   another IMAP4 server.
+
+   Example:  S: * BYE [REFERRAL IMAP://user;AUTH=*@SERVER2/] Server not
+                  accepting connections.  Try SERVER2
+
+5. Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) as described in [ABNF].
+
+   This amends the "resp_text_code" element of the IMAP4 grammar
+   described in [RFC-2060]
+
+   resp_text_code =/ "REFERRAL" SPACE <imapurl>
+      ; See [IMAP-URL] for definition of <imapurl>
+      ; See [RFC-2060] for base definition of resp_text_code
+
+6. Security Considerations
+
+   The IMAP4 login referral mechanism makes use of IMAP URLs, and as
+   such, have the same security considerations as general internet URLs
+   [RFC-1738], and in particular IMAP URLs [IMAP-URL].
+
+   A server MUST NOT give a login referral if authentication for that
+   user fails. This is to avoid revealing information about the user's
+   account to an unauthorized user.
+
+   With the LOGIN-REFERRALS capability, it is potentially easier to
+   write a rogue 'password catching' server that collects login data and
+   then refers the client to their actual IMAP4 server.  Although
+   referrals reduce the effort to write such a server, the referral
+   response makes detection of the intrusion easier.
+
+
+
+Gahrns                      Standards Track                     [Page 3]
+
+RFC 2221                 IMAP4 Login Referrals              October 1997
+
+
+7. References
+
+   [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
+   4rev1", RFC 2060, December 1996.
+
+   [IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft,
+   September 1997.
+
+   [RFC-1738], Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
+   Resource Locators  (URL)", RFC 1738, December 1994.
+
+   [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
+   Requirement Levels", RFC 2119, March 1997.
+
+   [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for
+   Syntax Specifications: ABNF", Work in Progress.
+
+8.  Acknowledgments
+
+   Many valuable suggestions were received from private discussions and
+   the IMAP4 mailing list.  In particular, Raymond Cheng, Mark Crispin,
+   Mark Keasling Chris Newman and Larry Osterman made significant
+   contributions to this document.
+
+9. Author's Address
+
+   Mike Gahrns
+   Microsoft
+   One Microsoft Way
+   Redmond, WA, 98072
+
+   Phone: (206) 936-9833
+   EMail: mikega@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gahrns                      Standards Track                     [Page 4]
+
+RFC 2221                 IMAP4 Login Referrals              October 1997
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1997).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implmentation may be prepared, copied, published
+   andand distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gahrns                      Standards Track                     [Page 5]
+
diff --git a/docs/rfcs/rfc2244.txt b/docs/rfcs/rfc2244.txt
new file mode 100644
index 0000000..ecf9492
--- /dev/null
+++ b/docs/rfcs/rfc2244.txt
@@ -0,0 +1,4035 @@
+
+
+
+
+
+
+Network Working Group                                          C. Newman
+Request for Comments: 2244                                      Innosoft
+Category: Standards Track                                    J. G. Myers
+                                                                Netscape
+                                                           November 1997
+
+
+           ACAP -- Application Configuration Access Protocol
+
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society 1997.  All Rights Reserved.
+
+Abstract
+
+   The Application Configuration Access Protocol (ACAP) is designed to
+   support remote storage and access of program option, configuration
+   and preference information.  The data store model is designed to
+   allow a client relatively simple access to interesting data, to allow
+   new information to be easily added without server re-configuration,
+   and to promote the use of both standardized data and custom or
+   proprietary data.  Key features include "inheritance" which can be
+   used to manage default values for configuration settings and access
+   control lists which allow interesting personal information to be
+   shared and group information to be restricted.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Myers              Standards Track                     [Page i]
+
+RFC 2244                          ACAP                     November 1997
+
+
+
+
+
+                           Table of Contents
+
+
+
+Status of this Memo ...............................................    i
+Copyright Notice ..................................................    i
+Abstract ..........................................................    i
+ACAP Protocol Specification .......................................    1
+1.       Introduction .............................................    1
+1.1.     Conventions Used in this Document ........................    1
+1.2.     ACAP Data Model ..........................................    1
+1.3.     ACAP Design Goals ........................................    1
+1.4.     Validation ...............................................    2
+1.5.     Definitions ..............................................    2
+1.6.     ACAP Command Overview ....................................    4
+2.       Protocol Framework .......................................    4
+2.1.     Link Level ...............................................    4
+2.2.     Commands and Responses ...................................    4
+2.2.1.   Client Protocol Sender and Server Protocol Receiver ......    4
+2.2.2.   Server Protocol Sender and Client Protocol Receiver ......    5
+2.3.     Server States ............................................    6
+2.3.1.   Non-Authenticated State ..................................    6
+2.3.2.   Authenticated State ......................................    6
+2.3.3.   Logout State .............................................    6
+2.4.     Operational Considerations ...............................    7
+2.4.1.   Untagged Status Updates ..................................    7
+2.4.2.   Response when No Command in Progress .....................    7
+2.4.3.   Auto-logout Timer ........................................    7
+2.4.4.   Multiple Commands in Progress ............................    8
+2.5.     Server Command Continuation Request ......................    8
+2.6.     Data Formats .............................................    8
+2.6.1.   Atom .....................................................    9
+2.6.2.   Number ...................................................    9
+2.6.3.   String ...................................................    9
+2.6.3.1. 8-bit and Binary Strings .................................   10
+2.6.4.   Parenthesized List .......................................   10
+2.6.5.   NIL ......................................................   10
+3.       Protocol Elements ........................................   10
+3.1.     Entries and Attributes ...................................   10
+3.1.1.   Predefined Attributes ....................................   11
+3.1.2.   Attribute Metadata .......................................   12
+3.2.     ACAP URL scheme ..........................................   13
+3.2.1.   ACAP URL User Name and Authentication Mechanism ..........   13
+3.2.2.   Relative ACAP URLs .......................................   14
+3.3.     Contexts .................................................   14
+
+
+
+Newman & Myers              Standards Track                    [Page ii]
+
+RFC 2244                          ACAP                     November 1997
+
+
+3.4.     Comparators ..............................................   15
+3.5.     Access Control Lists (ACLs) ..............................   17
+3.6.     Server Response Codes ....................................   18
+4.       Namespace Conventions ....................................   21
+4.1.     Dataset Namespace ........................................   21
+4.2.     Attribute Namespace ......................................   21
+4.3.     Formal Syntax for Dataset and Attribute Namespace ........   22
+5.       Dataset Management .......................................   23
+5.1.     Dataset Inheritance ......................................   23
+5.2.     Dataset Attributes .......................................   24
+5.3.     Dataset Creation .........................................   25
+5.4.     Dataset Class Capabilities ...............................   25
+5.5.     Dataset Quotas ...........................................   26
+6.       Command and Response Specifications ......................   26
+6.1.     Initial Connection .......................................   26
+6.1.1.   ACAP Untagged Response ...................................   26
+6.2.     Any State ................................................   27
+6.2.1.   NOOP Command .............................................   27
+6.2.2.   LANG Command .............................................   28
+6.2.3.   LANG Intermediate Response ...............................   28
+6.2.4.   LOGOUT Command ...........................................   29
+6.2.5.   OK Response ..............................................   29
+6.2.6.   NO Response ..............................................   29
+6.2.7.   BAD Response .............................................   30
+6.2.8.   BYE Untagged Response ....................................   30
+6.2.9.   ALERT Untagged Response ..................................   31
+6.3.     Non-Authenticated State ..................................   31
+6.3.1.   AUTHENTICATE Command .....................................   31
+6.4.     Searching ................................................   33
+6.4.1.   SEARCH Command ...........................................   33
+6.4.2.   ENTRY Intermediate Response ..............................   37
+6.4.3.   MODTIME Intermediate Response ............................   38
+6.4.4.   REFER Intermediate Response ..............................   38
+6.4.5.   Search Examples ..........................................   38
+6.5.     Contexts .................................................   39
+6.5.1.   FREECONTEXT Command ......................................   39
+6.5.2.   UPDATECONTEXT Command ....................................   40
+6.5.3.   ADDTO Untagged Response ..................................   40
+6.5.4.   REMOVEFROM Untagged Response .............................   41
+6.5.5.   CHANGE Untagged Response .................................   41
+6.5.6.   MODTIME Untagged Response ................................   42
+6.6.     Dataset modification .....................................   42
+6.6.1.   STORE Command ............................................   42
+6.6.2.   DELETEDSINCE Command .....................................   45
+6.6.3.   DELETED Intermediate Response ............................   45
+6.7.     Access Control List Commands .............................   45
+6.7.1.   SETACL Command ...........................................   46
+6.7.2.   DELETEACL Command ........................................   46
+
+
+
+Newman & Myers              Standards Track                   [Page iii]
+
+RFC 2244                          ACAP                     November 1997
+
+
+6.7.3.   MYRIGHTS Command .........................................   47
+6.7.4.   MYRIGHTS Intermediate Response ...........................   47
+6.7.5.   LISTRIGHTS Command .......................................   47
+6.7.6.   LISTRIGHTS Intermediate Response .........................   48
+6.8.     Quotas ...................................................   48
+6.8.1.   GETQUOTA Command .........................................   48
+6.8.3.   QUOTA Untagged Response ..................................   49
+6.9.     Extensions ...............................................   49
+7.       Registration Procedures ..................................   49
+7.1.     ACAP Capabilities ........................................   50
+7.2.     ACAP Response Codes ......................................   50
+7.3.     Dataset Classes ..........................................   51
+7.4.     Vendor Subtree ...........................................   51
+8.       Formal Syntax ............................................   52
+9.       Multi-lingual Considerations .............................   61
+10.      Security Considerations ..................................   62
+11.      Acknowledgments ..........................................   63
+12.      Authors' Addresses .......................................   63
+Appendices ........................................................   64
+A.       References ...............................................   64
+B.       ACAP Keyword Index .......................................   66
+C.       Full Copyright Statement
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page iv]
+RFC 2244                          ACAP                     November 1997
+
+
+ACAP Protocol Specification
+
+1.       Introduction
+
+1.1.     Conventions Used in this Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.  If such lines are wrapped without a new "C:" or
+   "S:" label, then the wrapping is for editorial clarity and is not
+   part of the command.
+
+   The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
+   and "MAY" in this document are to be interpreted as described in "Key
+   words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
+
+1.2.     ACAP Data Model
+
+   An ACAP server exports a hierarchical tree of entries.  Each level of
+   the tree is called a dataset, and each dataset is made up of a list
+   of entries.  Each entry has a unique name and may contain any number
+   of named attributes.  Each attribute within an entry may be single
+   valued or multi-valued and may have associated metadata to assist
+   access and interpretation of the value.
+
+   The rules with which a client interprets the data within a portion of
+   ACAP's tree of entries are called a dataset class.
+
+1.3.     ACAP Design Goals
+
+   ACAP's primary purpose is to allow users access to their
+   configuration data from multiple network-connected computers.  Users
+   can then sit down in front of any network-connected computer, run any
+   ACAP-enabled application and have access to their own configuration
+   data.  Because it is hoped that many applications will become ACAP-
+   enabled, client simplicity was preferred to server or protocol
+   simplicity whenever reasonable.
+
+   ACAP is designed to be easily manageable.  For this reason, it
+   includes "inheritance" which allows one dataset to inherit default
+   attributes from another dataset.  In addition, access control lists
+   are included to permit delegation of management and quotas are
+   included to control storage.  Finally, an ACAP server which is
+   conformant to this base specification should be able to support most
+   dataset classes defined in the future without requiring a server
+   reconfiguration or upgrade.
+
+
+
+
+
+
+Newman & Myers              Standards Track                     [Page 1]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   ACAP is designed to operate well with a client that only has
+   intermittent access to an ACAP server.  For this reason, each entry
+   has a server maintained modification time so that the client may
+   detect changes.  In addition, the client may ask the server for a
+   list of entries which have been removed since it last accessed the
+   server.
+
+   ACAP presumes that a dataset may be potentially large and/or the
+   client's network connection may be slow, and thus offers server
+   sorting, selective fetching and change notification for entries
+   within a dataset.
+
+   As required for most Internet protocols, security, scalability and
+   internationalization were important design goals.
+
+   Given these design goals, an attempt was made to keep ACAP as simple
+   as possible.  It is a traditional Internet text based protocol which
+   massively simplifies protocol debugging.  It was designed based on
+   the successful IMAP [IMAP4] protocol framework, with a few
+   refinements.
+
+1.4.     Validation
+
+   By default, any value may be stored in any attribute for which the
+   user has appropriate permission and quota.  This rule is necessary to
+   allow the addition of new simple dataset classes without
+   reconfiguring or upgrading the server.
+
+   In some cases, such as when the value has special meaning to the
+   server, it is useful to have the server enforce validation by
+   returning the INVALID response code to a STORE command. These cases
+   MUST be explicitly identified in the dataset class specification
+   which SHOULD include specific fixed rules for validation.  Since a
+   given ACAP server may be unaware of any particular dataset class
+   specification, clients MUST NOT depend on the presence of enforced
+   validation on the server.
+
+1.5.     Definitions
+
+
+   access control list (ACL)
+        A set of identifier, rights pairs associated with an object.  An
+        ACL is used to determine which operations a user is permitted to
+        perform on that object.  See section 3.5.
+
+   attribute
+        A named value within an entry.  See section 3.1.
+
+
+
+
+Newman & Myers              Standards Track                     [Page 2]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   comparator
+        A named function which can be used to perform one or more of
+        three comparison operations: ordering, equality and substring
+        matching.  See section 3.4.
+
+   context
+        An ordered subset of entries in a dataset, created by a SEARCH
+        command with a MAKECONTEXT modifier.  See section 3.3.
+
+   dataset
+        One level of hierarchy in ACAP's tree of entries.
+
+   dataset class specification
+        The rules which allow a client to interpret the data within a
+        portion of ACAP's tree of entries.
+
+   entry
+        A set of attributes with a unique entry name.  See section 3.1.
+
+   metadata
+        Information describing an attribute, its value and any access
+        controls associated with that attribute.  See section 3.1.2.
+
+   NIL  This represents the non-existence of a particular data item.
+
+   NUL  A control character encoded as 0 in US-ASCII [US-ASCII].
+
+   octet
+        An 8-bit value.  On most modern computer systems, an octet is
+        one byte.
+
+   SASL Simple Authentication and Security Layer [SASL].
+
+   UTC  Universal Coordinated Time as maintained by the Bureau
+        International des Poids et Mesures (BIPM).
+
+   UTF-8
+        An 8-bit transformation format of the Universal Character Set
+        [UTF8].  Note that an incompatible change was made to the coded
+        character set referenced by [UTF8], so for the purpose of this
+        document, UTF-8 refers to the UTF-8 encoding as defined by
+        version 2.0 of Unicode [UNICODE-2], or ISO 10646 [ISO-10646]
+        including amendments one through seven.
+
+
+
+
+
+
+
+
+Newman & Myers              Standards Track                     [Page 3]
+
+RFC 2244                          ACAP                     November 1997
+
+
+1.6.     ACAP Command Overview
+
+   The AUTHENTICATE, NOOP, LANG and LOGOUT commands provide basic
+   protocol services.  The SEARCH command is used to select, sort, fetch
+   and monitor changes to attribute values and metadata.  The
+   UPDATECONTEXT and FREECONTEXT commands are also used to assist in
+   monitoring changes in attribute values and metadata.  The STORE
+   command is used to add, modify and delete entries and attributes.
+   The DELETEDSINCE command is used to assist a client in
+   re-synchronizing a cache with the server.  The GETQUOTA, SETACL,
+   DELETEACL, LISTRIGHTS and MYRIGHTS commands are used to examine
+   storage quotas and examine or modify access permissions.
+
+2.       Protocol Framework
+
+2.1.     Link Level
+
+   The ACAP protocol assumes a reliable data stream such as provided by
+   TCP.  When TCP is used, an ACAP server listens on port 674.
+
+2.2.     Commands and Responses
+
+   An ACAP session consists of the establishment of a client/server
+   connection, an initial greeting from the server, and client/server
+   interactions.  These client/server interactions consist of a client
+   command, server data, and a server completion result.
+
+   ACAP is a text-based line-oriented protocol.  In general,
+   interactions transmitted by clients and servers are in the form of
+   lines; that is, sequences of characters that end with a CRLF.  The
+   protocol receiver of an ACAP client or server is either reading a
+   line, or is reading a sequence of octets with a known count (a
+   literal) followed by a line.  Both clients and servers must be
+   capable of handling lines of arbitrary length.
+
+2.2.1.   Client Protocol Sender and Server Protocol Receiver
+
+   The client command begins an operation.  Each client command is
+   prefixed with a identifier (an alphanumeric string of no more than 32
+   characters, e.g., A0001, A0002, etc.) called a "tag".  A different
+   tag SHOULD be generated by the client for each command.
+
+   There are two cases in which a line from the client does not
+   represent a complete command.  In one case, a command argument is
+   quoted with an octet count (see the description of literal in section
+   2.6.3); in the other case, the command arguments require server
+
+
+
+
+
+Newman & Myers              Standards Track                     [Page 4]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   feedback (see the AUTHENTICATE command).  In some of these cases, the
+   server sends a command continuation request if it is ready for the
+   next part of the command.  This response is prefixed with the token
+   "+".
+
+        Note: If, instead, the server detected an error in a
+        command, it sends a BAD completion response with tag
+        matching the command (as described below) to reject the
+        command and prevent the client from sending any more of the
+        command.
+
+        It is also possible for the server to send a completion or
+        intermediate response for some other command (if multiple
+        commands are in progress), or untagged data.  In either
+        case, the command continuation request is still pending;
+        the client takes the appropriate action for the response,
+        and reads another response from the server.
+
+   The ACAP server reads a command line from the client, parses the
+   command and its arguments, and transmits server data and a server
+   command completion result.
+
+2.2.2.   Server Protocol Sender and Client Protocol Receiver
+
+   Data transmitted by the server to the client come in four forms:
+   command continuation requests, command completion results,
+   intermediate responses, and untagged responses.
+
+   A command continuation request is prefixed with the token "+".
+
+   A command completion result indicates the success or failure of the
+   operation.  It is tagged with the same tag as the client command
+   which began the operation.  Thus, if more than one command is in
+   progress, the tag in a server completion response identifies the
+   command to which the response applies.  There are three possible
+   server completion responses: OK (indicating success), NO (indicating
+   failure), or BAD (indicating protocol error such as unrecognized
+   command or command syntax error).
+
+   An intermediate response returns data which can only be interpreted
+   within the context of a command in progress.  It is tagged with the
+   same tag as the client command which began the operation.  Thus, if
+   more than one command is in progress, the tag in an intermediate
+   response identifies the command to which the response applies.  A
+   tagged response other than "OK", "NO", or "BAD" is an intermediate
+   response.
+
+
+
+
+
+Newman & Myers              Standards Track                     [Page 5]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   An untagged response returns data or status messages which may be
+   interpreted outside the context of a command in progress.  It is
+   prefixed with the token "*".  Untagged data may be sent as a result
+   of a client command, or may be sent unilaterally by the server.
+   There is no syntactic difference between untagged data that resulted
+   from a specific command and untagged data that were sent
+   unilaterally.
+
+   The protocol receiver of an ACAP client reads a response line from
+   the server.  It then takes action on the response based upon the
+   first token of the response, which may be a tag, a "*", or a "+" as
+   described above.
+
+   A client MUST be prepared to accept any server response at all times.
+   This includes untagged data that it may not have requested.
+
+   This topic is discussed in greater detail in the Server Responses
+   section.
+
+2.3.     Server States
+
+   An ACAP server is in one of three states.  Most commands are valid in
+   only certain states.  It is a protocol error for the client to
+   attempt a command while the server is in an inappropriate state for
+   that command.  In this case, a server will respond with a BAD command
+   completion result.
+
+2.3.1.   Non-Authenticated State
+
+   In non-authenticated state, the user must supply authentication
+   credentials before most commands will be permitted.  This state is
+   entered when a connection starts.
+
+2.3.2.   Authenticated State
+
+   In authenticated state, the user is authenticated and most commands
+   will be permitted.  This state is entered when acceptable
+   authentication credentials have been provided.
+
+2.3.3.   Logout State
+
+   In logout state, the session is being terminated, and the server will
+   close the connection.  This state can be entered as a result of a
+   client request or by unilateral server decision.
+
+
+
+
+
+
+
+Newman & Myers              Standards Track                     [Page 6]
+
+RFC 2244                          ACAP                     November 1997
+
+
+            +--------------------------------------+
+            |initial connection and server greeting|
+            +--------------------------------------+
+                      || (1)                  || (2)
+                      VV                      ||
+            +-----------------+               ||
+            |non-authenticated|               ||
+            +-----------------+               ||
+             || (4)      || (3)               ||
+             ||          VV                   ||
+             ||          +----------------+   ||
+             ||          | authenticated  |   ||
+             ||          +----------------+   ||
+             ||            || (4)             ||
+             VV            VV                 VV
+            +--------------------------------------+
+            |     logout and close connection      |
+            +--------------------------------------+
+
+         (1) connection (ACAP greeting)
+         (2) rejected connection (BYE greeting)
+         (3) successful AUTHENTICATE command
+         (4) LOGOUT command, server shutdown, or connection closed
+
+2.4.     Operational Considerations
+
+2.4.1.   Untagged Status Updates
+
+   At any time, a server can send data that the client did not request.
+
+2.4.2.   Response when No Command in Progress
+
+   Server implementations are permitted to send an untagged response
+   while there is no command in progress.  Server implementations that
+   send such responses MUST deal with flow control considerations.
+   Specifically, they must either (1) verify that the size of the data
+   does not exceed the underlying transport's available window size, or
+   (2) use non-blocking writes.
+
+2.4.3.   Auto-logout Timer
+
+   If a server has an inactivity auto-logout timer, that timer MUST be
+   of at least 30 minutes duration.  The receipt of ANY command from the
+   client during that interval MUST suffice to reset the auto-logout
+   timer.
+
+
+
+
+
+
+Newman & Myers              Standards Track                     [Page 7]
+
+RFC 2244                          ACAP                     November 1997
+
+
+2.4.4.   Multiple Commands in Progress
+
+   The client is not required to wait for the completion result of a
+   command before sending another command, subject to flow control
+   constraints on the underlying data stream.  Similarly, a server is
+   not required to process a command to completion before beginning
+   processing of the next command, unless an ambiguity would result
+   because of a command that would affect the results of other commands.
+   If there is such an ambiguity, the server executes commands to
+   completion in the order given by the client.
+
+2.5.     Server Command Continuation Request
+
+   The command continuation request is indicated by a "+" token instead
+   of a tag.  This indicates that the server is ready to accept the
+   continuation of a command from the client.
+
+   This response is used in the AUTHENTICATE command to transmit server
+   data to the client, and request additional client data.  This
+   response is also used if an argument to any command is a
+   synchronizing literal (see section 2.6.3).
+
+   The client is not permitted to send the octets of a synchronizing
+   literal unless the server indicates that it expects it.  This permits
+   the server to process commands and reject errors on a line-by-line
+   basis, assuming it checks for non-synchronizing literals at the end
+   of each line.  The remainder of the command, including the CRLF that
+   terminates a command, follows the octets of the literal.  If there
+   are any additional command arguments the literal octets are followed
+   by a space and those arguments.
+
+   Example:    C: A099 FREECONTEXT {10}
+               S: + "Ready for additional command text"
+               C: FRED
+               C: FOOB
+               S: A099 OK "FREECONTEXT completed"
+               C: A044 BLURDYBLOOP {102856}
+               S: A044 BAD "No such command as 'BLURDYBLOOP'"
+
+
+2.6.     Data Formats
+
+   ACAP uses textual commands and responses.  Data in ACAP can be in one
+   of five forms: atom, number, string, parenthesized list or NIL.
+
+
+
+
+
+
+
+Newman & Myers              Standards Track                     [Page 8]
+
+RFC 2244                          ACAP                     November 1997
+
+
+2.6.1.   Atom
+
+   An atom consists of one to 1024 non-special characters.  It must
+   begin with a letter.  Atoms are used for protocol keywords.
+
+2.6.2.   Number
+
+   A number consists of one or more digit characters, and represents a
+   numeric value.  Numbers are restricted to the range of an unsigned
+   32-bit integer: 0 < number < 4,294,967,296.
+
+2.6.3.   String
+
+   A string is in one of two forms: literal and quoted string.  The
+   literal form is the general form of string.  The quoted string form
+   is an alternative that avoids the overhead of processing a literal at
+   the cost of restrictions of what may be in a quoted string.
+
+   A literal is a sequence of zero or more octets (including CR and LF),
+   prefix-quoted with an octet count in the form of an open brace ("{"),
+   the number of octets, close brace ("}"), and CRLF.  In the case of
+   literals transmitted from server to client, the CRLF is immediately
+   followed by the octet data.
+
+   There are two forms of literals transmitted from client to server.
+   The form where the open brace ("{") and number of octets is
+   immediately followed by a close brace ("}") and CRLF is called a
+   synchronizing literal.  When sending a synchronizing literal, the
+   client must wait to receive a command continuation request before
+   sending the octet data (and the remainder of the command).  The other
+   form of literal, the non-synchronizing literal, is used to transmit a
+   string from client to server without waiting for a command
+   continuation request.  The non-synchronizing literal differs from the
+   synchronizing literal by having a plus ("+") between the number of
+   octets and the close brace ("}") and by having the octet data
+   immediately following the CRLF.
+
+   A quoted string is a sequence of zero to 1024 octets excluding NUL,
+   CR and LF, with double quote (<">) characters at each end.
+
+   The empty string is represented as "" (a quoted string with zero
+   characters between double quotes), as {0} followed by CRLF (a
+   synchronizing literal with an octet count of 0), or as {0+} followed
+   by a CRLF (a non-synchronizing literal with an octet count of 0).
+
+        Note: Even if the octet count is 0, a client transmitting a
+        synchronizing literal must wait to receive a command
+        continuation request.
+
+
+
+Newman & Myers              Standards Track                     [Page 9]
+
+RFC 2244                          ACAP                     November 1997
+
+
+2.6.3.1. 8-bit and Binary Strings
+
+   Most strings in ACAP are restricted to UTF-8 characters and may not
+   contain NUL octets.  Attribute values MAY contain any octets
+   including NUL.
+
+2.6.4.   Parenthesized List
+
+   Data structures are represented as a "parenthesized list"; a sequence
+   of data items, delimited by space, and bounded at each end by
+   parentheses.  A parenthesized list can contain other parenthesized
+   lists, using multiple levels of parentheses to indicate nesting.
+
+   The empty list is represented as () -- a parenthesized list with no
+   members.
+
+2.6.5.   NIL
+
+   The special atom "NIL" represents the non-existence of a particular
+   data item that is represented as a string or parenthesized list, as
+   distinct from the empty string "" or the empty parenthesized list ().
+
+3.       Protocol Elements
+
+   This section defines data formats and other protocol elements used
+   throughout the ACAP protocol.
+
+3.1.     Entries and Attributes
+
+   Within a dataset, each entry name is made up of zero or more UTF-8
+   characters other than slash ("/").  A slash separated list of
+   entries, one at each level of the hierarchy, forms the full path to
+   an entry.
+
+   Each entry is made up of a set of attributes.  Each attribute has a
+   hierarchical name in UTF-8, with each component of the name separated
+   by a period (".").
+
+   The value of an attribute is either single or multi-valued.  A single
+   value is NIL (has no value), or a string of zero or more octets.  A
+   multi-value is a list of zero or more strings, each of zero or more
+   octets.
+
+   Attribute names are not permitted to contain asterisk ("*") or
+   percent ("%") and MUST be valid UTF-8 strings which do not contain
+   NUL.  Invalid attribute names result in a BAD response.  Entry names
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 10]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   are not permitted to begin with "." or contain slash ("/") and MUST
+   be valid UTF-8 strings which do not contain NUL.  Invalid entry names
+   in the entry field of a command result in a BAD response.
+
+   Use of non-visible UTF-8 characters in attribute and entry names is
+   discouraged.
+
+3.1.1.   Predefined Attributes
+
+   Attribute names which do not contain a dot (".") are reserved for
+   standardized attributes which have meaning in any dataset.  The
+   following attributes are defined by the ACAP protocol.
+
+   entry
+        Contains the name of the entry.  MUST be single valued.
+        Attempts to use illegal or multi-valued values for the entry
+        attribute are protocol errors and MUST result in a BAD
+        completion response.  This is a special case.
+
+   modtime
+        Contains the date and time any read-write metadata in the entry
+        was last modified.  This value MUST be in UTC, MUST be
+        automatically updated by the server.
+
+        The value consists of 14 or more US-ASCII digits.  The first
+        four indicate the year, the next two indicate the month, the
+        next two indicate the day of month, the next two indicate the
+        hour (0 - 23), the next two indicate the minute, and the next
+        two indicate the second.  Any further digits indicate fractions
+        of a second.
+
+        The time, particularly fractions of a second, need not be
+        accurate.  It is REQUIRED, however, that any two entries in a
+        dataset changed by successive modifications have strictly
+        ascending modtime values.  In addition, each STORE command
+        within a dataset (including simultaneous stores from different
+        connections) MUST use different modtime values.
+
+        This attribute has enforced validation, so any attempt to STORE
+        a value in this attribute MAY result in a NO response with an
+        INVALID response code.
+
+   subdataset
+        If this attribute is set, it indicates the existence of a sub-
+        dataset of this entry.
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 11]
+
+RFC 2244                          ACAP                     November 1997
+
+
+        The value consists of a list of relative ACAP URLs (see section
+        3.2) which may be used to locate the sub-dataset.  The base URL
+        is the full path to the entry followed by a slash ("/").  The
+        value "." indicates a subdataset is located directly under this
+        one.  Multiple values indicate replicated copies of the
+        subdataset.
+
+        For example, if the dataset "/folder/site/" has an entry
+        "public-folder" with a subdataset attribute of ".", then there
+        exists a dataset "/folder/site/public-folder/".  If the value of
+        the subdataset attribute was instead
+        "//other.acap.domain//folder/site/public-folder/", that would
+        indicate the dataset is actually located on a different ACAP
+        server.
+
+        A dataset can be created by storing a "subdataset" attribute
+        including ".", and a sub-hierarchy of datasets is deleted by
+        storing a NIL value to the "subdataset" attribute on the entry
+        in the parent dataset.
+
+        This attribute has enforced syntax validation.  Specifically, if
+        an attempt is made to STORE a non-list value (other than NIL),
+        an empty list, or one of the values does not follow the URL
+        syntax rules [BASIC-URL, REL-URL], then this will result in a NO
+        response with an INVALID response code.
+
+3.1.2.   Attribute Metadata
+
+   Each attribute is made up of metadata items which describe that
+   attribute, its value and any associated access controls.  Metadata
+   items may be either read-only, in which case the client is never
+   permitted to modify the item, or read-write, in which case the client
+   may modify the item if the access control list (ACL) permits.
+
+   The following metadata items are defined in this specification:
+
+   acl    The access control list for the attribute, if one exists.  If
+          the attribute does not have an ACL, NIL is returned.
+          Read-write.  See section 3.5 for the contents of an ACL.
+
+   attribute
+          The attribute name.  Read-only.
+
+   myrights
+          The set of rights that the client has to the attribute.
+          Read-only.  See section 3.5 for the possible rights.
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 12]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   size   This is the length of the value.  In the case of a
+          multi-value, this is a list of lengths for each of the values.
+          Read-only.
+
+   value  The value.  For a multi-value, this is a list of single
+          values.  Read-write.
+
+   Additional items of metadata may be defined in extensions to this
+   protocol.  Servers MUST respond to unrecognized metadata by returning
+   a BAD command completion result.
+
+3.2.     ACAP URL scheme
+
+   ACAP URLs are used within the ACAP protocol for the "subdataset"
+   attribute, referrals and inheritance.  They provide a convenient
+   syntax for referring to other ACAP datasets.  The ACAP URL follows
+   the common Internet scheme syntax as defined in [BASIC-URL] except
+   that plaintext passwords are not permitted.  If :<port> is omitted,
+   the port defaults to 674.
+
+   An ACAP URL has the following general form:
+
+   url-acap  = "acap://" url-server "/" url-enc-entry [url-filter]
+               [url-extension]
+
+   The <url-server> element includes the hostname, and optional user
+   name, authentication mechanism and port number.  The <url-enc-entry>
+   element contains the name of an entry path encoded according to the
+   rules in [BASIC-URL].
+
+   The <url-filter> element is an optional list of interesting attribute
+   names.  If omitted, the URL refers to all attributes of the named
+   entry.  The <url-extension> element is reserved for extensions to
+   this URL scheme.
+
+   Note that unsafe or reserved characters such as " " or "?" MUST be
+   hex encoded as described in the URL specification [BASIC-URL].  Hex
+   encoded octets are interpreted according to UTF-8 [UTF8].
+
+3.2.1.   ACAP URL User Name and Authentication Mechanism
+
+   A user name and/or authentication mechanism may be supplied.  They
+   are used in the "AUTHENTICATE" command after making the connection to
+   the ACAP server.  If no user name or authentication mechanism is
+   supplied, then the SASL ANONYMOUS [SASL-ANON] mechanism is used by
+   default.  If an authentication mechanism is supplied without a user
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 13]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   name, then one SHOULD be obtained from the specified mechanism or
+   requested from the user as appropriate.  If a user name is supplied
+   without an authentication mechanism then ";AUTH=*" is assumed.
+
+   The ";AUTH=" authentication parameter is interpreted as described in
+   the IMAP URL Scheme [IMAP-URL].
+
+   Note that if unsafe or reserved characters such as " " or ";" are
+   present in the user name or authentication mechanism, they MUST be
+   encoded as described in the URL specification [BASIC-URL].
+
+3.2.2.   Relative ACAP URLs
+
+   Because ACAP uses "/" as the hierarchy separator for dataset paths,
+   it works well with the relative URL rules defined in the relative URL
+   specification [REL-URL].
+
+   The <aauth> grammar element is considered part of the user name for
+   purposes of resolving relative ACAP URLs.
+
+   The base URL for a relative URL stored in an attribute's value is
+   formed by taking the path to the dataset containing that attribute,
+   appending a "/" followed by the entry name of the entry containing
+   that attribute followed by "/".
+
+3.3.     Contexts
+
+   A context is subset of entries in a dataset or datasets, created by a
+   SEARCH command with a MAKECONTEXT modifier.  Context names are
+   client-generated strings and must not start with the slash ('/')
+   character.
+
+   When a client creates a context, it may request automatic
+   notification of changes.  A client may also request enumeration of
+   entries within a context.  Enumeration simplifies the implementation
+   of a "virtual scrollbar" by the client.
+
+   A context exists only within the ACAP session in which it was
+   created.  When the connection is closed, all contexts associated with
+   that connection are automatically discarded.  A server is required to
+   support at least 100 active contexts within a session.  If the server
+   supports a larger limit it must advertise it in a CONTEXTLIMIT
+   capability.
+
+
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 14]
+
+RFC 2244                          ACAP                     November 1997
+
+
+3.4.     Comparators
+
+   A comparator is a named function which takes two input values and can
+   be used to perform one or more of four comparison operations:
+   ordering, equality, prefix and substring matching.
+
+   The ordering operation is used both for the SORT search modifier and
+   the COMPARE and COMPARESTRICT search keys.  Ordering comparators can
+   determine the ordinal precedence of any two values.  When used for
+   ordering, a comparator's name can be prefixed with "+" or "-" to
+   indicate that the ordering should be normal order or reversed order
+   respectively.  If no prefix is included, "+" is assumed.
+
+   For the purpose of ordering, a comparator may designate certain
+   values as having an undefined ordinal precedence.  Such values always
+   collate with equal value after all other values regardless of whether
+   normal or reversed ordering is used.  Unless the comparator
+   definition specifies otherwise, multi-values and NIL values have an
+   undefined ordinal precedence.
+
+   The equality operation is used for the EQUAL search modifier, and
+   simply determines if the two values are considered equal under the
+   comparator function.  When comparing a single value to a multi-value,
+   the two are considered equal if any one of the multiple values is
+   equal to the single value.
+
+   The prefix match operation is used for the PREFIX search modifier,
+   and simply determines if the search value is a prefix of the item
+   being searched.  In the case of prefix search on a multi-value, the
+   match is successful if the value is a prefix of any one of the
+   multiple values.
+
+   The substring match operation is used for the SUBSTRING search
+   modifier, and simply determines if search value is a substring of the
+   item being searched.  In the case of substring search on a multi-
+   value, the match is successful if the value is a substring of any one
+   of the multiple values.
+
+   Rules for naming and registering comparators will be defined in a
+   future specification.  Servers MUST respond to unknown or improperly
+   used comparators with a BAD command completion result.
+
+
+
+
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 15]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   The following comparators are defined by this standard and MUST be
+   implemented:
+
+      i;octet
+           Operations: Ordering, Equality, Prefix match, Substring match
+
+           For collation, the i;octet comparator interprets the value of
+           an attribute as a series of unsigned octets with ordinal
+           values from 0 to 255.  When ordering two strings, each octet
+           pair is compared in sequence until the octets are unequal or
+           the end of the string is reached.  When collating two strings
+           where the shorter is a prefix of the longer, the shorter
+           string is interpreted as having a smaller ordinal value.  The
+           "i;octet" or "+i;octet" forms collate smaller ordinal values
+           earlier, and the "-i;octet" form collates larger ordinal
+           values earlier.
+
+           For the equality function, two strings are equal if they are
+           the same length and contain the same octets in the same
+           order.  NIL is equal only to itself.
+
+           For non-binary, non-nil single values, i;octet ordering is
+           equivalent to the ANSI C [ISO-C] strcmp() function applied to
+           C string representations of the values.  For non-binary,
+           non-nil single values, i;octet substring match is equivalent
+           to the ANSI C strstr() function applied to the C string
+           representations of the values.
+
+      i;ascii-casemap
+           Operations: Ordering, Equality, Prefix match, Substring match
+
+           The i;ascii-casemap comparator first applies a mapping to the
+           attribute values which translates all US-ASCII letters to
+           uppercase (octet values 0x61 to 0x7A are translated to octet
+           values 0x41 to 0x5A respectively), then applies the i;octet
+           comparator as described above.  With this function the values
+           "hello" and "HELLO" have the same ordinal value and are
+           considered equal.
+
+      i;ascii-numeric
+           Operations: Ordering, Equality
+
+           The i;ascii-numeric comparator interprets strings as decimal
+           positive integers represented as US-ASCII digits.  All values
+           which do not begin with a US-ASCII digit are considered equal
+           with an ordinal value higher than all non-NIL single-valued
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 16]
+
+RFC 2244                          ACAP                     November 1997
+
+
+           attributes.  Otherwise, all US-ASCII digits (octet values
+           0x30 to 0x39) are interpreted starting from the beginning of
+           the string to the first non-digit or the end of the string.
+
+
+3.5.     Access Control Lists (ACLs)
+
+   An access control list is a set of identifier, rights pairs used to
+   restrict access to a given dataset, attribute or attribute within an
+   entry.  An ACL is represented by a multi-value with each value
+   containing an identifier followed by a tab character followed by the
+   rights.  The syntax is defined by the "acl" rule in the formal syntax
+   in section 8.
+
+   Identifier is a UTF-8 string.  The identifier "anyone" is reserved to
+   refer to the universal identity (all authentications, including
+   anonymous).  All user name strings accepted by the AUTHENTICATE
+   command to authenticate to the ACAP server are reserved as
+   identifiers for the corresponding user.  Identifiers starting with a
+   slash ("/") character are reserved for authorization groups which
+   will be defined in a future specification.  Identifiers MAY be
+   prefixed with a dash ("-") to indicate a revocation of rights.  All
+   other identifiers have implementation-defined meanings.
+
+   Rights is a string listing a (possibly empty) set of alphanumeric
+   characters, each character listing a set of operations which is being
+   controlled.  Letters are reserved for "standard" rights, listed
+   below.  The set of standard rights may only be extended by a
+   standards-track or IESG approved experimental RFC.  Digits are
+   reserved for implementation or site defined rights.  The currently
+   defined standard rights are:
+
+   x - search (use EQUAL search key with i;octet comparator)
+   r - read (access with SEARCH command)
+   w - write (modify with STORE command)
+   i - insert (perform STORE on a previously NIL value)
+   a - administer (perform SETACL or STORE on ACL attribute/metadata)
+
+   An implementation may force rights to always or never be granted.  In
+   particular, implementations are expected to grant implicit read and
+   administer rights to a user's personal dataset storage in order to
+   avoid denial of service problems.  Rights are never tied, unlike the
+   IMAP ACL extension [IMAP-ACL].
+
+   It is possible for multiple identifiers in an access control list to
+   apply to a given user (or other authentication identity).  For
+   example, an ACL may include rights to be granted to the identifier
+   matching the user, one or more implementation-defined identifiers
+
+
+
+Newman & Myers              Standards Track                    [Page 17]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   matching groups which include the user, and/or the identifier
+   "anyone".  These rights are combined by taking the union of all
+   positive rights which apply to a given user and subtracting the union
+   of all negative rights which apply to that user.  A client MAY avoid
+   this calculation by using the MYRIGHTS command and metadata items.
+
+   Each attribute of each entry of a dataset may potentially have an
+   ACL.  If an attribute in an entry does not have an ACL, then access
+   is controlled by a default ACL for that attribute in the dataset, if
+   it exists.  If there is no default ACL for that attribute in the
+   dataset, access is controlled by a default ACL for that dataset.  The
+   default ACL for a dataset must exist.
+
+   In order to perform any access or manipulation on an entry in a
+   dataset, the client must have 'r' rights on the "entry" attribute of
+   the entry.  Implementations should take care not to reveal via error
+   messages the existence of an entry for which the client does not have
+   'r' rights.  A client does not need access to the "subdataset"
+   attribute of the parent dataset in order to access the contents of a
+   dataset.
+
+   Many of the ACL commands and responses include an "acl object"
+   parameter, for specifying what the ACL applies to.  This is a
+   parenthesized list.  The list contains just the dataset name when
+   referring to the default ACL for a dataset.  The list contains a
+   dataset name and an attribute name when referring to the default ACL
+   for an attribute in a dataset.  The list contains a dataset name, an
+   attribute name, and an entry name when referring to the ACL for an
+   attribute of an entry of a dataset.
+
+
+3.6.     Server Response Codes
+
+   An OK, NO, BAD, ALERT or BYE response from the server MAY contain a
+   response code to describe the event in a more detailed machine
+   parsable fashion.  A response code consists of data inside
+   parentheses in the form of an atom, possibly followed by a space and
+   arguments.  Response codes are defined when there is a specific
+   action that a client can take based upon the additional information.
+   In order to support future extension, the response code is
+   represented as a slash-separated hierarchy with each level of
+   hierarchy representing increasing detail about the error.  Clients
+   MUST tolerate additional hierarchical response code detail which they
+   don't understand.
+
+   The currently defined response codes are:
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 18]
+
+RFC 2244                          ACAP                     November 1997
+
+
+      AUTH-TOO-WEAK
+           This response code is returned on a tagged NO result from an
+           AUTHENTICATE command.  It indicates that site security policy
+           forbids the use of the requested mechanism for the specified
+           authentication identity.
+
+      ENCRYPT-NEEDED
+           This response code is returned on a tagged NO result from an
+           AUTHENTICATE command.  It indicates that site security policy
+           requires the use of a strong encryption mechanism for the
+           specified authentication identity and mechanism.
+
+      INVALID
+           This response code indicates that a STORE command included
+           data which the server implementation does not permit.  It
+           MUST NOT be used unless the dataset class specification for
+           the attribute in question explicitly permits enforced server
+           validation.  The argument is the attribute which was invalid.
+
+      MODIFIED
+           This response code indicates that a conditional store failed
+           because the modtime on the entry is later than the modtime
+           specified with the STORE command UNCHANGEDSINCE modifier.
+           The argument is the entry which had been modified.
+
+      NOEXIST
+           This response code indicates that a search or NOCREATE store
+           failed because a specified dataset did not exist.  The
+           argument is the dataset which does not exist.
+
+      PERMISSION
+           A command failed due to insufficient permission based on the
+           access control list or implicit rights.  The argument is the
+           acl-object which caused the permission failure.
+
+      QUOTA
+           A STORE or SETACL command which would have increased the size
+           of the dataset failed due to insufficient quota.
+
+      REFER
+           This response code may be returned in a tagged NO response to
+           any command that takes a dataset name as a parameter.  It has
+           one or more arguments with the syntax of relative URLs.  It
+           is a referral, indicating that the command should be retried
+           using one of the relative URLs.
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 19]
+
+RFC 2244                          ACAP                     November 1997
+
+
+      SASL This response code can occur in the tagged OK response to a
+           successful AUTHENTICATE command and includes the optional
+           final server response data from the server as specified by
+           SASL [SASL].
+
+      TOOMANY
+           This response code may be returned in a tagged OK response to
+           a SEARCH command which includes the LIMIT modifier.  The
+           argument returns the total number of matching entries.
+
+      TOOOLD
+           The modtime specified in the DELETEDSINCE command is too old,
+           so deletedsince information is no longer available.
+
+      TRANSITION-NEEDED
+           This response code occurs on a NO response to an AUTHENTICATE
+           command.  It indicates that the user name is valid, but the
+           entry in the authentication database needs to be updated in
+           order to permit authentication with the specified mechanism.
+           This can happen if a user has an entry in a system
+           authentication database such as Unix /etc/passwd, but does
+           not have credentials suitable for use by the specified
+           mechanism.
+
+      TRYLATER
+           A command failed due to a temporary server failure.  The
+           client MAY continue using local information and try the
+           command later.
+
+      TRYFREECONTEXT
+           This response code may be returned in a tagged NO response to
+           a SEARCH command which includes the MAKECONTEXT modifier.  It
+           indicates that a new context may not be created due to the
+           server's limit on the number of existing contexts.
+
+      WAYTOOMANY
+           This response code may be returned in a tagged NO response to
+           a SEARCH command which includes a HARDLIMIT search modifier.
+           It indicates that the SEARCH would have returned more entries
+           than the HARDLIMIT permitted.
+
+      Additional response codes MUST be registered with IANA according
+      to the proceedures in section 7.2.  Client implementations MUST
+      tolerate response codes that they do not recognize.
+
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 20]
+
+RFC 2244                          ACAP                     November 1997
+
+
+4.       Namespace Conventions
+
+4.1.     Dataset Namespace
+
+   The dataset namespace is a slash-separated hierarchy.  The first
+   component of the dataset namespace is a dataset class.  Dataset
+   classes MUST have a vendor prefix (vendor.<vendor/product>) or be
+   specified in a standards track or IESG approved experimental RFC.
+   See section 7.3 for the registration template.
+
+   The second component of the dataset name is "site", "group", "host",
+   or "user" referring to server-wide data, administrative group data,
+   per-host data and per-user data respectively.
+
+   For "group", "host", and "user" areas, the third component of the
+   path is the group name, the fully qualified host domain name, or the
+   user name.  A path of the form "/<dataset-class>/~/" is a convenient
+   abbreviation for "/<dataset-class>/user/<current-user>/".
+
+   Dataset names which begin with "/byowner/" are reserved as an
+   alternate view of the namespace.  This provides a way to see all the
+   dataset classes which a particular owner uses.  For example,
+   "/byowner/~/<dataset-class>/" is an alternate name for
+   "/<dataset-class>/~/".  Byowner provides a way to view a list of
+   dataset classes owned by a given user; this is done using the dataset
+   "/byowner/user/<current-user>/" with the NOINHERIT SEARCH modifier.
+
+   The dataset "/" may be used to find all dataset classes visible to
+   the current user.  A dataset of the form "/<dataset-class>/user/" may
+   be used to find all users which have made a dataset or entry of that
+   class visible to the current user.
+
+   The formal syntax for a dataset name is defined by the "dataset-name"
+   rule in section 4.3.
+
+4.2.     Attribute Namespace
+
+   Attribute names which do not contain a dot (".") are reserved for
+   standardized attributes which have meaning in any dataset.  In order
+   to simplify client implementations, the attribute namespace is
+   intended to be unique across all datasets.  To achieve this,
+   attribute names are prefixed with the dataset class name followed by
+   a dot (".").  Attributes which affect management of the dataset are
+   prefixed with "dataset.".  In addition, a subtree of the "vendor."
+   attribute namespace may be registered with IANA according to the
+   rules in section 7.4.  ACAP implementors are encouraged to help
+   define interoperable dataset classes specifications rather than using
+   the private attribute namespace.
+
+
+
+Newman & Myers              Standards Track                    [Page 21]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   Some users or sites may wish to add their own private attributes to
+   certain dataset classes.  In order to enable this, the "user.<user-
+   name>." and "site." subtrees of the attribute namespace are reserved
+   for user-specific and site-specific attributes respectively and will
+   not be standardized.  Such attributes are not interoperable so are
+   discouraged in favor of defining standard attributes.  A future
+   extension is expected to permit discovery of syntax for user or
+   site-specific attributes.  Clients wishing to support display of user
+   or site-specific attributes should display the value of any non-NIL
+   single-valued "user.<user-name>." or "site."  attribute which has
+   valid UTF-8 syntax.
+
+   The formal syntax for an attribute name is defined by the
+   "attribute-name" rule in the next section.
+
+4.3.     Formal Syntax for Dataset and Attribute Namespace
+
+   The naming conventions for datasets and attributes are defined by the
+   following ABNF.   Note that this grammar is not part of the ACAP
+   protocol syntax in section 8, as dataset names and attribute names
+   are encoded as strings within the ACAP protocol.
+
+   attribute-dacl  = "dataset.acl" *("." name-component)
+
+   attribute-dset  = dataset-std 1*("." name-component)
+                     ;; MUST be defined in a dataset class specification
+
+   attribute-name  = attribute-std / attr-site / attr-user / vendor-name
+
+   attribute-std   = "entry" / "subdataset" / "modtime" /
+                     "dataset.inherit" / attribute-dacl / attribute-dset
+
+   attr-site       = "site" 1*("." name-component)
+
+   attr-user       = "user." name-component 1*("." name-component)
+
+   byowner         = "/byowner/" owner "/"
+                     [dataset-class "/" dataset-sub]
+
+   dataset-class   = dataset-std / vendor-name
+
+   dataset-normal  = "/" [dataset-class "/"
+                     (owner-prefix / dataset-tail)]
+
+   dataset-name    = byowner / dataset-normal
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 22]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   dataset-std     = name-component
+                     ;; MUST be registered with IANA and the spec MUST
+                     ;; be published as a standards track or
+                     ;; IESG-approved experimental RFC
+
+   dataset-sub     = *(dname-component "/")
+                     ;; The rules for this portion of the namespace may
+                     ;; be further restricted by the dataset class
+                     ;; specification.
+
+   dataset-tail    = owner "/" dataset-sub
+
+   dname-component = 1*UTF8-CHAR
+                     ;; MUST NOT begin with "." or contain "/"
+
+   name-component  = 1*UTF8-CHAR
+                     ;; MUST NOT contain ".", "/", "%", or "*"
+
+   owner           = "site" / owner-host / owner-group /
+                     owner-user / "~"
+
+   owner-group     = "group/" dname-component
+
+   owner-host      = "host/" dname-component
+
+   owner-prefix    = "group/" / "host/" / "user/"
+
+   owner-user      = "user/" dname-component
+
+   vendor-name     = vendor-token *("." name-component)
+
+   vendor-token    = "vendor." name-component
+                     ;; MUST be registered with IANA
+
+5.       Dataset Management
+
+   The entry with an empty name ("") in the dataset is used to hold
+   management information for the dataset as a whole.
+
+5.1.     Dataset Inheritance
+
+   It is possible for one dataset to inherit data from another.  The
+   dataset from which the data is inherited is called the base dataset.
+   Data in the base dataset appears in the inheriting dataset, except
+   when overridden by a STORE to the inheriting dataset.
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 23]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   The base dataset is usually a system-wide or group-wide set of
+   defaults.  A system-wide dataset usually has one inheriting dataset
+   per user, allowing each user to add to or modify the defaults as
+   appropriate.
+
+   An entry which exists in both the inheriting and base dataset
+   inherits a modtime equal to the greater of the two modtimes.  An
+   attribute in such an entry is inherited from the base dataset if it
+   was never modified by a STORE command in the inheriting dataset or if
+   DEFAULT was stored to that attribute.  This permits default entries
+   to be amended rather than replaced in the inheriting dataset.
+
+   The "subdataset" attribute is not directly inherited.  If the base
+   dataset includes a "subdataset" attribute and the inheriting dataset
+   does not, then the "subdataset" attribute will inherit a virtual
+   value of a list containing a ".".  The subdataset at that node is
+   said to be a "virtual" dataset as it is simply a virtual copy of the
+   appropriate base dataset with all "subdataset" attributes changed to
+   a list containing a ".".  A virtual dataset is not visible if
+   NOINHERIT is specified on the SEARCH command.
+
+   Servers MUST support at least two levels of inheritance.  This
+   permits a user's dataset such as "/options/user/fred/common" to
+   inherit from a group dataset such as "/options/group/dinosaur
+   operators/common" which in turn inherits from a server-wide dataset
+   such as "/options/site/common".
+
+5.2.     Dataset Attributes
+
+   The following attributes apply to management of the dataset when
+   stored in the "" entry of a dataset.  These attributes are not
+   inherited.
+
+   dataset.acl
+        This holds the default access control list for the dataset.
+        This attribute is validated, so an invalid access control list
+        in a STORE command will result in a NO response with an INVALID
+        response code.
+
+   dataset.acl.<attribute>
+        This holds the default access control list for an attribute
+        within the dataset.  This attribute is validated, so an invalid
+        access control list in a STORE command will result in a NO
+        response with an INVALID response code.
+
+   dataset.inherit
+        This holds the name of a dataset from which to inherit according
+        to the rules in the previous section.  This attribute MAY refer
+
+
+
+Newman & Myers              Standards Track                    [Page 24]
+
+RFC 2244                          ACAP                     November 1997
+
+
+        to a non-existent dataset, in which case nothing is inherited.
+        This attribute is validated, so illegal dataset syntax or an
+        attempt to store a multi-value will result in a NO response with
+        an INVALID response code.
+
+5.3.     Dataset Creation
+
+   When a dataset is first created (by storing a "." in the subdataset
+   attribute or storing an entry in a previously non-existent dataset),
+   the dataset attributes are initialized with the values from the
+   parent dataset in the "/byowner/" hierarchy.  In the case of the
+   "dataset.inherit" attribute, the appropriate hierarchy component is
+   added.  For example, given the following entry (note that \t refers
+   to the US-ASCII horizontal tab character):
+
+   entry path        "/byowner/user/joe/"
+   dataset.acl       ("joe\txrwia" "fred\txr")
+   dataset.inherit   "/byowner/site"
+
+   If a new dataset class "/byowner/user/joe/new" is created, it will
+   have the following dataset attributes:
+
+   entry path        "/byowner/user/joe/new/"
+   dataset.acl       ("joe\txrwia" "fred\txr")
+   dataset.inherit   "/byowner/site/new"
+
+   Note that the dataset "/byowner/user/joe/new/" is equivalent to
+   "/new/user/joe/".
+
+5.4.     Dataset Class Capabilities
+
+   Certain dataset classes or dataset class features may only be useful
+   if there is an active updating client or integrated server support
+   for the feature.  The dataset class "capability" is reserved to allow
+   clients or servers to advertise such features.  The "entry" attribute
+   within this dataset class is the name of the dataset class whose
+   features are being described.  The attributes are prefixed with
+   "capability.<dataset-class>." and are defined by the appropriate
+   dataset class specification.
+
+   Since it is possible for an unprivileged user to run an active client
+   for himself, a per-user capability dataset is useful.  The dataset
+   "/capability/~/" holds information about all features available to
+   the user (via inheritance), and the dataset "/capability/site/" holds
+   information about all features supported by the site.
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 25]
+
+RFC 2244                          ACAP                     November 1997
+
+
+5.5.     Dataset Quotas
+
+   Management and scope of quotas is implementation dependent.  Clients
+   can check the applicable quota limit and usage (in bytes) with the
+   GETQUOTA command.  Servers can notify the client of a low quota
+   situation with the QUOTA untagged response.
+
+6.       Command and Response Specifications
+
+   ACAP commands and responses are described in this section.  Commands
+   are organized first by the state in which the command is permitted,
+   then by a general category of command type.
+
+   Command arguments, identified by "Arguments:" in the command
+   descriptions below, are described by function, not by syntax.  The
+   precise syntax of command arguments is described in the Formal Syntax
+   section.
+
+   Some commands cause specific server data to be returned; these are
+   identified by "Data:" in the command descriptions below.  See the
+   response descriptions in the Responses section for information on
+   these responses, and the Formal Syntax section for the precise syntax
+   of these responses.  It is possible for server data to be transmitted
+   as a result of any command; thus, commands that do not specifically
+   require server data specify "no specific data for this command"
+   instead of "none".
+
+   The "Result:" in the command description refers to the possible
+   tagged status responses to a command, and any special interpretation
+   of these status responses.
+
+6.1.     Initial Connection
+
+   Upon session startup, the server sends one of two untagged responses:
+   ACAP or BYE.  The untagged BYE response is described in section
+   6.2.8.
+
+6.1.1.   ACAP Untagged Response
+
+   Data:       capability list
+
+      The untagged ACAP response indicates the session is ready to
+      accept commands and contains a space-separated listing of
+      capabilities that the server supports.  Each capability is
+      represented by a list containing the capability name optionally
+      followed by capability specific string arguments.
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 26]
+
+RFC 2244                          ACAP                     November 1997
+
+
+      ACAP capability names MUST be registered with IANA according to
+      the rules in section 7.1.
+
+      Client implementations SHOULD NOT require any capability name
+      beyond those defined in this specification, and MUST tolerate any
+      unknown capability names.  A client implementation MAY be
+      configurable to require SASL mechanisms other than CRAM-MD5
+      [CRAM-MD5] for site security policy reasons.
+
+      The following initial capabilities are defined:
+
+      CONTEXTLIMIT
+            The CONTEXTLIMIT capability has one argument which is a
+            number describing the maximum number of contexts the server
+            supports per connection.  The number 0 indicates the server
+            has no limit, otherwise this number MUST be greater than
+            100.
+
+      IMPLEMENTATION
+            The IMPLEMENTATION capability has one argument which is a
+            string describing the server implementation.  ACAP clients
+            MUST NOT alter their behavior based on this value.  It is
+            intended primarily for debugging purposes.
+
+      SASL  The SASL capability includes a list of the authentication
+            mechanisms supported by the server.  See section 6.3.1.
+
+
+   Example:    S: * ACAP (IMPLEMENTATION "ACME v3.5")
+                         (SASL "CRAM-MD5") (CONTEXTLIMIT "200")
+
+6.2.     Any State
+
+   The following commands and responses are valid in any state.
+
+6.2.1.   NOOP Command
+
+   Arguments:  none
+
+   Data:       no specific data for this command (but see below)
+
+   Result:     OK - noop completed
+               BAD - command unknown or arguments invalid
+
+      The NOOP command always succeeds.  It does nothing.  It can be
+      used to reset any inactivity auto-logout timer on the server.
+
+   Example:    C: a002 NOOP
+
+
+
+Newman & Myers              Standards Track                    [Page 27]
+
+RFC 2244                          ACAP                     November 1997
+
+
+               S: a002 OK "NOOP completed"
+
+
+6.2.2.   LANG Command
+
+   Arguments:  list of language preferences
+
+   Data:       intermediate response: LANG
+
+   Result:     OK - lang completed
+               NO - no matching language available
+               BAD - command unknown or arguments invalid
+
+      One or more arguments are supplied to indicate the client's
+      preferred languages [LANG-TAGS] for error messages.  The server
+      will match each client preference in order against its internal
+      table of available error string languages.  For a client
+      preference to match a server language, the client's language tag
+      MUST be a prefix of the server's tag and match up to a "-" or the
+      end of string.  If a match is found, the server returns an
+      intermediate LANG response and an OK response.  The LANG response
+      indicates the actual language selected and appropriate comparators
+      for use with the languages listed in the LANG command.
+
+      If no LANG command is issued, all error text strings MUST be in
+      the registered language "i-default" [CHARSET-LANG-POLICY],
+      intended for an international audience.
+
+   Example:    C: A003 LANG "fr-ca" "fr" "en-ca" "en-uk"
+               S: A003 LANG "fr-ca" "i;octet" "i;ascii-numeric"
+                       "i;ascii-casemap" "en;primary" "fr;primary"
+               S: A003 OK "Bonjour"
+
+
+6.2.3.   LANG Intermediate Response
+
+   Data:       language for error responses
+               appropriate comparators
+
+      The LANG response indicates the language which will be used for
+      error responses and the comparators which are appropriate for the
+      languages listed in the LANG command.  The comparators SHOULD be
+      in approximate order from most efficient (usually "i;octet") to
+      most appropriate for human text in the preferred language.
+
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 28]
+
+RFC 2244                          ACAP                     November 1997
+
+
+6.2.4.   LOGOUT Command
+
+   Arguments:  none
+
+   Data:       mandatory untagged response: BYE
+
+   Result:     OK - logout completed
+               BAD - command unknown or arguments invalid
+
+      The LOGOUT command informs the server that the client is done with
+      the session.  The server must send a BYE untagged response before
+      the (tagged) OK response, and then close the network connection.
+
+   Example:    C: A023 LOGOUT
+               S: * BYE "ACAP Server logging out"
+               S: A023 OK "LOGOUT completed"
+               (Server and client then close the connection)
+
+
+6.2.5.   OK Response
+
+   Data:       optional response code
+               human-readable text
+
+      The OK response indicates an information message from the server.
+      When tagged, it indicates successful completion of the associated
+      command.  The human-readable text may be presented to the user as
+      an information message.  The untagged form indicates an
+      information-only message; the nature of the information MAY be
+      indicated by a response code.
+
+   Example:    S: * OK "Master ACAP server is back up"
+
+
+6.2.6.   NO Response
+
+   Data:       optional response code
+               human-readable text
+
+      The NO response indicates an operational error message from the
+      server.  When tagged, it indicates unsuccessful completion of the
+      associated command.  The untagged form indicates a warning; the
+      command may still complete successfully.  The human-readable text
+      describes the condition.
+
+   Example:    C: A010 SEARCH "/addressbook/" DEPTH 3 RETURN ("*")
+                       EQUAL "entry" "+i;octet" "bozo"
+               S: * NO "Master ACAP server is down, your data may
+
+
+
+Newman & Myers              Standards Track                    [Page 29]
+
+RFC 2244                          ACAP                     November 1997
+
+
+                        be out of date."
+               S: A010 OK "search done"
+                  ...
+               C: A222 STORE ("/folder/site/comp.mail.misc"
+                              "folder.creation-time" "19951206103412")
+               S: A222 NO (PERMISSION ("/folder/site/")) "Permission
+               denied"
+
+
+6.2.7.   BAD Response
+
+   Data:       optional response code
+               human-readable text
+
+      The BAD response indicates an error message from the server.  When
+      tagged, it reports a protocol-level error in the client's command;
+      the tag indicates the command that caused the error.  The untagged
+      form indicates a protocol-level error for which the associated
+      command can not be determined; it may also indicate an internal
+      server failure.  The human-readable text describes the condition.
+
+   Example:    C: ...empty line...
+               S: * BAD "Empty command line"
+               C: A443 BLURDYBLOOP
+               S: A443 BAD "Unknown command"
+               C: A444 NOOP Hello
+               S: A444 BAD "invalid arguments"
+
+
+6.2.8.   BYE Untagged Response
+
+   Data:       optional response code
+               human-readable text
+
+      The untagged BYE response indicates that the server is about to
+      close the connection.  The human-readable text may be displayed to
+      the user in a status report by the client.  The BYE response 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
+      server implementations as an announcement of an inactivity auto-
+      logout.
+
+      This response is also used as one of two possible greetings at
+      session startup.  It indicates that the server is not willing to
+      accept a session from this client.
+
+   Example:    S: * BYE "Auto-logout; idle for too long"
+
+
+
+
+Newman & Myers              Standards Track                    [Page 30]
+
+RFC 2244                          ACAP                     November 1997
+
+
+6.2.9.   ALERT Untagged Response
+
+   Data:       optional response code
+               human-readable text
+
+      The human-readable text contains a special human generated alert
+      message that MUST be presented to the user in a fashion that calls
+      the user's attention to the message.  This is intended to be used
+      for vital messages from the server administrator to the user, such
+      as a warning that the server will soon be shut down for
+      maintenance.
+
+   Example:    S: * ALERT "This ACAP server will be shut down in
+                           10 minutes for system maintenance."
+
+
+6.3.     Non-Authenticated State
+
+   In non-authenticated state, the AUTHENTICATE command establishes
+   authentication and enters authenticated state.  The AUTHENTICATE
+   command provides a general mechanism for a variety of authentication
+   techniques.
+
+   Server implementations may allow non-authenticated access to certain
+   information by supporting the SASL ANONYMOUS [SASL-ANON] mechanism.
+
+   Once authenticated (including as anonymous), it is not possible to
+   re-enter non-authenticated state.
+
+   Only the any-state commands (NOOP, LANG and LOGOUT) and the
+   AUTHENTICATE command are valid in non-authenticated state.
+
+
+6.3.1.   AUTHENTICATE Command
+
+   Arguments:  SASL mechanism name
+               optional initial response
+
+   Data:       continuation data may be requested
+
+   Result:     OK - authenticate completed, now in authenticated state
+               NO - authenticate failure: unsupported authentication
+                    mechanism, credentials rejected
+               BAD - command unknown or arguments invalid,
+                    authentication exchange cancelled
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 31]
+
+RFC 2244                          ACAP                     November 1997
+
+
+      The AUTHENTICATE command indicates a SASL [SASL] authentication
+      mechanism to the server.  If the server supports the requested
+      authentication mechanism, it performs an authentication protocol
+      exchange to authenticate and identify the user.  Optionally, it
+      also negotiates a security layer for subsequent protocol
+      interactions.  If the requested authentication mechanism is not
+      supported, the server rejects the AUTHENTICATE command by sending
+      a tagged NO response.
+
+      The authentication protocol exchange consists of a series of
+      server challenges and client answers that are specific to the
+      authentication mechanism.  A server challenge consists of a
+      command continuation request with the "+" token followed by a
+      string.  The client answer consists of a line consisting of a
+      string.  If the client wishes to cancel an authentication
+      exchange, it should issue a line with a single unquoted "*".  If
+      the server receives such an answer, it must reject the
+      AUTHENTICATE command by sending a tagged BAD response.
+
+      The optional initial-response argument to the AUTHENTICATE command
+      is used to save a round trip when using authentication mechanisms
+      that are defined to send no data in the initial challenge.  When
+      the initial-response argument is used with such a mechanism, the
+      initial empty challenge is not sent to the client and the server
+      uses the data in the initial-response argument as if it were sent
+      in response to the empty challenge.  If the initial-response
+      argument to the AUTHENTICATE command is used with a mechanism that
+      sends data in the initial challenge, the server rejects the
+      AUTHENTICATE command by sending a tagged NO response.
+
+      The service name specified by this protocol's profile of SASL is
+      "acap".
+
+      If a security layer is negotiated through the SASL authentication
+      exchange, it takes effect immediately following the CRLF that
+      concludes the authentication exchange for the client, and the CRLF
+      of the tagged OK response for the server.
+
+      All ACAP implementations MUST implement the CRAM-MD5 SASL
+      mechanism [CRAM-MD5], although they MAY offer a configuration
+      option to disable it if site security policy dictates.  The
+      example below is the same example described in the CRAM-MD5
+      specification.
+
+      If an AUTHENTICATE command fails with a NO response, the client
+      may try another authentication mechanism by issuing another
+      AUTHENTICATE command.  In other words, the client may request
+      authentication types in decreasing order of preference.
+
+
+
+Newman & Myers              Standards Track                    [Page 32]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   Example:    S: * ACAP (IMPLEMENTATION "Blorfysoft v3.5")
+                         (SASL "CRAM-MD5" "KERBEROS_V4")
+               C: A001 AUTHENTICATE "CRAM-MD5"
+               S: + "<1896.697170952@postoffice.reston.mci.net>"
+               C: "tim b913a602c7eda7a495b4e6e7334d3890"
+               S: A001 OK "CRAM-MD5 authentication successful"
+
+
+6.4.     Searching
+
+   This section describes the SEARCH command, for retrieving data from
+   datasets.
+
+
+6.4.1.   SEARCH Command
+
+   Arguments:  dataset or context name
+               optional list of modifiers
+               search criteria
+
+   Data:       intermediate responses: ENTRY, MODTIME, REFER
+               untagged responses: ADDTO, REMOVEFROM, CHANGE, MODTIME
+
+   Result:     OK - search completed
+               NO - search failure: can't perform search
+               BAD - command unknown or arguments invalid
+
+      The SEARCH command identifies a subset of entries in a dataset and
+      returns information on that subset to the client.  Inherited
+      entries and attributes are included in the search unless the
+      NOINHERIT search modifier is included or the user does not have
+      permission to read the attributes in the base dataset.
+
+      The first argument to SEARCH identifies what is to be searched.
+      If the string begins with a slash ("/"), it is the name of a
+      dataset to be searched, otherwise it is a name of a context that
+      was created by a SEARCH command given previously in the session.
+
+      A successful SEARCH command MAY result in intermediate ENTRY
+      responses and MUST result in a MODTIME intermediate response.
+
+      Following that are zero or more modifiers to the search.  Each
+      modifier may be specified at most once.  The defined modifiers
+      are:
+
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 33]
+
+RFC 2244                          ACAP                     November 1997
+
+
+      DEPTH number
+           The SEARCH command will traverse the dataset tree up to the
+           specified depth.  ENTRY responses will include the full path
+           to the entry.  A value of "0" indicates that the search
+           should traverse the entire tree.  A value of "1" is the
+           default and indicates only the specified dataset should be
+           searched.  If a dataset is traversed which is not located on
+           the current server, then a REFER intermediate response is
+           returned for that subtree and the search continues.
+
+      HARDLIMIT number
+           If the SEARCH command would result in more than number
+           entries, the SEARCH fails with a NO completion result with a
+           WAYTOOMANY response code.
+
+      LIMIT number number
+           Limits the number of intermediate ENTRY responses that the
+           search may generate.  The first numeric argument specifies
+           the limit, the second number specifies the number of entries
+           to return if the number of matches exceeds the limit.  If the
+           limit is exceeded, the SEARCH command still succeeds,
+           returning the total number of matches in a TOOMANY response
+           code in the tagged OK response.
+
+      MAKECONTEXT [ENUMERATE] [NOTIFY] context
+           Causes the SEARCH command to create a context with the name
+           given in the argument to refer to the matching entries.  If
+           the SEARCH is successful, the context name may then be given
+           as an argument to subsequent SEARCH commands to search the
+           set of matching entries.  If a context with the specified
+           name already exists, it is first freed.  If a new context may
+           not be created due to the server's limit on the number of
+           existing contexts, the command fails, returning a
+           TRYFREECONTEXT response code in the NO completion response.
+
+           The optional "ENUMERATE" and "NOTIFY" arguments may be
+           included to request enumeration of the context (for virtual
+           scroll bars) or change notifications for the context.  If
+           "NOTIFY" is not requested, the context represents a snapshot
+           of the entries at the time the SEARCH was issued.
+
+           ENUMERATE requests that the contents of the context be
+           ordered according to the SORT modifier and that sequential
+           numbers, starting with one, be assigned to the entries in the
+           context.  This permits the RANGE modifier to be used to fetch
+           portions of the ordered context.
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 34]
+
+RFC 2244                          ACAP                     November 1997
+
+
+           NOTIFY requests that the server send untagged ADDTO,
+           REMOVEFROM, CHANGE, and MODTIME responses while the context
+           created by this SEARCH command exists.  The server MAY issue
+           untagged ADDTO, REMOVEFROM, CHANGE and MODTIME notifications
+           for a context at any time between the issuing of the SEARCH
+           command with MAKECONTEXT NOTIFY and the completion of a
+           FREECONTEXT command for the context.  Notifications are only
+           issued for changes which occur after the server receives the
+           SEARCH command which created the context.  After issuing a
+           sequence of ADDTO, REMOVEFROM or CHANGE notifications, the
+           server MUST issue an untagged MODTIME notification indicating
+           that the client has all updates to the entries in the context
+           up to and including the given modtime value.  Servers are
+           permitted a reasonable delay to batch change notifications
+           before sending them to the client.
+
+           The position arguments of the ADDTO, REMOVEFROM and CHANGE
+           notifications are 0 if ENUMERATE is not requested.
+
+      NOINHERIT
+           This causes the SEARCH command to operate without
+           inheritance.  It can be used to tell which values are
+           explicit overrides.  If MAKECONTEXT is also specified, the
+           created context is also not affected by inheritance.
+
+      RETURN (metadata...)
+           Specifies what is to be returned in intermediate ENTRY
+           responses.  If this modifier is not specified, no
+           intermediate ENTRY responses are returned.
+
+           Inside the parentheses is an optional list of attributes,
+           each optionally followed by a parenthesized list of metadata.
+           If the parenthesized list of metadata is not specified, it
+           defaults to "(value)".
+
+           An attribute name with a trailing "*" requests all attributes
+           with that prefix.  A "*" by itself requests all attributes.
+           If the parenthesized list of metadata is not specified for an
+           attribute with a trailing "*", it defaults to "(attribute
+           value)".  Results matching such an attribute pattern are
+           grouped in parentheses.
+
+           Following the last intermediate ENTRY response, the server
+           returns a single intermediate MODTIME response.
+
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 35]
+
+RFC 2244                          ACAP                     November 1997
+
+
+      SORT (attribute comparator ...)
+           Specifies the order in which any resulting ENTRY replies are
+           to be returned to the client.  The SORT modifier takes as an
+           argument a parenthesized list of one or more
+           attribute/comparator pairs.  Attribute lists the attribute to
+           sort on, comparator specifies the name of the collation rule
+           to apply to the values of the attribute.  Successive
+           attribute/comparator pairs are used to order two entries only
+           when all preceding pairs indicate the two entries collate the
+           same.
+
+           If the SORT modifier is used in conjunction with the
+           MAKECONTEXT modifier, the SORT modifier specifies the
+           ordering of entries in the created context.
+
+           If no SORT modifier is specified, or none of the
+           attribute/comparator pairs indicates an order for the two
+           entries, the server uses the order of the entries that exists
+           in the context or dataset being searched.
+
+
+      Following the modifiers is the search criteria.  Searching
+      criteria consist of one or more search keys.  Search keys may be
+      combined using the AND, and OR search keys.  For example, the
+      criteria (the newline is for readability and not part of the
+      criteria):
+          AND COMPARE "modtime" "+i;octet" "19951206103400"
+              COMPARE "modtime" "-i;octet" "19960112000000"
+      refers to all entries modified between 10:34 December 6 1995 and
+      midnight January 12, 1996 UTC.
+
+      The currently defined search keys are as follows.
+
+      ALL  This matches all entries.
+
+      AND search-key1 search-key2
+           Entries that match both search keys.
+
+      COMPARE attribute comparator value
+           Entries for which the value of the specified attribute
+           collates using the specified comparator the same or later
+           than the specified value.
+
+      COMPARESTRICT attribute comparator value
+           Entries for which the specified attribute collates using the
+           specified comparator later than the specified value.
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 36]
+
+RFC 2244                          ACAP                     November 1997
+
+
+      EQUAL attribute comparator value
+           Entries for which the value of the attribute is equal to the
+           specified value using the specified comparator.
+
+      NOT search-key
+           Entries that do not match the specified search key.
+
+      OR search-key1 search-key2
+           Entries that match either search key.
+
+      PREFIX attribute comparator value
+           Entries which begin with the specified value using the
+           specified comparator.  If the specified comparator doesn't
+           support substring matching, a BAD response is returned.
+
+      RANGE start end time
+           Entries which are within the specified range of the
+           enumerated context's ordering.  The lowest-ordered entry in
+           the context is assigned number one, the next lowest entry is
+           assigned number two, and so on.  The numeric arguments
+           specify the lowest and highest numbers to match. The time
+           specifies that the client has processed notifications for the
+           context up to the specified time.  If the context has been
+           modified since then, the server MUST either return a NO with
+           a MODIFIED response code, or return the results that the
+           SEARCH would have returned if none of the changes since that
+           time had been made.
+
+           RANGE is only permitted on enumerated contexts.  If RANGE is
+           used with a dataset or non-enumerated context, the server
+           MUST return a BAD response.
+
+      SUBSTRING attribute comparator value
+           Entries which contain the specified value, using the
+           specified comparator.  If the specified comparator doesn't
+           support substring matching, a BAD response is returned.
+
+
+6.4.2.   ENTRY Intermediate Response
+
+   Data:       entry name
+               entry data
+
+      The ENTRY intermediate response occurs as a result of a SEARCH or
+      STORE command. This is the means by which dataset entries are
+      returned to the client.
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 37]
+
+RFC 2244                          ACAP                     November 1997
+
+
+      The ENTRY response begins with the entry name, if a SEARCH command
+      without the DEPTH modifier was issued, or the entry path in other
+      cases.  This is followed by a set of zero or more items, one for
+      each metadata item in the RETURN search modifier.  Results
+      matching an attribute pattern or returning multiple metadata items
+      are grouped in parentheses.
+
+6.4.3.   MODTIME Intermediate Response
+
+   Data:       modtime value
+
+      The MODTIME intermediate response occurs as a result of a SEARCH
+      command.  It indicates that the just created context or the
+      previously returned ENTRY responses include all updates to the
+      returned entries up to and including the modtime value in the
+      argument.
+
+6.4.4.   REFER Intermediate Response
+
+   Data:       dataset path
+               relative ACAP URLs
+
+      The REFER intermediate response occurs as a result of a
+      multi-level SEARCH where one of the levels is located on a
+      different server.  The response indicates the dataset which is not
+      located on the current server and one or more relative ACAP URLs
+      for where that dataset may be found.
+
+6.4.5.   Search Examples
+
+   Here are some SEARCH command exchanges between the client and server:
+
+   C: A046 SEARCH "/addressbook/" DEPTH 3 RETURN ("addressbook.Alias"
+           "addressbook.Email" "addressbook.List") OR NOT EQUAL
+           "addressbook.Email" "i;octet" NIL NOT EQUAL
+           "addressbook.List" "i;octet" NIL
+   S: A046 ENTRY "/addressbook/user/joe/A0345" "fred"
+           "fred@stone.org" NIL
+   S: A046 ENTRY "/addressbook/user/fred/A0537" "joe" "joe@stone.org"
+           NIL
+   S: A046 ENTRY "/addressbook/group/Dinosaur Operators/A423"
+           "saurians" NIL "1"
+   S: A046 MODTIME "19970728105252"
+   S: A046 OK "SEARCH completed"
+
+   C: A047 SEARCH "/addressbook/user/fred/" RETURN ("*") EQUAL "entry"
+           "i;octet" "A0345"
+   S: A047 ENTRY "A0345" (("modtime" "19970728102226")
+
+
+
+Newman & Myers              Standards Track                    [Page 38]
+
+RFC 2244                          ACAP                     November 1997
+
+
+           ("addressbook.Alias" "fred") ("addressbook.Email"
+           "fred@stone.org") ("addressbook.CommonName"
+           "Fred Flintstone") ("addressbook.Surname" "Flintstone")
+           ("addressbook.GivenName" "Fred"))
+   S: A047 MODTIME "19970728105258"
+   S: A047 OK "SEARCH completed"
+
+   C: A048 SEARCH "/options/~/vendor.example/" RETURN
+           ("option.value"("size" "value" "myrights"))
+           SORT ("entry" "i;octet") COMPARE "modtime" "i;octet"
+           "19970727123225"
+   S: A048 ENTRY "blurdybloop" (5 "ghoti" "rwia")
+   S: A048 ENTRY "buckybits" (2 "10" "rwia")
+   S: A048 ENTRY "windowSize" (7 "100x100" "rwia")
+   S: A048 MODTIME "19970728105304"
+   S: A048 OK "SEARCH completed"
+
+   C: A049 SEARCH "/addressbook/~/public" RETURN ("addressbook.Alias"
+           "addressbook.Email") MAKECONTEXT ENUMERATE "blob" LIMIT 100 1
+           SORT ("addressbook.Alias" "i;octet") NOT EQUAL
+           "addressbook.Email" NIL
+   S: A049 ENTRY "A437" "aaguy" "aaguy@stone.org"
+   S: A049 MODTIME "19970728105308"
+   S: A049 OK (TOOMANY 347) "Context 'blob' created"
+
+   C: A050 SEARCH "blob" RANGE 2 2 "19970728105308" ALL
+   S: A050 ENTRY "A238" "abguy" "abguy@stone.org"
+   S: A050 MODTIME "19970728105310"
+   S: A050 OK "SEARCH Completed"
+
+6.5.     Contexts
+
+   The following commands use contexts created by a SEARCH command with
+   a MAKECONTEXT modifier.
+
+
+6.5.1.   FREECONTEXT Command
+
+   Arguments:  context name
+
+   Data:       no specific data for this command
+
+   Result:     OK - freecontext completed
+               NO - freecontext failure: no such context
+               BAD - command unknown or arguments invalid
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 39]
+
+RFC 2244                          ACAP                     November 1997
+
+
+      The FREECONTEXT command causes the server to free all state
+      associated with the named context.  The context may no longer be
+      searched and the server will no longer issue any untagged
+      responses for the context.  The context is no longer counted
+      against the server's limit on the number of contexts.
+
+   Example:    C: A683 FREECONTEXT "blurdybloop"
+               S: A683 OK "Freecontext completed"
+
+
+6.5.2.   UPDATECONTEXT Command
+
+   Arguments:  list of context names
+
+   Data:       untagged responses: ADDTO REMOVEFROM CHANGE MODTIME
+
+   Result:     OK - Updatecontext completed: all updates completed
+               NO - Updatecontext failed: no such context
+                                          not a notify context
+               BAD - command unknown or arguments invalid
+
+      The UPDATECONTEXT command causes the server to ensure that the
+      client is notified of all changes known to the server for the
+      contexts listed as arguments up to the current time.  The contexts
+      listed in the arguments must have been previously given to a
+      successful SEARCH command with a MAKECONTEXT NOTIFY modifier.  A
+      MODTIME untagged response MUST be returned if any read-write
+      metadata in the context changed since the last MODTIME for that
+      context.  This includes metadata which is not listed in the RETURN
+      modifier for the context.
+
+      While a server may issue untagged ADDTO, REMOVEFROM, CHANGE, and
+      MODTIME at any time, the UPDATECONTEXT command is used to "prod"
+      the server to send any notifications it has not sent yet.
+
+      The UPDATECONTEXT command SHOULD NOT be used to poll for updates.
+
+   Example:    C: Z4S9 UPDATECONTEXT "blurdybloop" "blarfl"
+               S: Z4S9 OK "client has been notified of all changes"
+
+
+6.5.3.   ADDTO Untagged Response
+
+   Data:       context name
+               entry name
+               position
+               metadata list
+
+
+
+
+Newman & Myers              Standards Track                    [Page 40]
+
+RFC 2244                          ACAP                     November 1997
+
+
+      The untagged ADDTO response informs the client that an entry has
+      been added to a context.  The response includes the position
+      number of the added entry (the first entry in the context is
+      numbered 1) and those metadata contained in the entry which match
+      the RETURN statement when the context was created.
+
+      For enumerated contexts, the ADDTO response implicitly adds one to
+      the position of all members of the context which had position
+      numbers that were greater than or equal to the ADDTO position
+      number.  For non-enumerated contexts, the position field is always
+      0.
+
+   Example:    S: * ADDTO "blurdybloop" "fred" 15
+                    ("addressbook.Email" "fred@stone.org")
+
+
+6.5.4.   REMOVEFROM Untagged Response
+
+   Data:       context name
+               entry name
+               old position
+
+      The untagged REMOVEFROM response informs the client that an entry
+      has been removed from a context.  The response includes the
+      position number that the removed entry used to have (the first
+      entry in the context is numbered 1).
+
+      For enumerated contexts, the REMOVEFROM response implicitly
+      subtracts one from the position numbers of all members of the
+      context which had position numbers greater than the REMOVEFROM
+      position number.  For non-enumerated contexts, the position field
+      is always 0.
+
+   Example:    S: * REMOVEFROM "blurdybloop" "fred" 15
+
+
+6.5.5.   CHANGE Untagged Response
+
+   Data:       context name
+               entry name
+               old position
+               new position
+               metadata list
+
+      The untagged CHANGE response informs the client that an entry in a
+      context has either changed position in the context or has changed
+      the values of one or more of the attributes specified in the
+      RETURN modifier when the context was created.
+
+
+
+Newman & Myers              Standards Track                    [Page 41]
+
+RFC 2244                          ACAP                     November 1997
+
+
+      The response includes the previous and current position numbers of
+      the entry (which are 0 if ENUMERATE was not specified on the
+      context) and the attribute metadata requested in the RETURN
+      modifier when the context was created.
+
+      For enumerated contexts, the CHANGE response implicitly changes
+      the position numbers of all entries which had position numbers
+      between the old and new position.  If old position is less than
+      new position, than one is subtracted from all entries which had
+      position numbers in that range.  Otherwise one is added to all
+      entries which had position numbers in that range.  If the old
+      position and new position are the same, then no implicit position
+      renumbering occurs.
+
+      CHANGE responses are not issued for entries which have changed
+      position implicitly due to another ADDTO, REMOVEFROM or CHANGE
+      response.
+
+   Example:    S: * CHANGE "blurdybloop" "fred" 15 10
+                    ("addressbook.Email" "fred@stone.org")
+
+
+6.5.6.   MODTIME Untagged Response
+
+   Data:       context name
+               modtime value
+
+      The untagged MODTIME response informs the client that it has
+      received all updates to entries in the context which have modtime
+      values less than or equal to the modtime value in the argument.
+
+   Example:    S: * MODTIME mycontext "19970320162338"
+
+6.6.     Dataset modification
+
+   The following commands and responses handle modification of datasets.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 42]
+
+RFC 2244                          ACAP                     November 1997
+
+
+6.6.1.   STORE Command
+
+   Arguments:  entry store list
+
+   Data:       intermediate responses: ENTRY
+
+   Result:     OK - store completed
+               NO - store failure: can't store that name
+                    UNCHANGEDSINCE specified and entry changed
+               BAD - command unknown or arguments invalid
+                     invalid UTF-8 syntax in attribute name
+
+
+      Creates, modifies, or deletes the named entries in the named
+      datasets.  The values of metadata not specified in the command are
+      not changed.  Setting the "value" metadata of an attribute to NIL
+      removes that attribute from the entry.  Setting the "value" of the
+      "entry" attribute to NIL removes that entry from the dataset and
+      cancels inheritance for the entire entry.  Setting the "value" of
+      the "entry" attribute to DEFAULT removes that entry from the
+      inheriting dataset and reverts the entry and its attributes to
+      inherited values, if any.  Changing the value of the "entry"
+      attribute renames the entry.
+
+      Storing DEFAULT to the "value" metadata of an attribute is
+      equivalent to storing NIL, except that inheritance is enabled for
+      that attribute.  If a non-NIL value is inherited then an ENTRY
+      intermediate response is generated to notify the client of the
+      this change.  The ENTRY response includes the entry-path and the
+      attribute name and value metadata for each attribute which
+      reverted to a non-NIL inherited setting.
+
+      Storing NIL to the "value" metadata of an attribute MAY be treated
+      equivalent to storing DEFAULT to that "value" if there is a NIL
+      value in the base dataset.
+
+      The STORE command is followed by one or more entry store lists.
+      Each entry store list begins with an entry path followed by STORE
+      modifiers, followed by zero or more attribute store items.  Each
+      attribute store item is made up of the attribute name followed by
+      NIL (to remove the attribute's value), DEFAULT (to revert the item
+      to any inherited value), a single value (to set the attribute's
+      single value), or a list of metadata items to modify.  The
+      following STORE modifiers may be specified:
+
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 43]
+
+RFC 2244                          ACAP                     November 1997
+
+
+      NOCREATE
+           By default, the server MUST create any datasets necessary to
+           store the entry, including multiple hierarchy levels.  If
+           NOCREATE is specified, the STORE command will fail with a
+           NOEXIST error unless the parent dataset already exists.
+
+      UNCHANGEDSINCE
+           If the "modtime" of the entry is later than the
+           unchangedsince time, then the store fails with a MODIFIED
+           response code.  Use of UNCHANGEDSINCE with a time of
+           "00000101000000" will always fail if the entry exists.
+           Clients writing to a shared dataset are encouraged to use
+           UNCHANGEDSINCE when modifying an existing entry.
+
+
+      The server MUST either make all the changes specified in a single
+      STORE command or make none of them.  If successful, the server
+      MUST update the "modtime" attribute for every entry which was
+      changed.
+
+      It is illegal to list any metadata item within an attribute twice,
+      any attribute within an entry twice or any entry path twice.  The
+      server MUST return a BAD response if this happens.
+
+      The server MAY re-order the strings in a multi-value on STORE and
+      MAY remove duplicate strings.  However, SEARCH MUST return multi-
+      values and the associated size list metadata in a consistant
+      order.
+
+
+   Example:    C: A342 STORE ("/addressbook/user/fred/ABC547"
+                       "addressbook.TelephoneNumber" "555-1234"
+                       "addressbook.CommonName" "Barney Rubble"
+                       "addressbook.AlternateNames" ("value"
+                       ("Barnacus Rubble" "Coco Puffs Thief"))
+                       "addressbook.Email" NIL)
+               S: A342 OK "Store completed"
+               C: A343 STORE ("/addressbook/user/joe/ABD42"
+                       UNCHANGEDSINCE "19970320162338"
+                       "user.joe.hair-length" "10 inches")
+               S: A343 NO (MODIFIED) "'ABD42' has been changed
+                       by somebody else."
+               C: A344 STORE ("/addressbook/group/Developers/ACD54"
+                       "entry" NIL)
+               S: A344 OK "Store completed"
+               C: A345 STORE ("/option/~/common/SMTPserver"
+                       "option.value" DEFAULT)
+               S: A345 ENTRY "/option/~/common/SMTPserver"
+
+
+
+Newman & Myers              Standards Track                    [Page 44]
+
+RFC 2244                          ACAP                     November 1997
+
+
+                       "option.value" "smtp.server.do.main"
+               S: A345 OK "Store completed"
+               C: A347 STORE ("/addressbook/~/" "dataset.inherit"
+                       "/addressbook/group/Developers")
+               S: A347 OK "Store completed"
+
+
+6.6.2.   DELETEDSINCE Command
+
+   Arguments:  dataset name
+               time
+
+   Data:       intermediate response: DELETED
+
+   Result:     OK - DELETEDSINCE completed
+               NO - DELETEDSINCE failure: can't read dataset
+                    date too far in the past
+               BAD - command unknown or arguments invalid
+
+      The DELETEDSINCE command returns in intermediate DELETED replies
+      the names of entries that have been deleted from the named dataset
+      since the given time.
+
+      Servers may impose a limit on the number or age of deleted entry
+      names they keep track of.  If the server does not have information
+      going back to the specified time, the command fails, returning a
+      TOOOLD response code in the tagged NO response.
+
+   Example:    C: Z4S9 DELETEDSINCE "/folder/site/" 19951205103412
+               S: Z4S9 DELETED "blurdybloop"
+               S: Z4S9 DELETED "anteaters"
+               S: Z4S9 OK "DELETEDSINCE completed"
+               C: Z4U3 DELETEDSINCE "/folder/site/" 19951009040854
+               S: Z4U3 NO (TOOOLD) "Don't have that information"
+
+
+6.6.3.   DELETED Intermediate Response
+
+   Data:       entry name
+
+      The intermediate DELETED response occurs as a result of a
+      DELETEDSINCE command. It returns an entry that has been deleted
+      from the dataset specified in the DELETEDSINCE command.
+
+6.7.     Access Control List Commands
+
+   The commands in this section are used to manage access control lists.
+
+
+
+
+Newman & Myers              Standards Track                    [Page 45]
+
+RFC 2244                          ACAP                     November 1997
+
+
+6.7.1.   SETACL Command
+
+   Arguments:  acl object
+               authentication identifier
+               access rights
+
+   Data:       no specific data for this command
+
+   Result:     OK - setacl completed
+               NO - setacl failure: can't set acl
+               BAD - command unknown or arguments invalid
+
+      The SETACL command changes the access control list on the
+      specified object so that the specified identifier is granted the
+      permissions enumerated in rights.  If the object did not
+      previously have an access control list, one is created.
+
+
+   Example:    C: A123 SETACL ("/addressbook/~/public/") "anyone" "r"
+               S: A123 OK "Setacl complete"
+               C: A124 SETACL ("/folder/site/") "B1FF" "rwa"
+               S: A124 NO (PERMISSION ("/folder/site/")) "'B1FF' not
+                       permitted to modify access rights
+                       for '/folder/site/'"
+
+
+
+6.7.2.   DELETEACL Command
+
+   Arguments:  acl object
+               optional authentication identifier
+
+   Data:       no specific data for this command
+
+   Result:     OK - deleteacl completed
+               NO - deleteacl failure: can't delete acl
+               BAD - command unknown or arguments invalid
+
+      If given the optional identifier argument, the DELETEACL command
+      removes any portion of the access control list on the specified
+      object for the specified identifier.
+
+      If not given the optional identifier argument, the DELETEACL
+      command removes the ACL from the object entirely, causing access
+      to be controlled by a higher-level default ACL.  This form of the
+      DELETEACL command is not permitted on the default ACL for a
+      dataset and servers MUST return a BAD.
+
+
+
+
+Newman & Myers              Standards Track                    [Page 46]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   Example:    C: A223 DELETEACL ("/addressbook/~/public") "anyone"
+               S: A223 OK "Deleteacl complete"
+               C: A224 DELETEACL ("/folder/site")
+               S: A224 BAD "Can't delete ACL from dataset"
+               C: A225 DELETEACL ("/addressbook/user/fred"
+                       "addressbook.Email" "barney")
+               S: A225 OK "Deleteacl complete"
+
+
+6.7.3.   MYRIGHTS Command
+
+   Arguments:  acl object
+
+   Data:       intermediate responses: MYRIGHTS
+
+   Result:     OK - myrights completed
+               NO - myrights failure: can't get rights
+               BAD - command unknown or arguments invalid
+
+      The MYRIGHTS command returns the set of rights that the client has
+      to the given dataset or dataset attribute.
+
+
+   Example:    C: A003 MYRIGHTS ("/folder/site")
+               S: A003 MYRIGHTS "r"
+               S: A003 OK "Myrights complete"
+
+
+6.7.4.   MYRIGHTS Intermediate Response
+
+   Data:       rights
+
+      The MYRIGHTS response occurs as a result of a MYRIGHTS command.
+      The argument is the set of rights that the client has for the
+      object referred to in the MYRIGHTS command.
+
+6.7.5.   LISTRIGHTS Command
+
+   Arguments:  acl object
+               authentication identifier
+
+   Data:       untagged responses: LISTRIGHTS
+
+   Result:     OK - listrights completed
+               NO - listrights failure: can't get rights list
+               BAD - command unknown or arguments invalid
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 47]
+
+RFC 2244                          ACAP                     November 1997
+
+
+      The LISTRIGHTS command takes an object and an identifier and
+      returns information about what rights the current user may revoke
+      or grant to that identifier in the ACL for that object.
+
+   Example:    C: a001 LISTRIGHTS ("/folder/~/") "smith"
+               S: a001 LISTRIGHTS "xra" "w" "i"
+               S: a001 OK Listrights completed
+               C: a005 LISTRIGHTS ("/folder/site/archive/imap") "anyone"
+               S: a005 LISTRIGHTS "" "x" "r" "w" "i"
+               S: a005 OK Listrights completed
+
+
+
+6.7.6.   LISTRIGHTS Intermediate Response
+
+   Data:       required rights
+               list of optional rights
+
+      The LISTRIGHTS response occurs as a result of a LISTRIGHTS
+      command.  The first argument is a string containing the (possibly
+      empty) set of rights the identifier will always be granted on the
+      dataset or attribute.
+
+      Following this are zero or more strings each containing a single
+      right which the current user may revoke or grant to the identifier
+      in the dataset or attribute.
+
+      The same right MUST NOT be listed more than once in the LISTRIGHTS
+      response.
+
+
+6.8.     Quotas
+
+   The section defines the commands and responses relating to quotas.
+
+
+6.8.1.   GETQUOTA Command
+
+   Arguments:  dataset
+
+   Data:       untagged responses: QUOTA
+
+   Result:     OK - Quota information returned
+               NO - Quota failure: can't access resource limit
+                                   no resource limit
+               BAD - command unknown or arguments invalid
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 48]
+
+RFC 2244                          ACAP                     November 1997
+
+
+      The GETQUOTA command takes the name of a dataset, and returns in
+      an untagged QUOTA response the name of the dataset, quota limit in
+      bytes that applies to that dataset and the quota usage within that
+      limit.  The scope of a quota limit is implementation dependent.
+
+   Example:    C: A043 GETQUOTA "/option/user/fred/common"
+               S: * QUOTA "/option/user/fred/common" 1048576 2475
+               S: A043 OK "Getquota completed"
+
+
+6.8.3.   QUOTA Untagged Response
+
+   Data:       dataset
+               quota limit in bytes
+               amount of quota limit used
+               extension data
+
+      The QUOTA untagged response is generated as a result of a GETQUOTA
+      command or MAY be generated by the server in response to a SEARCH
+      or STORE command to warn about high usage of a quota.  It includes
+      the name of the applicable dataset, the quota limit in bytes, the
+      quota usage and some optional extension data.  Clients MUST
+      tolerate the extension data as its use is reserved for a future
+      extension.
+
+6.9.     Extensions
+
+   In order to simplify the process of extending the protocol, clients
+   MUST tolerate unknown server responses which meet the syntax of
+   response-extend.  In addition, clients MUST tolerate unknown server
+   response codes which meet the syntax of resp-code-ext.  Availability
+   of new commands MUST be announced via a capability on the initial
+   greeting line and such commands SHOULD meet the syntax of
+   command-extend.
+
+   Servers MUST respond to unknown commands with a BAD command
+   completion result.  Servers MUST skip over non-synchronizing literals
+   contained in an unknown command.  This may be done by assuming the
+   unknown command matches the command-extend syntax, or by reading a
+   line at a time and checking for the non-synchronizing literal syntax
+   at the end of the line.
+
+7.       Registration Procedures
+
+   ACAP's usefulness comes from providing a structured storage model for
+   all sorts of configuration data.  However, for its potential to be
+   achieved, it is important that the Internet community strives for the
+   following goals:
+
+
+
+Newman & Myers              Standards Track                    [Page 49]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   (1) Standardization.  It is very important to standardize dataset
+   classes.  The authors hope that ACAP achieves the success that SNMP
+   has seen with the definition of numerous standards track MIBs.
+
+   (2) Community Review.  In the absence of standardization, it is
+   important to get community review on a proposal to improve its
+   engineering quality.  Community review is strongly recommended prior
+   to registration.  The ACAP implementors mailing list
+   <ietf-acap@andrew.cmu.edu> should be used for this purpose.
+
+   (3) Registration.  Registration serves a two-fold purpose.  First it
+   prevents use of the same name for different purposes, and second it
+   provides a one-stop list which can be used to locate existing
+   extensions or dataset classes to prevent duplicate work.
+
+   The following registration templates may be used to register ACAP
+   protocol elements with the Internet Assigned Numbers Authority
+   (IANA).
+
+7.1.     ACAP Capabilities
+
+   New ACAP capabilities MUST be registered prior to use.  Careful
+   consideration should be made before extending the protocol, as it can
+   lead to complexity or interoperability problems.  Review of proposals
+   on the acap implementors mailing list is strongly encouraged prior to
+   registration.
+
+   To: iana@iana.org
+   Subject: Registration of ACAP capability
+
+   Capability name:
+
+   Capability keyword:
+
+   Capability arguments:
+
+   Published Specification(s):
+
+   (Optional, but strongly encouraged)
+
+   Person and email address to contact for further information:
+
+7.2.     ACAP Response Codes
+
+   ACAP response codes are registered on a first come, first served
+   basis.  Review of proposals on the acap implementors mailing list is
+   strongly encouraged prior to registration.
+
+
+
+
+Newman & Myers              Standards Track                    [Page 50]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   To: iana@iana.org
+   Subject: Registration of ACAP response code
+
+   Response Code:
+
+   Arguments (use ABNF to specify syntax):
+
+   Purpose:
+
+   Published Specification(s):
+
+   (Optional, but strongly encouraged)
+
+   Person and email address to contact for further information:
+
+7.3.     Dataset Classes
+
+   A dataset class provides a core set of attributes for use in a
+   specified hierarchy.  It may also define rules for the dataset
+   hierarchy underneath that class.  Dataset class specifications must
+   be standards track or IESG approved experimental RFCs.
+
+   To: iana@iana.org
+   Subject: Registration of ACAP dataset class
+
+   Dataset class name/attribute prefix:
+
+   Purpose:
+
+   Published Specification(s):
+
+   (Standards track or IESG approved experimental RFC)
+
+   Person and email address to contact for further information:
+
+7.4.     Vendor Subtree
+
+   Vendors may reserve a portion of the ACAP namespace for private use.
+   Dataset class names beginning with "vendor.<company/product name>."
+   are reserved for use by that company or product.  In addition, all
+   attribute names beginning with "vendor.<company/product name>." are
+   reserved for use by that company or product once registered.
+   Registration is on a first come, first served basis.  Whenever
+   possible, private attributes and dataset classes should be avoided in
+   favor of improving interoperable dataset class definitions.
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 51]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   To: iana@iana.org
+   Subject: Registration of ACAP vendor subtree
+
+   Private Prefix: vendor.<company/product name>.
+
+   Person and email address to contact for further information:
+
+   (company names and addresses should be included when appropriate)
+
+8.       Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) notation as specified in [ABNF].  This uses the ABNF core
+   rules as specified in Appendix A of the ABNF specification [ABNF].
+
+   Except as noted otherwise, all alphabetic characters are
+   case-insensitive.  The use of upper or lower case characters to
+   define token strings is for editorial clarity only.  Implementations
+   MUST accept these strings in a case-insensitive fashion.
+
+   The "initial-greeting" rule below defines the initial ACAP greeting
+   from the server.  The "command" rule below defines the syntax for
+   commands sent by the client.  The "response" rule below defines the
+   syntax for responses sent by the server.
+
+   ATOM-CHAR          = "!" / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E
+                        ;; Any CHAR except ATOM-SPECIALS
+
+   ATOM-SPECIALS      = "(" / ")" / "{" / SP / CTL / QUOTED-SPECIALS
+
+   CHAR               = %x01-7F
+
+   DIGIT-NZ           = %x31-39
+                        ; non-zero digits ("1" - "9")
+
+   QUOTED-CHAR        = SAFE-UTF8-CHAR / "\" QUOTED-SPECIALS
+
+   QUOTED-SPECIALS    = <"> / "\"
+
+   SAFE-CHAR          = %x01-09 / %x0B-0C / %x0E-21 /
+                        %x23-5B / %x5D-7F
+                        ;; any TEXT-CHAR except QUOTED-SPECIALS
+
+   SAFE-UTF8-CHAR     = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4 /
+                        UTF8-5 / UTF8-6
+
+   TAG-CHAR           = %x21 / %x23-27 / %x2C-5B / %x5D-7A / %x7C-7E
+                        ;; Any ATOM-CHAR except "*" or "+"
+
+
+
+Newman & Myers              Standards Track                    [Page 52]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   TEXT-CHAR          = %x01-09 / %x0B-0C / %x0E-7F
+                        ;; any CHAR except CR and LF
+
+   TEXT-UTF8-CHAR     = SAFE-UTF8-CHAR / QUOTED-SPECIALS
+
+   UTF8-1             = %x80-BF
+
+   UTF8-2             = %xC0-DF UTF8-1
+
+   UTF8-3             = %xE0-EF 2UTF8-1
+
+   UTF8-4             = %xF0-F7 3UTF8-1
+
+   UTF8-5             = %xF8-FB 4UTF8-1
+
+   UTF8-6             = %xFC-FD 5UTF8-1
+
+   UTF8-CHAR          = TEXT-UTF8-CHAR / CR / LF
+
+   acl                = "(" [acl-identrights *(SP acl-identrights)] ")"
+                        *(SPACE acl-identrights)] ")"
+
+   acl-identifier     = string-utf8
+                        ;; MUST NOT contain HTAB
+
+   acl-identrights    = string-utf8
+                        ;; The identifier followed by a HTAB,
+                        ;; followed by the rights.
+
+   acl-delobject      = "(" dataset SP attribute [SP entry-name] ")"
+
+   acl-object         = "(" dataset [SP attribute [SP entry-name]] ")"
+
+   acl-rights         = quoted
+
+   atom               = ALPHA *1023ATOM-CHAR
+
+   attribute          = string-utf8
+                        ;; dot-separated attribute name
+                        ;; MUST NOT contain "*" or "%"
+
+   attribute-store    = attribute SP (value-nildef /
+                        "(" 1*(metadata-write-q SP value-store) ")")
+                        ;; MUST NOT include the same metadata twice
+
+   auth-type          = <"> auth-type-name <">
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 53]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   auth-type-name     = iana-token
+                        ;; as defined in SASL [SASL]
+
+   command            = tag SP (command-any / command-auth /
+                        command-nonauth) CRLF
+                        ;; Modal based on state
+
+   command-authent    = "AUTHENTICATE" SP auth-type
+                        [SP string] *(CRLF string)
+
+   command-any        = "NOOP" / command-lang / "LOGOUT" /
+                        command-extend
+
+   command-auth       = command-delacl / command-dsince /
+                        command-freectx / command-getquota /
+                        command-lrights / command-myrights /
+                        command-search / command-setacl /
+                        command-store
+                        ;; only valid in authenticated state
+
+   command-delacl     = "DELETEACL" SP acl-delobject [SP acl-identifier]
+
+   command-dsince     = "DELETEDSINCE" SP dataset SP time
+
+   command-extend     = extend-token [SP extension-data]
+
+   command-freectx    = "FREECONTEXT" SP context
+
+   command-getquota   = "GETQUOTA" SP dataset
+
+   command-lang       = "LANG" *(SP lang-tag)
+
+   command-lrights    = "LISTRIGHTS" SP acl-object
+
+   command-myrights   = "MYRIGHTS" SP acl-object
+
+   command-nonauth    = command-authent
+                        ;; only valid in non-authenticated state
+
+   command-search     = "SEARCH" SP (dataset / context)
+                        *(SP search-modifier) SP search-criteria
+                        ;; MUST NOT include same search-modifier twice
+
+   command-setacl     = "SETACL" SP acl-object SP acl-identifier
+                        SP acl-rights
+
+   command-store      = "STORE" SP store-entry-list
+
+
+
+
+Newman & Myers              Standards Track                    [Page 54]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   comparator         = <"> comparator-name <">
+
+   comparator-name    = ["+" / "-"] iana-token
+
+   context            = string-utf8
+                        ;; MUST NOT begin with slash ("/")
+
+   dataset            = string-utf8
+                        ;; slash-separated dataset name
+                        ;; begins with slash
+
+   entry              = entry-name / entry-path
+
+   entry-name         = string-utf8
+                        ;; entry name MUST NOT contain slash
+                        ;; MUST NOT begin with "."
+
+   entry-path         = string-utf8
+                        ;; slash-separated path to entry
+                        ;; begins with slash
+
+   entry-relative     = string-utf8
+                        ;; potentially relative path to entry
+
+   extend-token       = atom
+                        ;; MUST be defined by a standards track or
+                        ;; IESG approved experimental protocol extension
+
+   extension-data     = extension-item *(SP extension-item)
+
+   extension-item     = extend-token / string / number /
+                        "(" [extension-data] ")"
+
+   iana-token         = atom
+                        ;; MUST be registered with IANA
+
+   initial-greeting   = "*" SP "ACAP" *(SP "(" init-capability ")") CRLF
+
+   init-capability    = init-cap-context / init-cap-extend /
+                        init-cap-implem / init-cap-sasl
+
+   init-cap-context   = "CONTEXTLIMIT" SP string
+
+   init-cap-extend    = iana-token [SP string-list]
+
+   init-cap-implem    = "IMPLEMENTATION" SP string
+
+   init-cap-sasl      = "SASL" SP string-list
+
+
+
+Newman & Myers              Standards Track                    [Page 55]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   lang-tag           = <"> Language-Tag <">
+                        ;; Language-Tag rule is defined in [LANG-TAGS]
+
+   literal            = "{" number [ "+" ] "}" CRLF *OCTET
+                        ;; The number represents the number of octets
+                        ;; MUST be literal-utf8 except for values
+
+   literal-utf8       = "{" number [ "+" ] "}" CRLF *UTF8-CHAR
+                        ;; The number represents the number of octets
+                        ;; not the number of characters
+
+   metadata           = attribute [ "(" metadata-type-list ")" ]
+                        ;; attribute MAY end in "*" as wildcard.
+
+   metadata-list      = metadata *(SP metadata)
+
+   metadata-type      = "attribute" / "myrights" / "size" /
+                        "count" / metadata-write
+
+   metadata-type-q    = <"> metadata-type <">
+
+   metadata-type-list = metadata-type-q *(SP metadata-type-q)
+
+   metadata-write     = "value" / "acl"
+
+   metadata-write-q   = <"> metadata-write <">
+
+   nil                = "NIL"
+
+   number             = *DIGIT
+                        ;; A 32-bit unsigned number.
+                        ;; (0 <= n < 4,294,967,296)
+
+   nz-number          = DIGIT-NZ *DIGIT
+                        ;; A 32-bit unsigned non-zero number.
+                        ;; (0 < n < 4,294,967,296)
+
+   position           = number
+                        ;; "0" if context is not enumerated
+                        ;; otherwise this is non-zero
+
+   quota-limit        = number
+
+   quota-usage        = number
+
+   quoted             = <"> *QUOTED-CHAR <">
+                        ;; limited to 1024 octets between the <">s
+
+
+
+
+Newman & Myers              Standards Track                    [Page 56]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   response           = response-addto / response-alert / response-bye /
+                        response-change / response-cont /
+                        response-deleted / response-done /
+                        response-entry / response-extend /
+                        response-listr / response-lang /
+                        response-mtimei / response-mtimeu /
+                        response-myright / response-quota /
+                        response-refer / response-remove / response-stat
+
+   response-addto     = "*" SP "ADDTO" SP context SP entry-name
+                        SP position SP return-data-list
+
+   response-alert     = "*" SP "ALERT" SP resp-body CRLF
+                       ;; Client MUST display alert text to user
+
+   response-bye       = "*" SP "BYE" SP resp-body CRLF
+                       ;; Server will disconnect condition
+
+   response-change    = "*" SP "CHANGE" SP context SP entry-name
+                        SP position SP position SP return-data-list
+
+   response-cont      = "+" SP string
+
+   response-deleted   = tag SP "DELETED" SP entry-name
+
+   response-done      = tag SP resp-cond-state CRLF
+
+   response-entry     = tag SP "ENTRY" SP entry SP return-data-list
+
+   response-extend    = (tag / "*") SP extend-token [SP extension-data]
+
+   response-lang      = "*" SP "LANG" SP lang-tag 1*(SP comparator)
+
+   response-listr     = tag SP "LISTRIGHTS" SP acl-rights
+                        *(SP acl-rights)
+
+   response-mtimei    = tag SP "MODTIME" SP time
+
+   response-mtimeu    = "*" SP "MODTIME" SP context SP time
+
+   response-myright   = tag SP "MYRIGHTS" SP acl-rights
+
+   response-quota     = "*" SP "QUOTA" SP dataset SP quota-limit
+                        SP quota-usage [SP extension-data]
+
+   response-refer     = tag SP "REFER" SP dataset
+                        1*(SP <"> url-relative <">)
+
+
+
+
+Newman & Myers              Standards Track                    [Page 57]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   response-remove    = "*" SP "REMOVEFROM" SP context SP
+                        entry-name SP position
+
+   response-stat      = "*" SP resp-cond-state CRLF
+
+   resp-body          = ["(" resp-code ")" SP] quoted
+
+   resp-code          = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" /
+                        resp-code-inval / resp-code-mod /
+                        resp-code-noexist / resp-code-perm / "QUOTA" /
+                        resp-code-refer / resp-code-sasl /
+                        resp-code-toomany / "TOOOLD" /
+                        "TRANSITION-NEEDED" / "TRYFREECONTEXT" /
+                        "TRYLATER" / "WAYTOOMANY" / resp-code-ext
+
+   resp-code-ext      = iana-token [SP extension-data]
+                        ;; unknown codes MUST be tolerated by the client
+
+   resp-code-inval    = "INVALID" 1*(SP entry-path SP attribute)
+
+   resp-code-mod      = "MODIFIED" SP entry-path
+
+   resp-code-noexist  = "NOEXIST" SP dataset
+
+   resp-code-perm     = "PERMISSION" SP acl-object
+
+   resp-code-refer    = "REFER" 1*(SP <"> url-relative <">)
+
+   resp-code-sasl     = "SASL" SP string
+
+   resp-code-toomany  = "TOOMANY" SP nz-number
+
+   resp-cond-state    = ("OK" / "NO" / "BAD") SP resp-body
+                        ;; Status condition
+
+   return-attr-list   = "(" return-metalist *(SP return-metalist) ")"
+                        ;; occurs when "*" in RETURN pattern on SEARCH
+
+   return-data        = return-metadata / return-metalist /
+                        return-attr-list
+
+   return-data-list   = return-data *(SP return-data)
+
+   return-metalist    = "(" return-metadata *(SP return-metadata) ")"
+                        ;; occurs when multiple metadata items requested
+
+   return-metadata    = nil / string / value-list / acl
+
+
+
+
+Newman & Myers              Standards Track                    [Page 58]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   searchkey-equal    = "EQUAL" SP attribute SP comparator SP value-nil
+
+   searchkey-comp     = "COMPARE" SP attribute SP comparator SP value
+
+   searchkey-prefix   = "PREFIX" SP attribute SP comparator SP value
+
+   searchkey-range    = "RANGE" SP nz-number SP nz-number SP time
+
+   searchkey-strict   = "COMPARESTRICT" SP attribute SP comparator
+                        SP value
+
+   searchkey-substr   = "SUBSTRING" SP attribute SP comparator SP value
+
+   searchmod-depth    = "DEPTH" SP number
+
+   searchmod-hard     = "HARDLIMIT" SP nz-number
+
+   searchmod-limit    = "LIMIT" SP number SP number
+
+   searchmod-make     = "MAKECONTEXT" [SP "ENUMERATE"]
+                        [SP "NOTIFY"] SP context
+
+   searchmod-ninh     = "NOINHERIT"
+
+   searchmod-return   = "RETURN" SP "(" [metadata-list] ")"
+
+   searchmod-sort     = "SORT" SP "(" sort-list ")"
+
+   search-criteria    = "ALL" / searchkey-equal / searchkey-comp /
+                        searchkey-strict / searchkey-range /
+                        searchkey-prefix / searchkey-substr /
+                        "NOT" SP search-criteria /
+                        "OR" SP search-criteria SP search-criteria /
+                        "AND" SP search-criteria SP search-criteria
+
+   search-modifier    = searchmod-depth / searchmod-hard /
+                        searchmod-limit / searchmod-make /
+                        searchmod-ninh / searchmod-return /
+                        searchmod-sort
+
+   sort-list          = sort-item *(SP sort-item)
+
+   sort-item          = attribute SP comparator
+
+   store-entry        = "(" entry-path *(SP store-modifier)
+                            *(SP attribute-store) ")"
+                        ;; MUST NOT include same store-modifier twice
+                        ;; MUST NOT include same attribute twice
+
+
+
+Newman & Myers              Standards Track                    [Page 59]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   store-entry-list   = store-entry *(SP store-entry)
+                        ;; MUST NOT include same entry twice
+
+   store-modifier     = store-mod-unchang / store-mod-nocreate
+
+   store-mod-nocreate = "NOCREATE"
+
+   store-mod-unchang  = "UNCHANGEDSINCE" SP time
+
+   string             = quoted / literal
+
+   string-list        = string *(SP string)
+
+   string-utf8        = quoted / literal-utf8
+
+   tag                = 1*32TAG-CHAR
+
+   time               = <"> time-year time-month time-day time-hour
+                        time-minute time-second time-subsecond <">
+                        ;; Timestamp in UTC
+
+   time-day           = 2DIGIT ;; 01-31
+
+   time-hour          = 2DIGIT ;; 00-23
+
+   time-minute        = 2DIGIT ;; 00-59
+
+   time-month         = 2DIGIT ;; 01-12
+
+   time-second        = 2DIGIT ;; 00-60
+
+   time-subsecond     = *DIGIT
+
+   time-year          = 4DIGIT
+
+   value              = string
+
+   value-list         = "(" [value *(SP value)] ")"
+
+   value-nil          = value / nil
+
+   value-nildef       = value-nil / "DEFAULT"
+
+   value-store        = value-nildef / value-list / acl
+
+   url-acap           = "acap://" url-server "/" url-enc-entry
+                        [url-filter] [url-extension]
+                        ;; url-enc-entry interpreted relative to "/"
+
+
+
+Newman & Myers              Standards Track                    [Page 60]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   url-attr-list      = url-enc-attr *("&" url-enc-attr)
+
+   url-auth           = ";AUTH=" ("*" / url-enc-auth)
+
+   url-achar          = uchar / "&" / "=" / "~"
+                        ;; See RFC 1738 for definition of "uchar"
+
+   url-char           = uchar / "=" / "~" / ":" / "@" / "/"
+                        ;; See RFC 1738 for definition of "uchar"
+
+   url-enc-attr       = 1*url-char
+                        ;; encoded version of attribute name
+
+   url-enc-auth       = 1*url-achar
+                        ;; encoded version of auth-type-name above
+
+   url-enc-entry      = 1*url-char
+                        ;; encoded version of entry-relative above
+
+   url-enc-user       = *url-achar
+                        ;; encoded version of login userid
+
+   url-extension      = *("?" 1*url-char)
+
+   url-filter         = "?" url-attr-list
+
+   url-relative       = url-acap / [url-enc-entry] [url-filter]
+                        ;; url-enc-entry is relative to base URL
+
+   url-server         = [url-enc-user [url-auth] "@"] hostport
+                        ;; See RFC 1738 for definition of "hostport"
+
+9.       Multi-lingual Considerations
+
+   The IAB charset workshop [IAB-CHARSET] came to a number of
+   conclusions which influenced the design of ACAP.  The decision to use
+   UTF-8 as the character encoding scheme was based on that work.  The
+   LANG command to negotiate a language for error messages is also
+   included.
+
+   Section 3.4.5 of the IAB charset workshop report states that there
+   should be a way to identify the natural language for human readable
+   strings.  Several promising proposals have been made for use within
+   ACAP, but no clear consensus on a single method is apparent at this
+   stage.  The following rules are likely to permit the addition of
+   multi-lingual support in the future:
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 61]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   (1) A work in progress called Multi-Lingual String Format (MLSF)
+   proposes a layer on top of UTF-8 which uses otherwise illegal UTF-8
+   sequences to store language tags.  In order to permit its addition to
+   a future version of this standard, client-side UTF-8 interpreters
+   MUST be able to silently ignore illegal multi-byte UTF-8 characters,
+   and treat illegal single-byte UTF-8 characters as end of string
+   markers.  Servers, for the time being, MUST be able to silently
+   accept illegal UTF-8 characters, except in attribute names and entry
+   names.  Clients MUST NOT send illegal UTF-8 characters to the server
+   unless a future standard changes this rule.
+
+   (2) There is a proposal to add language tags to Unicode.  To support
+   this, servers MUST be able to store UTF-8 characters of up to 20 bits
+   of data.
+
+   (3) The metadata item "language" is reserved for future use.
+
+10.      Security Considerations
+
+   The AUTHENTICATE command uses SASL [SASL] to provide basic
+   authentication, authorization, integrity and privacy services.  This
+   is described in section 6.3.1.
+
+   When the CRAM-MD5 mechanism is used, the security considerations for
+   the CRAM-MD5 SASL mechanism [CRAM-MD5] apply.  The CRAM-MD5 mechanism
+   is also susceptible to passive dictionary attacks.  This means that
+   if an authentication session is recorded by a passive observer, that
+   observer can try common passwords through the CRAM-MD5 mechanism and
+   see if the results match.  This attack is reduced by using hard to
+   guess passwords.  Sites are encouraged to educate users and have the
+   password change service test candidate passwords against a
+   dictionary.  ACAP implementations of CRAM-MD5 SHOULD permit passwords
+   of at least 64 characters in length.
+
+   ACAP protocol transactions are susceptible to passive observers or
+   man in the middle attacks which alter the data, unless the optional
+   encryption and integrity services of the AUTHENTICATE command are
+   enabled, or an external security mechanism is used for protection.
+   It may be useful to allow configuration of both clients and servers
+   to refuse to transfer sensitive information in the absence of strong
+   encryption.
+
+   ACAP access control lists provide fine grained authorization for
+   access to attributes.  A number of related security issues are
+   described in section 3.5.
+
+   ACAP URLs have the same security considerations as IMAP URLs
+   [IMAP-URL].
+
+
+
+Newman & Myers              Standards Track                    [Page 62]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   ACAP clients are encouraged to consider the security problems
+   involved with a lab computer situation.  Specifically, a client cache
+   of ACAP configuration information MUST NOT allow access by an
+   unauthorized user.  One way to assure this is for an ACAP client to
+   be able to completely flush any non-public cached configuration data
+   when a user leaves.
+
+   As laptop computers can be easily stolen and a cache of configuration
+   data may contain sensitive information, a disconnected mode ACAP
+   client may wish to encrypt and password protect cached configuration
+   information.
+
+11.      Acknowledgments
+
+   Many thanks to the follow people who have contributed to ACAP over
+   the past four years: Wallace Colyer, Mark Crispin, Jack DeWinter, Rob
+   Earhart, Ned Freed, Randy Gellens, Terry Gray, J. S. Greenfield,
+   Steve Dorner, Steve Hole, Steve Hubert, Dave Roberts, Bart Schaefer,
+   Matt Wall and other participants of the IETF ACAP working group.
+
+12.      Authors' Addresses
+
+   Chris Newman
+   Innosoft International, Inc.
+   1050 Lakes Drive
+   West Covina, CA 91790 USA
+
+   Email: chris.newman@innosoft.com
+
+
+   John Gardiner Myers
+   Netscape Communications
+   501 East Middlefield Road
+   Mail Stop MV-029
+   Mountain View, CA 94043
+
+   Email: jgmyers@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 63]
+
+RFC 2244                          ACAP                     November 1997
+
+
+Appendices
+
+A.       References
+
+   [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
+   ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
+   November 1997.
+
+       <ftp://ds.internic.net/rfc/rfc2234.txt>
+
+   [BASIC-URL] Berners-Lee, Masinter, McCahill, "Uniform Resource
+   Locators (URL)", RFC 1738, CERN, Xerox Coproration, University of
+   Minnesota, December 1994.
+
+       <ftp://ds.internic.net/rfc/rfc1738.txt>
+
+   [CHARSET-LANG-POLICY] Alvestrand, "IETF Policy on Character Sets and
+   Languages", work in progress.
+
+   [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension
+   for Simple Challenge/Response", RFC 2195, MCI, September 1997.
+
+       <ftp://ds.internic.net/rfc/rfc2195.txt>
+
+   [IAB-CHARSET] Weider, Preston, Simonsen, Alvestrand, Atkinson,
+   Crispin, Svanberg, "The Report of the IAB Character Set Workshop held
+   29 February - 1 March, 1996", RFC 2130, April 1997.
+
+       <ftp://ds.internic.net/rfc/rfc2130.txt>
+
+   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
+   4rev1", RFC 2060, University of Washington, December 1996.
+
+       <ftp://ds.internic.net/rfc/rfc2060.txt>
+
+   [IMAP-ACL] Myers, J., "IMAP4 ACL extension", RFC 2086, Carnegie
+   Mellon, January 1997.
+
+       <ftp://ds.internic.net/rfc/rfc2086.txt>
+
+   [IMAP-URL] Newman, "IMAP URL Scheme", RFC 2192, Innosoft, July 1997.
+
+       <ftp://ds.internic.net/rfc/rfc2192.txt>
+
+   [ISO-10646] ISO/IEC 10646-1:1993(E) "Information Technology--
+   Universal Multiple-octet Coded Character Set (UCS)." See also
+   amendments 1 through 7, plus editorial corrections.
+
+
+
+
+Newman & Myers              Standards Track                    [Page 64]
+
+RFC 2244                          ACAP                     November 1997
+
+
+   [ISO-C] "Programming languages -- C", ISO/IEC 9899:1990,
+   International Organization for Standardization.  This is effectively
+   the same as ANSI C standard X3.159-1989.
+
+   [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
+   Requirement Levels", RFC 2119, Harvard University, March 1997.
+
+       <ftp://ds.internic.net/rfc/rfc2119.txt>
+
+   [LANG-TAGS] Alvestrand, H., "Tags for the Identification of
+   Languages", RFC 1766.
+
+       <ftp://ds.internic.net/rfc/rfc1766.txt>
+
+   [REL-URL] Fielding, "Relative Uniform Resource Locators", RFC 1808,
+   UC Irvine, June 1995.
+
+       <ftp://ds.internic.net/rfc/rfc1808.txt>
+
+   [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)",
+   RFC 2222, Netscape Communications, October 1997.
+
+       <ftp://ds.internic.net/rfc/rfc2222.txt>
+
+   [SASL-ANON] Newman, C., "Anonymous SASL Mechanism", RFC 2245,
+   November 1997.
+
+   [UNICODE-2] The Unicode Consortium, "The Unicode Standard, Version
+   2.0", Addison-Wesley, 1996. ISBN 0-201-48345-9.
+
+   [US-ASCII] "USA Standard Code for Information Interchange," X3.4.
+   American National Standards Institute: New York (1968).
+
+   [UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and ISO
+   10646", RFC 2044, Alis Technologies, October 1996.
+
+       <ftp://ds.internic.net/rfc/rfc2044.txt>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 65]
+
+RFC 2244                          ACAP                     November 1997
+
+
+B.       ACAP Keyword Index
+
+
+       ACAP (untagged response) ...................................   26
+       ADDTO (untagged response) ..................................   40
+       ALERT (untagged response) ..................................   31
+       ALL (search keyword) .......................................   36
+       AND (search keyword) .......................................   36
+       AUTH-TOO-WEAK (response code) ..............................   19
+       AUTHENTICATE (command) .....................................   31
+       BAD (response) .............................................   30
+       BYE (untagged response) ....................................   30
+       CHANGE (untagged response) .................................   41
+       COMPARE (search keyword) ...................................   36
+       COMPARESTRICT (search keyword) .............................   36
+       CONTEXTLIMIT (ACAP capability) .............................   27
+       DELETEACL (command) ........................................   46
+       DELETED (intermediate response) ............................   45
+       DELETEDSINCE (command) .....................................   45
+       DEPTH (search modifier) ....................................   34
+       ENCRYPT-NEEDED (response code) .............................   19
+       ENTRY (intermediate response) ..............................   37
+       EQUAL (search keyword) .....................................   37
+       FREECONTEXT (command) ......................................   39
+       GETQUOTA (command) .........................................   48
+       HARDLIMIT (search modifier) ................................   34
+       IMPLEMENTATION (ACAP capability) ...........................   27
+       INVALID (response code) ....................................   19
+       LANG (command) .............................................   28
+       LANG (intermediate response) ...............................   28
+       LIMIT (search modifier) ....................................   34
+       LISTRIGHTS (command) .......................................   47
+       LISTRIGHTS (intermediate response) .........................   48
+       LOGOUT (command) ...........................................   29
+       MAKECONTEXT (search modifier) ..............................   34
+       MODIFIED (response code) ...................................   19
+       MODTIME (intermediate response) ............................   38
+       MODTIME (untagged response) ................................   42
+       MYRIGHTS (command) .........................................   47
+       MYRIGHTS (intermediate response) ...........................   47
+       NO (response) ..............................................   29
+       NOCREATE (store modifier) ..................................   44
+       NOEXIST (response code) ....................................   19
+       NOINHERIT (search modifier) ................................   35
+       NOOP (command) .............................................   27
+       NOT (search keyword) .......................................   37
+       OK (response) ..............................................   29
+       OR (search keyword) ........................................   37
+       PERMISSION (response code) .................................   19
+
+
+
+Newman & Myers              Standards Track                    [Page 66]
+
+RFC 2244                          ACAP                     November 1997
+
+
+
+       PREFIX (search keyword) ....................................   37
+       QUOTA (response code) ......................................   19
+       QUOTA (untagged response) ..................................   49
+       RANGE (search keyword) .....................................   37
+       REFER (intermediate response) ..............................   38
+       REFER (response code) ......................................   19
+       REMOVEFROM (untagged response) .............................   41
+       RETURN (search modifier) ...................................   35
+       SASL (ACAP capability) .....................................   27
+       SASL (response code) .......................................   20
+       SEARCH (command) ...........................................   33
+       SETACL (command) ...........................................   46
+       SORT (search modifier) .....................................   36
+       STORE (command) ............................................   42
+       SUBSTRING (search keyword) .................................   37
+       TOOMANY (response code) ....................................   20
+       TOOOLD (response code) .....................................   20
+       TRANSITION-NEEDED (response code) ..........................   20
+       TRYFREECONTEXT (response code) .............................   20
+       TRYLATER (response code) ...................................   20
+       UNCHANGEDSINCE (store modifier) ............................   44
+       UPDATECONTEXT (command) ....................................   40
+       WAYTOOMANY (response code) .................................   20
+       acl (attribute metadata) ...................................   12
+       anyone (ACL identifier) ....................................   17
+       attribute (attribute metadata) .............................   12
+       dataset.acl (dataset attribute) ............................   24
+       dataset.acl.<attribute> (dataset attribute) ................   24
+       dataset.inherit (dataset attribute) ........................   24
+       entry (predefined attribute) ...............................   11
+       i;ascii-casemap (comparator) ...............................   16
+       i;ascii-numeric (comparator) ...............................   16
+       i;octet (comparator) .......................................   16
+       modtime (predefined attribute) .............................   11
+       myrights (attribute metadata) ..............................   12
+       size (attribute metadata) ..................................   13
+       subdataset (predefined attribute) ..........................   11
+       value (attribute metadata) .................................   13
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 67]
+
+RFC 2244                          ACAP                     November 1997
+
+
+C.       Full Copyright Statement
+
+   Copyright (C) The Internet Society 1997. All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implmentation may be prepared, copied, published and
+   distributed, in whole or in part, without restriction of any kind,
+   provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of developing
+   Internet standards in which case the procedures for copyrights defined
+   in the Internet Standards process must be followed, or as required to
+   translate it into languages other than English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
+   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
+   WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Myers              Standards Track                    [Page 68]
diff --git a/docs/rfcs/rfc2342.txt b/docs/rfcs/rfc2342.txt
new file mode 100644
index 0000000..0926646
--- /dev/null
+++ b/docs/rfcs/rfc2342.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                         M. Gahrns
+Request for Comments: 2342                                    Microsoft
+Category: Standards Track                                     C. Newman
+                                                               Innosoft
+                                                               May 1998
+
+
+                            IMAP4 Namespace
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+1. Abstract
+
+   IMAP4 [RFC-2060] does not define a default server namespace. As a
+   result, two common namespace models have evolved:
+
+   The "Personal Mailbox" model, in which the default namespace that is
+   presented consists of only the user's personal mailboxes. To access
+   shared mailboxes, the user must use an escape mechanism to reach
+   another namespace.
+
+   The "Complete Hierarchy" model, in which the default namespace that
+   is presented includes the user's personal mailboxes along with any
+   other mailboxes they have access to.
+
+   These two models, create difficulties for certain client operations.
+   This document defines a NAMESPACE command that allows a client to
+   discover the prefixes of namespaces used by a server for personal
+   mailboxes, other users' mailboxes, and shared mailboxes.  This allows
+   a client to avoid much of the manual user configuration that is now
+   necessary when mixing and matching IMAP4 clients and servers.
+
+2. Conventions used in this document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.  If such lines are wrapped without a new "C:" or
+   "S:" label, then the wrapping is for editorial clarity and is not
+   part of the command.
+
+
+
+Gahrns & Newman             Standards Track                     [Page 1]
+
+RFC 2342                    IMAP4 Namespace                     May 1998
+
+
+   Personal Namespace: A namespace that the server considers within the
+   personal scope of the authenticated user on a particular connection.
+   Typically, only the authenticated user has access to mailboxes in
+   their Personal Namespace. It is the part of the namespace that
+   belongs to the user that is allocated for mailboxes. If an INBOX
+   exists for a user, it MUST appear within the user's personal
+   namespace.  In the typical case, there SHOULD be only one Personal
+   Namespace on a server.
+
+   Other Users' Namespace: A namespace that consists of mailboxes from
+   the Personal Namespaces of other users.  To access mailboxes in the
+   Other Users' Namespace, the currently authenticated user MUST be
+   explicitly granted access rights.  For example, it is common for a
+   manager to grant to their secretary access rights to their mailbox.
+   In the typical case, there SHOULD be only one Other Users' Namespace
+   on a server.
+
+   Shared Namespace: A namespace that consists of mailboxes that are
+   intended to be shared amongst users and do not exist within a user's
+   Personal Namespace.
+
+   The namespaces a server uses MAY differ on a per-user basis.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC-2119].
+
+3. Introduction and Overview
+
+   Clients often attempt to create mailboxes for such purposes as
+   maintaining a record of sent messages (e.g. "Sent Mail") or
+   temporarily saving messages being composed (e.g. "Drafts").  For
+   these clients to inter-operate correctly with the variety of IMAP4
+   servers available, the user must enter the prefix of the Personal
+   Namespace used by the server.  Using the NAMESPACE command, a client
+   is able to automatically discover this prefix without manual user
+   configuration.
+
+   In addition, users are often required to manually enter the prefixes
+   of various namespaces in order to view the mailboxes located there.
+   For example, they might be required to enter the prefix of #shared to
+   view the shared mailboxes namespace. The NAMESPACE command allows a
+   client to automatically discover the namespaces that are available on
+   a server. This allows a client to present the available namespaces to
+   the user in what ever manner it deems appropriate.  For example, a
+
+
+
+
+
+
+Gahrns & Newman             Standards Track                     [Page 2]
+
+RFC 2342                    IMAP4 Namespace                     May 1998
+
+
+   client could choose to initially display only personal mailboxes, or
+   it may choose to display the complete list of mailboxes available,
+   and initially position the user at the root of their Personal
+   Namespace.
+
+   A server MAY choose to make available to the NAMESPACE command only a
+   subset of the complete set of namespaces the server supports. To
+   provide the ability to access these namespaces, a client SHOULD allow
+   the user the ability to manually enter a namespace prefix.
+
+4. Requirements
+
+   IMAP4 servers that support this extension MUST list the keyword
+   NAMESPACE in their CAPABILITY response.
+
+   The NAMESPACE command is valid in the Authenticated and Selected
+   state.
+
+5. NAMESPACE Command
+
+   Arguments: none
+
+   Response:  an untagged NAMESPACE response that contains the prefix
+                 and hierarchy delimiter to the server's Personal
+                 Namespace(s), Other Users' Namespace(s), and Shared
+                 Namespace(s) that the server wishes to expose. The
+                 response will contain a NIL for any namespace class
+                 that is not available. Namespace_Response_Extensions
+                 MAY be included in the response.
+                 Namespace_Response_Extensions which are not on the IETF
+                 standards track, MUST be prefixed with an "X-".
+
+   Result:    OK - Command completed
+                 NO - Error: Can't complete command
+                 BAD - argument invalid
+
+   Example 5.1:
+   ===========
+
+      < A server that supports a single personal namespace.  No leading
+      prefix is used on personal mailboxes and "/" is the hierarchy
+      delimiter.>
+
+      C: A001 NAMESPACE
+      S: * NAMESPACE (("" "/")) NIL NIL
+      S: A001 OK NAMESPACE command completed
+
+
+
+
+
+Gahrns & Newman             Standards Track                     [Page 3]
+
+RFC 2342                    IMAP4 Namespace                     May 1998
+
+
+   Example 5.2:
+   ===========
+
+      < A user logged on anonymously to a server.  No personal mailboxes
+      are associated with the anonymous user and the user does not have
+      access to the Other Users' Namespace.  No prefix is required to
+      access shared mailboxes and the hierarchy delimiter is "." >
+
+      C: A001 NAMESPACE
+      S: * NAMESPACE NIL NIL (("" "."))
+      S: A001 OK NAMESPACE command completed
+
+   Example 5.3:
+   ===========
+
+      < A server that contains a Personal Namespace and a single Shared
+      Namespace. >
+
+      C: A001 NAMESPACE
+      S: * NAMESPACE (("" "/")) NIL (("Public Folders/" "/"))
+      S: A001 OK NAMESPACE command completed
+
+   Example 5.4:
+   ===========
+
+      < A server that contains a Personal Namespace, Other Users'
+      Namespace and multiple Shared Namespaces.  Note that the hierarchy
+      delimiter used within each namespace can be different. >
+
+      C: A001 NAMESPACE
+      S: * NAMESPACE (("" "/")) (("~" "/")) (("#shared/" "/")
+         ("#public/" "/")("#ftp/" "/")("#news." "."))
+      S: A001 OK NAMESPACE command completed
+
+   The prefix string allows a client to do things such as automatically
+   creating personal mailboxes or LISTing all available mailboxes within
+   a namespace.
+
+   Example 5.5:
+   ===========
+
+      < A server that supports only the Personal Namespace, with a
+      leading prefix of INBOX to personal mailboxes and a hierarchy
+      delimiter of ".">
+
+      C: A001 NAMESPACE
+      S: * NAMESPACE (("INBOX." ".")) NIL  NIL
+      S: A001 OK NAMESPACE command completed
+
+
+
+Gahrns & Newman             Standards Track                     [Page 4]
+
+RFC 2342                    IMAP4 Namespace                     May 1998
+
+
+      < Automatically create a mailbox to store sent items.>
+
+      C: A002 CREATE "INBOX.Sent Mail"
+      S: A002 OK CREATE command completed
+
+   Although typically a server will support only a single Personal
+   Namespace, and a single Other User's Namespace, circumstances exist
+   where there MAY be multiples of these, and a client MUST be prepared
+   for them.   If a client is configured such that it is required to
+   create a certain mailbox, there can be circumstances where it is
+   unclear which Personal Namespaces it should create the mailbox in.
+   In these situations a client SHOULD let the user select which
+   namespaces to create the mailbox in.
+
+   Example 5.6:
+   ===========
+
+      < In this example, a server supports 2 Personal Namespaces.  In
+      addition to the regular Personal Namespace, the user has an
+      additional personal namespace to allow access to mailboxes in an
+      MH format mailstore. >
+
+      < The client is configured to save a copy of all mail sent by the
+      user into a mailbox called 'Sent Mail'.  Furthermore, after a
+      message is deleted from a mailbox, the client is configured to
+      move that message to a mailbox called 'Deleted Items'.>
+
+      < Note that this example demonstrates how some extension flags can
+      be passed to further describe the #mh namespace. >
+
+      C: A001 NAMESPACE
+      S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM" ("FLAG1" "FLAG2")))
+         NIL NIL
+      S: A001 OK NAMESPACE command completed
+
+      < It is desired to keep only one copy of sent mail. It is unclear
+      which Personal Namespace the client should use to create the 'Sent
+      Mail' mailbox.  The user is prompted to select a namespace and
+      only one 'Sent Mail' mailbox is created. >
+
+      C: A002 CREATE "Sent Mail"
+      S: A002 OK CREATE command completed
+
+      < The client is designed so that it keeps two 'Deleted Items'
+      mailboxes, one for each namespace. >
+
+      C: A003 CREATE "Delete Items"
+      S: A003 OK CREATE command completed
+
+
+
+Gahrns & Newman             Standards Track                     [Page 5]
+
+RFC 2342                    IMAP4 Namespace                     May 1998
+
+
+      C: A004 CREATE "#mh/Deleted Items"
+      S: A004 OK CREATE command completed
+
+   The next level of hierarchy following the Other Users' Namespace
+   prefix SHOULD consist of <username>, where <username> is a user name
+   as per the IMAP4 LOGIN or AUTHENTICATE command.
+
+   A client can construct a LIST command by appending a "%" to the Other
+   Users' Namespace prefix to discover the Personal Namespaces of other
+   users that are available to the currently authenticated user.
+
+   In response to such a LIST command, a server SHOULD NOT return user
+   names that have not granted access to their personal mailboxes to the
+   user in question.
+
+   A server MAY return a LIST response containing only the names of
+   users that have explicitly granted access to the user in question.
+
+   Alternatively, a server MAY return NO to such a LIST command,
+   requiring that a user name be included with the Other Users'
+   Namespace prefix before listing any other user's mailboxes.
+
+   Example 5.7:
+   ===========
+
+      < A server that supports providing a list of other user's
+      mailboxes that are accessible to the currently logged on user. >
+
+      C: A001 NAMESPACE
+      S: * NAMESPACE (("" "/")) (("Other Users/" "/")) NIL
+      S: A001 OK NAMESPACE command completed
+
+      C: A002 LIST "" "Other Users/%"
+      S: * LIST () "/" "Other Users/Mike"
+      S: * LIST () "/" "Other Users/Karen"
+      S: * LIST () "/" "Other Users/Matthew"
+      S: * LIST () "/" "Other Users/Tesa"
+      S: A002 OK LIST command completed
+
+   Example 5.8:
+   ===========
+
+      < A server that does not support providing a list of other user's
+      mailboxes that are accessible to the currently logged on user.
+      The mailboxes are listable if the client includes the name of the
+      other user with the Other Users' Namespace prefix. >
+
+
+
+
+
+Gahrns & Newman             Standards Track                     [Page 6]
+
+RFC 2342                    IMAP4 Namespace                     May 1998
+
+
+      C: A001 NAMESPACE
+      S: * NAMESPACE (("" "/")) (("#Users/" "/")) NIL
+      S: A001 OK NAMESPACE command completed
+
+      < In this example, the currently logged on user has access to the
+      Personal Namespace of user Mike, but the server chose to suppress
+      this information in the LIST response.  However, by appending the
+      user name Mike (received through user input) to the Other Users'
+      Namespace prefix, the client is able to get a listing of the
+      personal mailboxes of user Mike. >
+
+      C: A002 LIST "" "#Users/%"
+      S: A002 NO The requested item could not be found.
+
+      C: A003 LIST "" "#Users/Mike/%"
+      S: * LIST () "/" "#Users/Mike/INBOX"
+      S: * LIST () "/" "#Users/Mike/Foo"
+      S: A003 OK LIST command completed.
+
+      A prefix string might not contain a hierarchy delimiter, because
+      in some cases it is not needed as part of the prefix.
+
+      Example 5.9:
+      ===========
+
+      < A server that allows access to the Other Users' Namespace by
+      prefixing the others' mailboxes with a '~' followed by <username>,
+      where <username> is a user name as per the IMAP4 LOGIN or
+      AUTHENTICATE command.>
+
+      C: A001 NAMESPACE
+      S: * NAMESPACE (("" "/")) (("~" "/")) NIL
+      S: A001 OK NAMESPACE command completed
+
+      < List the mailboxes for user mark >
+
+      C: A002 LIST "" "~mark/%"
+      S: * LIST () "/" "~mark/INBOX"
+      S: * LIST () "/" "~mark/foo"
+      S: A002 OK LIST command completed
+
+   Historical convention has been to start all namespaces with the "#"
+   character.  Namespaces that include the "#" character are not IMAP
+   URL [IMAP-URL] friendly requiring the "#" character to be represented
+   as %23 when within URLs.  As such, server implementers MAY instead
+   consider using namespace prefixes that do not contain the "#"
+   character.
+
+
+
+
+Gahrns & Newman             Standards Track                     [Page 7]
+
+RFC 2342                    IMAP4 Namespace                     May 1998
+
+
+6. Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) as described in [ABNF].
+
+   atom = <atom>
+      ; <atom> as defined in [RFC-2060]
+
+   Namespace = nil / "(" 1*( "(" string SP  (<"> QUOTED_CHAR <"> /
+      nil) *(Namespace_Response_Extension) ")" ) ")"
+
+   Namespace_Command = "NAMESPACE"
+
+   Namespace_Response_Extension = SP string SP "(" string *(SP string)
+      ")"
+
+   Namespace_Response = "*" SP "NAMESPACE" SP Namespace SP Namespace SP
+      Namespace
+
+      ; The first Namespace is the Personal Namespace(s)
+      ; The second Namespace is the Other Users' Namespace(s)
+      ; The third Namespace is the Shared Namespace(s)
+
+      nil = <nil>
+         ; <nil> as defined in [RFC-2060]
+
+      QUOTED_CHAR = <QUOTED_CHAR>
+         ; <QUOTED_CHAR> as defined in [RFC-2060]
+
+      string = <string>
+         ; <string> as defined in [RFC-2060]
+         ; Note that  the namespace prefix is to a mailbox and following
+         ; IMAP4 convention, any international string in the NAMESPACE
+         ; response MUST be of modified UTF-7 format as described in
+         ;  [RFC-2060].
+
+7. Security Considerations
+
+   In response to a LIST command containing an argument of the Other
+   Users' Namespace prefix, a server SHOULD NOT list users that have not
+   granted list access to their personal mailboxes to the currently
+   authenticated user.  Providing such a list, could compromise security
+   by potentially disclosing confidential information of who is located
+   on the server, or providing a starting point of a list of user
+   accounts to attack.
+
+
+
+
+
+
+Gahrns & Newman             Standards Track                     [Page 8]
+
+RFC 2342                    IMAP4 Namespace                     May 1998
+
+
+8. References
+
+   [RFC-2060], Crispin, M., "Internet Message Access Protocol Version
+   4rev1", RFC 2060, December 1996.
+
+   [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
+   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [ABNF] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax
+   Specifications: ABNF", RFC 2234, November 1997.
+
+   [IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
+
+9.  Acknowledgments
+
+   Many people have participated in the discussion of IMAP namespaces on
+   the IMAP mailing list.  In particular, the authors would like to
+   thank Mark Crispin for many of the concepts relating to the Personal
+   Namespace and accessing the Personal Namespace of other users, Steve
+   Hole for summarizing the two namespace models, John Myers and Jack De
+   Winter for their work in a preceding effort trying to define a
+   standardized personal namespace, and Larry Osterman for his review
+   and collaboration on this document.
+
+11. Authors' Addresses
+
+   Mike Gahrns
+   Microsoft
+   One Microsoft Way
+   Redmond, WA, 98072, USA
+
+   Phone: (425) 936-9833
+   EMail: mikega@microsoft.com
+
+
+   Chris Newman
+   Innosoft International, Inc.
+   1050 East Garvey Ave. South
+   West Covina, CA, 91790, USA
+
+   EMail: chris.newman@innosoft.com
+
+
+
+
+
+
+
+
+
+
+Gahrns & Newman             Standards Track                     [Page 9]
+
+RFC 2342                    IMAP4 Namespace                     May 1998
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gahrns & Newman             Standards Track                    [Page 10]
+
diff --git a/docs/rfcs/rfc2359.txt b/docs/rfcs/rfc2359.txt
new file mode 100644
index 0000000..460ac4b
--- /dev/null
+++ b/docs/rfcs/rfc2359.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                           J. Myers
+Request for Comments: 2359                       Netscape Communications
+Category: Standards Track                                      June 1998
+
+
+                        IMAP4 UIDPLUS extension
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+IESG NOTE
+
+   The IMAP extension described here assumes a particular means of using
+   IMAP to support disconnected operation.  However, this means of
+   supporting disconnected operation is not yet documented.  Also, there
+   are multiple theories about how best to do disconnected operation in
+   IMAP, and as yet, there is no consensus on which one should be
+   adopted as a standard.
+
+   This document is being approved as a Proposed Standard because it
+   does not appear to have technical flaws in itelf.  However, approval
+   of this document as a Proposed Standard should not be considered an
+   IETF endorsement of any particular means of doing disconnected
+   operation in IMAP.
+
+Table of Contents
+
+   1.   Abstract ..............................................    2
+   2.   Conventions Used in this Document .....................    2
+   3.   Introduction and Overview .............................    2
+   4.   Features ..............................................    2
+   4.1. UID EXPUNGE Command ...................................    2
+   4.2. APPENDUID response code ...............................    3
+   4.3. COPYUID response code .................................    4
+   5.   Formal Syntax .........................................    4
+   6.   References ............................................    4
+   7.   Security Considerations ...............................    5
+   8.   Author's Address ......................................    5
+   9.   Full Copyright Statement ..............................    6
+
+
+
+Myers                       Standards Track                     [Page 1]
+
+RFC 2359                IMAP4 UIDPLUS extension                June 1998
+
+
+1.   Abstract
+
+   The UIDPLUS extension of the Internet Message Access Protocol [IMAP4]
+   provides a set of features intended to reduce the amount of time and
+   resources used by some client operations.  The features in UIDPLUS
+   are primarily intended for disconnected-use clients.
+
+2.   Conventions Used in this Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+   in this document are to be interpreted as defined in "Key words for
+   use in RFCs to Indicate Requirement Levels" [KEYWORDS].
+
+3.   Introduction and Overview
+
+   The UIDPLUS extension is present in any IMAP4 server implementation
+   which returns "UIDPLUS" as one of the supported capabilities to the
+   CAPABILITY command.  The UIDPLUS extension contains one additional
+   command and additional data returned with successful APPEND and COPY
+   commands.
+
+   Clients that wish to use the new command in UIDPLUS must of course
+   first test for the presence of the extension by issuing a CAPABILITY
+   command.  Each of the features in UIDPLUS are optimizations; clients
+   can provide the same functionality, albeit more slowly, by using
+   commands in the base protocol.  With each feature, this document
+   recommends a fallback approach to take when the UIDPLUS extension is
+   not supported by the server.
+
+4.   Features
+
+4.1. UID EXPUNGE Command
+
+   Arguments:  message set
+
+   Data:       untagged responses: EXPUNGE
+
+   Result:     OK - expunge completed
+               NO - expunge failure (e.g. permission denied)
+               BAD - command unknown or arguments invalid
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 2]
+
+RFC 2359                IMAP4 UIDPLUS extension                June 1998
+
+
+      The UID EXPUNGE command permanently removes from the currently
+      selected mailbox all messages that both have the \Deleted flag set
+      and have a UID that is included in the specified message set.  If
+      a message either does not have the \Deleted flag set or is has a
+      UID that is not included in the specified message set, it is not
+      affected.
+
+      This command may be used to ensure that a replayed EXPUNGE command
+      does not remove any messages that have been marked as \Deleted
+      between the time that the user requested the expunge operation and
+      the time the server processes the command.
+
+      If the server does not support the UIDPLUS capability, the client
+      should fall back to using the STORE command to temporarily remove
+      the \Deleted flag from messages it does not want to remove.  The
+      client could alternatively fall back to using the EXPUNGE command,
+      risking the unintended removal of some messages.
+
+   Example:    C: A003 UID EXPUNGE 3000:3002
+               S: * 3 EXPUNGE
+               S: * 3 EXPUNGE
+               S: * 3 EXPUNGE
+               S: A003 OK UID EXPUNGE completed
+
+4.2. APPENDUID response code
+
+   Successful APPEND commands return an APPENDUID response code in the
+   tagged OK response.  The APPENDUID response code contains as
+   arguments the UIDVALIDITY of the destination mailbox and the UID
+   assigned to the appended message.
+
+   If the server does not support the UIDPLUS capability, the client can
+   only discover this information by selecting the destination mailbox
+   and issuing FETCH commands.
+
+   Example:    C: A003 APPEND saved-messages (\Seen) {310}
+               C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
+               C: From: Fred Foobar <foobar@Blurdybloop.COM>
+               C: Subject: afternoon meeting
+               C: To: mooch@owatagu.siam.edu
+               C: Message-Id: <B27397-0100000@Blurdybloop.COM>
+               C: MIME-Version: 1.0
+               C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+               C:
+               C: Hello Joe, do you think we can meet at 3:30 tomorrow?
+               C:
+               S: A003 OK [APPENDUID 38505 3955] APPEND completed
+
+
+
+
+Myers                       Standards Track                     [Page 3]
+
+RFC 2359                IMAP4 UIDPLUS extension                June 1998
+
+
+4.3. COPYUID response code
+
+   Successful COPY and UID COPY commands return a COPYUID response code
+   in the tagged OK response whenever at least one message was copied.
+   The COPYUID response code contains as an argument the UIDVALIDITY of
+   the appended-to mailbox, a message set containing the UIDs of the
+   messages copied to the destination mailbox, in the order they were
+   copied, and a message containing the UIDs assigned to the copied
+   messages, in the order they were assigned.  Neither of the message
+   sets may contain extraneous UIDs or the symbol '*'.
+
+   If the server does not support the UIDPLUS capability, the client can
+   only discover this information by selecting the destination mailbox
+   and issuing FETCH commands.
+
+   Example:    C: A003 COPY 2:4 MEETING
+               S: A003 OK [COPYUID 38505 304,319:320 3956:3958] Done
+               C: A003 UID COPY 305:310 MEETING
+               S: A003 OK Done
+
+5.   Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
+   Non-terminals referenced but not defined below are as defined by
+   [IMAP4].
+
+   Except as noted otherwise, all alphabetic characters are case-
+   insensitive.  The use of upper or lower case characters to define
+   token strings is for editorial clarity only.  Implementations MUST
+   accept these strings in a case-insensitive fashion.
+
+   resp_code_apnd  ::= "APPENDUID" SPACE nz_number SPACE uniqueid
+
+   resp_code_copy  ::= "COPYUID" SPACE nz_number SPACE set SPACE set
+
+   uid_expunge     ::= "UID" SPACE "EXPUNGE" SPACE set
+
+6.   References
+
+   [IMAP4]    Crispin, M., "Internet Message Access Protocol -
+              Version 4rev1", RFC 2060, December 1996.
+
+   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC-822]  Crocker, D., "Standard for the Format of ARPA Internet
+              Text Messages", STD 11, RFC 822, August 1982.
+
+
+
+Myers                       Standards Track                     [Page 4]
+
+RFC 2359                IMAP4 UIDPLUS extension                June 1998
+
+
+7.   Security Considerations
+
+   There are no known security issues with this extension.
+
+8.   Author's Address
+
+   John Gardiner Myers
+   Netscape Communications
+   501 East Middlefield Road
+   Mail Stop MV-029
+   Mountain View, CA  94043
+
+   EMail: jgmyers@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 5]
+
+RFC 2359                IMAP4 UIDPLUS extension                June 1998
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 6]
+
diff --git a/docs/rfcs/rfc2595.txt b/docs/rfcs/rfc2595.txt
new file mode 100644
index 0000000..66897cd
--- /dev/null
+++ b/docs/rfcs/rfc2595.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                          C. Newman
+Request for Comments: 2595                                      Innosoft
+Category: Standards Track                                      June 1999
+
+
+                   Using TLS with IMAP, POP3 and ACAP
+
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+1. Motivation
+
+   The TLS protocol (formerly known as SSL) provides a way to secure an
+   application protocol from tampering and eavesdropping.  The option of
+   using such security is desirable for IMAP, POP and ACAP due to common
+   connection eavesdropping and hijacking attacks [AUTH].  Although
+   advanced SASL authentication mechanisms can provide a lightweight
+   version of this service, TLS is complimentary to simple
+   authentication-only SASL mechanisms or deployed clear-text password
+   login commands.
+
+   Many sites have a high investment in authentication infrastructure
+   (e.g., a large database of a one-way-function applied to user
+   passwords), so a privacy layer which is not tightly bound to user
+   authentication can protect against network eavesdropping attacks
+   without requiring a new authentication infrastructure and/or forcing
+   all users to change their password.  Recognizing that such sites will
+   desire simple password authentication in combination with TLS
+   encryption, this specification defines the PLAIN SASL mechanism for
+   use with protocols which lack a simple password authentication
+   command such as ACAP and SMTP.  (Note there is a separate RFC for the
+   STARTTLS command in SMTP [SMTPTLS].)
+
+   There is a strong desire in the IETF to eliminate the transmission of
+   clear-text passwords over unencrypted channels.  While SASL can be
+   used for this purpose, TLS provides an additional tool with different
+   deployability characteristics.  A server supporting both TLS with
+
+
+
+
+Newman                      Standards Track                     [Page 1]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+   simple passwords and a challenge/response SASL mechanism is likely to
+   interoperate with a wide variety of clients without resorting to
+   unencrypted clear-text passwords.
+
+   The STARTTLS command rectifies a number of the problems with using a
+   separate port for a "secure" protocol variant.  Some of these are
+   mentioned in section 7.
+
+1.1. Conventions Used in this Document
+
+   The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
+   "MAY", and "OPTIONAL" in this document are to be interpreted as
+   described in "Key words for use in RFCs to Indicate Requirement
+   Levels" [KEYWORDS].
+
+   Terms related to authentication are defined in "On Internet
+   Authentication" [AUTH].
+
+   Formal syntax is defined using ABNF [ABNF].
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+2. Basic Interoperability and Security Requirements
+
+   The following requirements apply to all implementations of the
+   STARTTLS extension for IMAP, POP3 and ACAP.
+
+2.1. Cipher Suite Requirements
+
+   Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher
+   suite is REQUIRED.  This is important as it assures that any two
+   compliant implementations can be configured to interoperate.
+
+   All other cipher suites are OPTIONAL.
+
+2.2. Privacy Operational Mode Security Requirements
+
+   Both clients and servers SHOULD have a privacy operational mode which
+   refuses authentication unless successful activation of an encryption
+   layer (such as that provided by TLS) occurs prior to or at the time
+   of authentication and which will terminate the connection if that
+   encryption layer is deactivated.  Implementations are encouraged to
+   have flexability with respect to the minimal encryption strength or
+   cipher suites permitted.  A minimalist approach to this
+   recommendation would be an operational mode where the
+   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is mandatory prior to
+   permitting authentication.
+
+
+
+Newman                      Standards Track                     [Page 2]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+   Clients MAY have an operational mode which uses encryption only when
+   it is advertised by the server, but authentication continues
+   regardless.  For backwards compatibility, servers SHOULD have an
+   operational mode where only the authentication mechanisms required by
+   the relevant base protocol specification are needed to successfully
+   authenticate.
+
+2.3. Clear-Text Password Requirements
+
+   Clients and servers which implement STARTTLS MUST be configurable to
+   refuse all clear-text login commands or mechanisms (including both
+   standards-track and nonstandard mechanisms) unless an encryption
+   layer of adequate strength is active.  Servers which allow
+   unencrypted clear-text logins SHOULD be configurable to refuse
+   clear-text logins both for the entire server, and on a per-user
+   basis.
+
+2.4. Server Identity Check
+
+   During the TLS negotiation, the client MUST check its understanding
+   of the server hostname against the server's identity as presented in
+   the server Certificate message, in order to prevent man-in-the-middle
+   attacks.  Matching is performed according to these rules:
+
+   - The client MUST use the server hostname it used to open the
+     connection as the value to compare against the server name as
+     expressed in the server certificate.  The client MUST NOT use any
+     form of the server hostname derived from an insecure remote source
+     (e.g., insecure DNS lookup).  CNAME canonicalization is not done.
+
+   - If a subjectAltName extension of type dNSName is present in the
+     certificate, it SHOULD be used as the source of the server's
+     identity.
+
+   - Matching is case-insensitive.
+
+   - A "*" wildcard character MAY be used as the left-most name
+     component in the certificate.  For example, *.example.com would
+     match a.example.com, foo.example.com, etc. but would not match
+     example.com.
+
+   - If the certificate contains multiple names (e.g. more than one
+     dNSName field), then a match with any one of the fields is
+     considered acceptable.
+
+   If the match fails, the client SHOULD either ask for explicit user
+   confirmation, or terminate the connection and indicate the server's
+   identity is suspect.
+
+
+
+Newman                      Standards Track                     [Page 3]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+2.5. TLS Security Policy Check
+
+   Both the client and server MUST check the result of the STARTTLS
+   command and subsequent TLS negotiation to see whether acceptable
+   authentication or privacy was achieved.  Ignoring this step
+   completely invalidates using TLS for security.  The decision about
+   whether acceptable authentication or privacy was achieved is made
+   locally, is implementation-dependent, and is beyond the scope of this
+   document.
+
+3. IMAP STARTTLS extension
+
+   When the TLS extension is present in IMAP, "STARTTLS" is listed as a
+   capability in response to the CAPABILITY command.  This extension
+   adds a single command, "STARTTLS" to the IMAP protocol which is used
+   to begin a TLS negotiation.
+
+3.1. STARTTLS Command
+
+   Arguments:  none
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - begin TLS negotiation
+               BAD - command unknown or arguments invalid
+
+      A TLS negotiation begins immediately after the CRLF at the end of
+      the tagged OK response from the server.  Once a client issues a
+      STARTTLS command, it MUST NOT issue further commands until a
+      server response is seen and the TLS negotiation is complete.
+
+      The STARTTLS command is only valid in non-authenticated state.
+      The server remains in non-authenticated state, even if client
+      credentials are supplied during the TLS negotiation.  The SASL
+      [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
+      client credentials are successfully exchanged, but servers
+      supporting the STARTTLS command are not required to support the
+      EXTERNAL mechanism.
+
+      Once TLS has been started, the client MUST discard cached
+      information about server capabilities and SHOULD re-issue the
+      CAPABILITY command.  This is necessary to protect against
+      man-in-the-middle attacks which alter the capabilities list prior
+      to STARTTLS.  The server MAY advertise different capabilities
+      after STARTTLS.
+
+      The formal syntax for IMAP is amended as follows:
+
+
+
+
+Newman                      Standards Track                     [Page 4]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+        command_any   =/  "STARTTLS"
+
+   Example:    C: a001 CAPABILITY
+               S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
+               S: a001 OK CAPABILITY completed
+               C: a002 STARTTLS
+               S: a002 OK Begin TLS negotiation now
+               <TLS negotiation, further commands are under TLS layer>
+               C: a003 CAPABILITY
+               S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL
+               S: a003 OK CAPABILITY completed
+               C: a004 LOGIN joe password
+               S: a004 OK LOGIN completed
+
+3.2. IMAP LOGINDISABLED capability
+
+   The current IMAP protocol specification (RFC 2060) requires the
+   implementation of the LOGIN command which uses clear-text passwords.
+   Many sites may choose to disable this command unless encryption is
+   active for security reasons.  An IMAP server MAY advertise that the
+   LOGIN command is disabled by including the LOGINDISABLED capability
+   in the capability response.  Such a server will respond with a tagged
+   "NO" response to any attempt to use the LOGIN command.
+
+   An IMAP server which implements STARTTLS MUST implement support for
+   the LOGINDISABLED capability on unencrypted connections.
+
+   An IMAP client which complies with this specification MUST NOT issue
+   the LOGIN command if this capability is present.
+
+   This capability is useful to prevent clients compliant with this
+   specification from sending an unencrypted password in an environment
+   subject to passive attacks.  It has no impact on an environment
+   subject to active attacks as a man-in-the-middle attacker can remove
+   this capability.  Therefore this does not relieve clients of the need
+   to follow the privacy mode recommendation in section 2.2.
+
+   Servers advertising this capability will fail to interoperate with
+   many existing compliant IMAP clients and will be unable to prevent
+   those clients from disclosing the user's password.
+
+4. POP3 STARTTLS extension
+
+   The POP3 STARTTLS extension adds the STLS command to POP3 servers.
+   If this is implemented, the POP3 extension mechanism [POP3EXT] MUST
+   also be implemented to avoid the need for client probing of multiple
+   commands.  The capability name "STLS" indicates this command is
+   present and permitted in the current state.
+
+
+
+Newman                      Standards Track                     [Page 5]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+      STLS
+
+         Arguments: none
+
+         Restrictions:
+             Only permitted in AUTHORIZATION state.
+
+         Discussion:
+             A TLS negotiation begins immediately after the CRLF at the
+             end of the +OK response from the server.  A -ERR response
+             MAY result if a security layer is already active.  Once a
+             client issues a STLS command, it MUST NOT issue further
+             commands until a server response is seen and the TLS
+             negotiation is complete.
+
+             The STLS command is only permitted in AUTHORIZATION state
+             and the server remains in AUTHORIZATION state, even if
+             client credentials are supplied during the TLS negotiation.
+             The AUTH command [POP-AUTH] with the EXTERNAL mechanism
+             [SASL] MAY be used to authenticate once TLS client
+             credentials are successfully exchanged, but servers
+             supporting the STLS command are not required to support the
+             EXTERNAL mechanism.
+
+             Once TLS has been started, the client MUST discard cached
+             information about server capabilities and SHOULD re-issue
+             the CAPA command.  This is necessary to protect against
+             man-in-the-middle attacks which alter the capabilities list
+             prior to STLS.  The server MAY advertise different
+             capabilities after STLS.
+
+         Possible Responses:
+             +OK -ERR
+
+         Examples:
+             C: STLS
+             S: +OK Begin TLS negotiation
+             <TLS negotiation, further commands are under TLS layer>
+               ...
+             C: STLS
+             S: -ERR Command not permitted when TLS active
+
+
+
+
+
+
+
+
+
+
+Newman                      Standards Track                     [Page 6]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+5. ACAP STARTTLS extension
+
+   When the TLS extension is present in ACAP, "STARTTLS" is listed as a
+   capability in the ACAP greeting.  No arguments to this capability are
+   defined at this time.  This extension adds a single command,
+   "STARTTLS" to the ACAP protocol which is used to begin a TLS
+   negotiation.
+
+5.1. STARTTLS Command
+
+   Arguments:  none
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - begin TLS negotiation
+               BAD - command unknown or arguments invalid
+
+      A TLS negotiation begins immediately after the CRLF at the end of
+      the tagged OK response from the server.  Once a client issues a
+      STARTTLS command, it MUST NOT issue further commands until a
+      server response is seen and the TLS negotiation is complete.
+
+      The STARTTLS command is only valid in non-authenticated state.
+      The server remains in non-authenticated state, even if client
+      credentials are supplied during the TLS negotiation.  The SASL
+      [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
+      client credentials are successfully exchanged, but servers
+      supporting the STARTTLS command are not required to support the
+      EXTERNAL mechanism.
+
+      After the TLS layer is established, the server MUST re-issue an
+      untagged ACAP greeting.  This is necessary to protect against
+      man-in-the-middle attacks which alter the capabilities list prior
+      to STARTTLS.  The client MUST discard cached capability
+      information and replace it with the information from the new ACAP
+      greeting.  The server MAY advertise different capabilities after
+      STARTTLS.
+
+      The formal syntax for ACAP is amended as follows:
+
+        command_any   =/  "STARTTLS"
+
+   Example:    S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
+               C: a002 STARTTLS
+               S: a002 OK "Begin TLS negotiation now"
+               <TLS negotiation, further commands are under TLS layer>
+               S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
+
+
+
+
+Newman                      Standards Track                     [Page 7]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+6. PLAIN SASL mechanism
+
+   Clear-text passwords are simple, interoperate with almost all
+   existing operating system authentication databases, and are useful
+   for a smooth transition to a more secure password-based
+   authentication mechanism.  The drawback is that they are unacceptable
+   for use over an unencrypted network connection.
+
+   This defines the "PLAIN" SASL mechanism for use with ACAP and other
+   protocols with no clear-text login command.  The PLAIN SASL mechanism
+   MUST NOT be advertised or used unless a strong encryption layer (such
+   as the provided by TLS) is active or backwards compatibility dictates
+   otherwise.
+
+   The mechanism consists of a single message from the client to the
+   server.  The client sends the authorization identity (identity to
+   login as), followed by a US-ASCII NUL character, followed by the
+   authentication identity (identity whose password will be used),
+   followed by a US-ASCII NUL character, followed by the clear-text
+   password.  The client may leave the authorization identity empty to
+   indicate that it is the same as the authentication identity.
+
+   The server will verify the authentication identity and password with
+   the system authentication database and verify that the authentication
+   credentials permit the client to login as the authorization identity.
+   If both steps succeed, the user is logged in.
+
+   The server MAY also use the password to initialize any new
+   authentication database, such as one suitable for CRAM-MD5
+   [CRAM-MD5].
+
+   Non-US-ASCII characters are permitted as long as they are represented
+   in UTF-8 [UTF-8].  Use of non-visible characters or characters which
+   a user may be unable to enter on some keyboards is discouraged.
+
+   The formal grammar for the client message using Augmented BNF [ABNF]
+   follows.
+
+   message         = [authorize-id] NUL authenticate-id NUL password
+   authenticate-id = 1*UTF8-SAFE      ; MUST accept up to 255 octets
+   authorize-id    = 1*UTF8-SAFE      ; MUST accept up to 255 octets
+   password        = 1*UTF8-SAFE      ; MUST accept up to 255 octets
+   NUL             = %x00
+   UTF8-SAFE       = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 /
+                     UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6
+   UTF8-1          = %x80-BF
+   UTF8-2          = %xC0-DF UTF8-1
+   UTF8-3          = %xE0-EF 2UTF8-1
+
+
+
+Newman                      Standards Track                     [Page 8]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+   UTF8-4          = %xF0-F7 3UTF8-1
+   UTF8-5          = %xF8-FB 4UTF8-1
+   UTF8-6          = %xFC-FD 5UTF8-1
+
+   Here is an example of how this might be used to initialize a CRAM-MD5
+   authentication database for ACAP:
+
+   Example:    S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
+               C: a001 AUTHENTICATE "CRAM-MD5"
+               S: + "<1896.697170952@postoffice.reston.mci.net>"
+               C: "tim b913a602c7eda7a495b4e6e7334d3890"
+               S: a001 NO (TRANSITION-NEEDED)
+                  "Please change your password, or use TLS to login"
+               C: a002 STARTTLS
+               S: a002 OK "Begin TLS negotiation now"
+               <TLS negotiation, further commands are under TLS layer>
+               S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
+               C: a003 AUTHENTICATE "PLAIN" {21+}
+               C: <NUL>tim<NUL>tanstaaftanstaaf
+               S: a003 OK CRAM-MD5 password initialized
+
+   Note: In this example, <NUL> represents a single ASCII NUL octet.
+
+7. imaps and pop3s ports
+
+   Separate "imaps" and "pop3s" ports were registered for use with SSL.
+   Use of these ports is discouraged in favor of the STARTTLS or STLS
+   commands.
+
+   A number of problems have been observed with separate ports for
+   "secure" variants of protocols.  This is an attempt to enumerate some
+   of those problems.
+
+   - Separate ports lead to a separate URL scheme which intrudes into
+     the user interface in inappropriate ways.  For example, many web
+     pages use language like "click here if your browser supports SSL."
+     This is a decision the browser is often more capable of making than
+     the user.
+
+   - Separate ports imply a model of either "secure" or "not secure."
+     This can be misleading in a number of ways.  First, the "secure"
+     port may not in fact be acceptably secure as an export-crippled
+     cipher suite might be in use.  This can mislead users into a false
+     sense of security.  Second, the normal port might in fact be
+     secured by using a SASL mechanism which includes a security layer.
+     Thus the separate port distinction makes the complex topic of
+     security policy even more confusing.  One common result of this
+     confusion is that firewall administrators are often misled into
+
+
+
+Newman                      Standards Track                     [Page 9]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+     permitting the "secure" port and blocking the standard port.  This
+     could be a poor choice given the common use of SSL with a 40-bit
+     key encryption layer and plain-text password authentication is less
+     secure than strong SASL mechanisms such as GSSAPI with Kerberos 5.
+
+   - Use of separate ports for SSL has caused clients to implement only
+     two security policies: use SSL or don't use SSL.  The desirable
+     security policy "use TLS when available" would be cumbersome with
+     the separate port model, but is simple with STARTTLS.
+
+   - Port numbers are a limited resource.  While they are not yet in
+     short supply, it is unwise to set a precedent that could double (or
+     worse) the speed of their consumption.
+
+
+8. IANA Considerations
+
+   This constitutes registration of the "STARTTLS" and "LOGINDISABLED"
+   IMAP capabilities as required by section 7.2.1 of RFC 2060 [IMAP].
+
+   The registration for the POP3 "STLS" capability follows:
+
+   CAPA tag:                   STLS
+   Arguments:                  none
+   Added commands:             STLS
+   Standard commands affected: May enable USER/PASS as a side-effect.
+     CAPA command SHOULD be re-issued after successful completion.
+   Announced states/Valid states: AUTHORIZATION state only.
+   Specification reference:    this memo
+
+   The registration for the ACAP "STARTTLS" capability follows:
+
+   Capability name:            STARTTLS
+   Capability keyword:         STARTTLS
+   Capability arguments:       none
+   Published Specification(s): this memo
+   Person and email address for further information:
+       see author's address section below
+
+   The registration for the PLAIN SASL mechanism follows:
+
+   SASL mechanism name:        PLAIN
+   Security Considerations:    See section 9 of this memo
+   Published specification:    this memo
+   Person & email address to contact for further information:
+       see author's address section below
+   Intended usage:             COMMON
+   Author/Change controller:   see author's address section below
+
+
+
+Newman                      Standards Track                    [Page 10]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+9. Security Considerations
+
+   TLS only provides protection for data sent over a network connection.
+   Messages transferred over IMAP or POP3 are still available to server
+   administrators and usually subject to eavesdropping, tampering and
+   forgery when transmitted through SMTP or NNTP.  TLS is no substitute
+   for an end-to-end message security mechanism using MIME security
+   multiparts [MIME-SEC].
+
+   A man-in-the-middle attacker can remove STARTTLS from the capability
+   list or generate a failure response to the STARTTLS command.  In
+   order to detect such an attack, clients SHOULD warn the user when
+   session privacy is not active and/or be configurable to refuse to
+   proceed without an acceptable level of security.
+
+   A man-in-the-middle attacker can always cause a down-negotiation to
+   the weakest authentication mechanism or cipher suite available.  For
+   this reason, implementations SHOULD be configurable to refuse weak
+   mechanisms or cipher suites.
+
+   Any protocol interactions prior to the TLS handshake are performed in
+   the clear and can be modified by a man-in-the-middle attacker.  For
+   this reason, clients MUST discard cached information about server
+   capabilities advertised prior to the start of the TLS handshake.
+
+   Clients are encouraged to clearly indicate when the level of
+   encryption active is known to be vulnerable to attack using modern
+   hardware (such as encryption keys with 56 bits of entropy or less).
+
+   The LOGINDISABLED IMAP capability (discussed in section 3.2) only
+   reduces the potential for passive attacks, it provides no protection
+   against active attacks.  The responsibility remains with the client
+   to avoid sending a password over a vulnerable channel.
+
+   The PLAIN mechanism relies on the TLS encryption layer for security.
+   When used without TLS, it is vulnerable to a common network
+   eavesdropping attack.  Therefore PLAIN MUST NOT be advertised or used
+   unless a suitable TLS encryption layer is active or backwards
+   compatibility dictates otherwise.
+
+   When the PLAIN mechanism is used, the server gains the ability to
+   impersonate the user to all services with the same password
+   regardless of any encryption provided by TLS or other network privacy
+   mechanisms.  While many other authentication mechanisms have similar
+   weaknesses, stronger SASL mechanisms such as Kerberos address this
+   issue.  Clients are encouraged to have an operational mode where all
+   mechanisms which are likely to reveal the user's password to the
+   server are disabled.
+
+
+
+Newman                      Standards Track                    [Page 11]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+   The security considerations for TLS apply to STARTTLS and the
+   security considerations for SASL apply to the PLAIN mechanism.
+   Additional security requirements are discussed in section 2.
+
+10. References
+
+   [ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 2234, November 1997.
+
+   [ACAP]     Newman, C. and J. Myers, "ACAP -- Application
+              Configuration Access Protocol", RFC 2244, November 1997.
+
+   [AUTH]     Haller, N. and R. Atkinson, "On Internet Authentication",
+              RFC 1704, October 1994.
+
+   [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
+              AUTHorize Extension for Simple Challenge/Response", RFC
+              2195, September 1997.
+
+   [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
+              4rev1", RFC 2060, December 1996.
+
+   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
+              "Security Multiparts for MIME: Multipart/Signed and
+              Multipart/Encrypted", RFC 1847, October 1995.
+
+   [POP3]     Myers, J. and M. Rose, "Post Office Protocol - Version 3",
+              STD 53, RFC 1939, May 1996.
+
+   [POP3EXT]  Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension
+              Mechanism", RFC 2449, November 1998.
+
+   [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
+              December 1994.
+
+   [SASL]     Myers, J., "Simple Authentication and Security Layer
+              (SASL)", RFC 2222, October 1997.
+
+   [SMTPTLS]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
+              TLS", RFC 2487, January 1999.
+
+   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+              RFC 2246, January 1999.
+
+
+
+
+
+Newman                      Standards Track                    [Page 12]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+   [UTF-8]    Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", RFC 2279, January 1998.
+
+
+11. Author's Address
+
+   Chris Newman
+   Innosoft International, Inc.
+   1050 Lakes Drive
+   West Covina, CA 91790 USA
+
+   EMail: chris.newman@innosoft.com
+
+
+A. Appendix -- Compliance Checklist
+
+   An implementation is not compliant if it fails to satisfy one or more
+   of the MUST requirements for the protocols it implements.  An
+   implementation that satisfies all the MUST and all the SHOULD
+   requirements for its protocols is said to be "unconditionally
+   compliant"; one that satisfies all the MUST requirements but not all
+   the SHOULD requirements for its protocols is said to be
+   "conditionally compliant".
+
+   Rules                                                 Section
+   -----                                                 -------
+   Mandatory-to-implement Cipher Suite                      2.1
+   SHOULD have mode where encryption required               2.2
+   server SHOULD have mode where TLS not required           2.2
+   MUST be configurable to refuse all clear-text login
+     commands or mechanisms                                 2.3
+   server SHOULD be configurable to refuse clear-text
+     login commands on entire server and on per-user basis  2.3
+   client MUST check server identity                        2.4
+   client MUST use hostname used to open connection         2.4
+   client MUST NOT use hostname from insecure remote lookup 2.4
+   client SHOULD support subjectAltName of dNSName type     2.4
+   client SHOULD ask for confirmation or terminate on fail  2.4
+   MUST check result of STARTTLS for acceptable privacy     2.5
+   client MUST NOT issue commands after STARTTLS
+      until server response and negotiation done        3.1,4,5.1
+   client MUST discard cached information             3.1,4,5.1,9
+   client SHOULD re-issue CAPABILITY/CAPA command       3.1,4
+   IMAP server with STARTTLS MUST implement LOGINDISABLED   3.2
+   IMAP client MUST NOT issue LOGIN if LOGINDISABLED        3.2
+   POP server MUST implement POP3 extensions                4
+   ACAP server MUST re-issue ACAP greeting                  5.1
+
+
+
+
+Newman                      Standards Track                    [Page 13]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+   client SHOULD warn when session privacy not active and/or
+     refuse to proceed without acceptable security level    9
+   SHOULD be configurable to refuse weak mechanisms or
+     cipher suites                                          9
+
+   The PLAIN mechanism is an optional part of this specification.
+   However if it is implemented the following rules apply:
+
+   Rules                                                 Section
+   -----                                                 -------
+   MUST NOT use PLAIN unless strong encryption active
+     or backwards compatibility dictates otherwise         6,9
+   MUST use UTF-8 encoding for characters in PLAIN          6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman                      Standards Track                    [Page 14]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman                      Standards Track                    [Page 15]
+
diff --git a/docs/rfcs/rfc2683.txt b/docs/rfcs/rfc2683.txt
new file mode 100644
index 0000000..d92e340
--- /dev/null
+++ b/docs/rfcs/rfc2683.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group                                           B. Leiba
+Request for Comments: 2683               IBM T.J. Watson Research Center
+Category: Informational                                   September 1999
+
+
+                  IMAP4 Implementation Recommendations
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+1. Abstract
+
+   The IMAP4 specification [RFC-2060] describes a rich protocol for use
+   in building clients and servers for storage, retrieval, and
+   manipulation of electronic mail.  Because the protocol is so rich and
+   has so many implementation choices, there are often trade-offs that
+   must be made and issues that must be considered when designing such
+   clients and servers.  This document attempts to outline these issues
+   and to make recommendations in order to make the end products as
+   interoperable as possible.
+
+2. Conventions used in this document
+
+   In examples, "C:" indicates lines sent by a client that is connected
+   to a server.  "S:" indicates lines sent by the server to the client.
+
+   The words "must", "must not", "should", "should not", and "may" are
+   used with specific meaning in this document; since their meaning is
+   somewhat different from that specified in RFC 2119, we do not put
+   them in all caps here.  Their meaning is as follows:
+
+   must --       This word means that the action described is necessary
+                 to ensure interoperability.  The recommendation should
+                 not be ignored.
+   must not --   This phrase means that the action described will be
+                 almost certain to hurt interoperability.  The
+                 recommendation should not be ignored.
+
+
+
+
+
+
+
+Leiba                        Informational                      [Page 1]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+   should --     This word means that the action described is strongly
+                 recommended and will enhance interoperability or
+                 usability.  The recommendation should not be ignored
+                 without careful consideration.
+   should not -- This phrase means that the action described is strongly
+                 recommended against, and might hurt interoperability or
+                 usability.  The recommendation should not be ignored
+                 without careful consideration.
+   may --        This word means that the action described is an
+                 acceptable implementation choice.  No specific
+                 recommendation is implied; this word is used to point
+                 out a choice that might not be obvious, or to let
+                 implementors know what choices have been made by
+                 existing implementations.
+
+3. Interoperability Issues and Recommendations
+
+3.1.   Accessibility
+
+   This section describes the issues related to access to servers and
+   server resources.  Concerns here include data sharing and maintenance
+   of client/server connections.
+
+3.1.1. Multiple Accesses of the Same Mailbox
+
+   One strong point of IMAP4 is that, unlike POP3, it allows for
+   multiple simultaneous access to a single mailbox.  A user can, thus,
+   read mail from a client at home while the client in the office is
+   still connected; or the help desk staff can all work out of the same
+   inbox, all seeing the same pool of questions.  An important point
+   about this capability, though is that NO SERVER IS GUARANTEED TO
+   SUPPORT THIS.  If you are selecting an IMAP server and this facility
+   is important to you, be sure that the server you choose to install,
+   in the configuration you choose to use, supports it.
+
+   If you are designing a client, you must not assume that you can
+   access the same mailbox more than once at a time.  That means
+
+   1. you must handle gracefully the failure of a SELECT command if the
+      server refuses the second SELECT,
+   2. you must handle reasonably the severing of your connection (see
+      "Severed Connections", below) if the server chooses to allow the
+      second SELECT by forcing the first off,
+   3. you must avoid making multiple connections to the same mailbox in
+      your own client (for load balancing or other such reasons), and
+   4. you must avoid using the STATUS command on a mailbox that you have
+      selected (with some server implementations the STATUS command has
+      the same problems with multiple access as do the SELECT and
+
+
+
+Leiba                        Informational                      [Page 2]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+      EXAMINE commands).
+
+   A further note about STATUS: The STATUS command is sometimes used to
+   check a non-selected mailbox for new mail.  This mechanism must not
+   be used to check for new mail in the selected mailbox; section 5.2 of
+   [RFC-2060] specifically forbids this in its last paragraph.  Further,
+   since STATUS takes a mailbox name it is an independent operation, not
+   operating on the selected mailbox.  Because of this, the information
+   it returns is not necessarily in synchronization with the selected
+   mailbox state.
+
+3.1.2. Severed Connections
+
+   The client/server connection may be severed for one of three reasons:
+   the client severs the connection, the server severs the connection,
+   or the connection is severed by outside forces beyond the control of
+   the client and the server (a telephone line drops, for example).
+   Clients and servers must both deal with these situations.
+
+   When the client wants to sever a connection, it's usually because it
+   has finished the work it needed to do on that connection.  The client
+   should send a LOGOUT command, wait for the tagged response, and then
+   close the socket.  But note that, while this is what's intended in
+   the protocol design, there isn't universal agreement here.  Some
+   contend that sending the LOGOUT and waiting for the two responses
+   (untagged BYE and tagged OK) is wasteful and unnecessary, and that
+   the client can simply close the socket.  The server should interpret
+   the closed socket as a log out by the client.  The counterargument is
+   that it's useful from the standpoint of cleanup, problem
+   determination, and the like, to have an explicit client log out,
+   because otherwise there is no way for the server to tell the
+   difference between "closed socket because of log out" and "closed
+   socket because communication was disrupted".  If there is a
+   client/server interaction problem, a client which routinely
+   terminates a session by breaking the connection without a LOGOUT will
+   make it much more difficult to determine the problem.
+
+   Because of this disagreement, server designers must be aware that
+   some clients might close the socket without sending a LOGOUT.  In any
+   case, whether or not a LOGOUT was sent, the server should not
+   implicitly expunge any messages from the selected mailbox.  If a
+   client wants the server to do so, it must send a CLOSE or EXPUNGE
+   command explicitly.
+
+   When the server wants to sever a connection it's usually due to an
+   inactivity timeout or is because a situation has arisen that has
+   changed the state of the mail store in a way that the server can not
+   communicate to the client.  The server should send an untagged BYE
+
+
+
+Leiba                        Informational                      [Page 3]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+   response to the client and then close the socket.  Sending an
+   untagged BYE response before severing allows the server to send a
+   human-readable explanation of the problem to the client, which the
+   client may then log, display to the user, or both (see section 7.1.5
+   of [RFC-2060]).
+
+   Regarding inactivity timeouts, there is some controversy.  Unlike
+   POP, for which the design is for a client to connect, retrieve mail,
+   and log out, IMAP's design encourages long-lived (and mostly
+   inactive) client/server sessions.  As the number of users grows, this
+   can use up a lot of server resources, especially with clients that
+   are designed to maintain sessions for mailboxes that the user has
+   finished accessing.  To alleviate this, a server may implement an
+   inactivity timeout, unilaterally closing a session (after first
+   sending an untagged BYE, as noted above).  Some server operators have
+   reported dramatic improvements in server performance after doing
+   this.  As specified in [RFC-2060], if such a timeout is done it must
+   not be until at least 30 minutes of inactivity.  The reason for this
+   specification is to prevent clients from sending commands (such as
+   NOOP) to the server at frequent intervals simply to avert a too-early
+   timeout.  If the client knows that the server may not time out the
+   session for at least 30 minutes, then the client need not poll at
+   intervals more frequent than, say, 25 minutes.
+
+3.2.   Scaling
+
+   IMAP4 has many features that allow for scalability, as mail stores
+   become larger and more numerous.  Large numbers of users, mailboxes,
+   and messages, and very large messages require thought to handle
+   efficiently.  This document will not address the administrative
+   issues involved in large numbers of users, but we will look at the
+   other items.
+
+3.2.1. Flood Control
+
+   There are three situations when a client can make a request that will
+   result in a very large response - too large for the client reasonably
+   to deal with: there are a great many mailboxes available, there are a
+   great many messages in the selected mailbox, or there is a very large
+   message part.  The danger here is that the end user will be stuck
+   waiting while the server sends (and the client processes) an enormous
+   response.  In all of these cases there are things a client can do to
+   reduce that danger.
+
+   There is also the case where a client can flood a server, by sending
+   an arbitratily long command.  We'll discuss that issue, too, in this
+   section.
+
+
+
+
+Leiba                        Informational                      [Page 4]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+3.2.1.1.  Listing Mailboxes
+
+   Some servers present Usenet newsgroups to IMAP users.  Newsgroups,
+   and other such hierarchical mailbox structures, can be very numerous
+   but may have only a few entries at the top level of hierarchy.  Also,
+   some servers are built against mail stores that can, unbeknownst to
+   the server, have circular hierarchies - that is, it's possible for
+   "a/b/c/d" to resolve to the same file structure as "a", which would
+   then mean that "a/b/c/d/b" is the same as "a/b", and the hierarchy
+   will never end.  The LIST response in this case will be unlimited.
+
+   Clients that will have trouble with this are those that use
+
+       C: 001 LIST "" *
+
+   to determine the mailbox list.  Because of this, clients should not
+   use an unqualified "*" that way in the LIST command.  A safer
+   approach is to list each level of hierarchy individually, allowing
+   the user to traverse the tree one limb at a time, thus:
+
+       C: 001 LIST "" %
+       S: * LIST () "/" Banana
+       S: * LIST ...etc...
+       S: 001 OK done
+
+   and then
+
+       C: 002 LIST "" Banana/%
+       S: * LIST () "/" Banana/Apple
+       S: * LIST ...etc...
+       S: 002 OK done
+
+   Using this technique the client's user interface can give the user
+   full flexibility without choking on the voluminous reply to "LIST *".
+
+   Of course, it is still possible that the reply to
+
+       C: 005 LIST "" alt.fan.celebrity.%
+
+   may be thousands of entries long, and there is, unfortunately,
+   nothing the client can do to protect itself from that.  This has not
+   yet been a notable problem.
+
+   Servers that may export circular hierarchies (any server that
+   directly presents a UNIX file system, for instance) should limit the
+   hierarchy depth to prevent unlimited LIST responses.  A suggested
+   depth limit is 20 hierarchy levels.
+
+
+
+
+Leiba                        Informational                      [Page 5]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+3.2.1.2.  Fetching the List of Messages
+
+   When a client selects a mailbox, it is given a count, in the untagged
+   EXISTS response, of the messages in the mailbox.  This number can be
+   very large.  In such a case it might be unwise to use
+
+       C: 004 FETCH 1:* ALL
+
+   to populate the user's view of the mailbox.  One good method to avoid
+   problems with this is to batch the requests, thus:
+
+       C: 004 FETCH 1:50 ALL
+       S: * 1 FETCH ...etc...
+       S: 004 OK done
+       C: 005 FETCH 51:100 ALL
+       S: * 51 FETCH ...etc...
+       S: 005 OK done
+       C: 006 FETCH 101:150 ALL
+       ...etc...
+
+   Using this method, another command, such as "FETCH 6 BODY[1]" can be
+   inserted as necessary, and the client will not have its access to the
+   server blocked by a storm of FETCH replies.  (Such a method could be
+   reversed to fetch the LAST 50 messages first, then the 50 prior to
+   that, and so on.)
+
+   As a smart extension of this, a well designed client, prepared for
+   very large mailboxes, will not automatically fetch data for all
+   messages AT ALL.  Rather, the client will populate the user's view
+   only as the user sees it, possibly pre-fetching selected information,
+   and only fetching other information as the user scrolls to it.  For
+   example, to select only those messages beginning with the first
+   unseen one:
+
+       C: 003 SELECT INBOX
+       S: * 10000 EXISTS
+       S: * 80 RECENT
+       S: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
+       S: * OK [UIDVALIDITY 824708485] UID validity status
+       S: * OK [UNSEEN 9921] First unseen message
+       S: 003 OK [READ-WRITE] SELECT completed
+       C: 004 FETCH 9921:* ALL
+       ... etc...
+
+   If the server does not return an OK [UNSEEN] response, the client may
+   use SEARCH UNSEEN to obtain that value.
+
+
+
+
+
+Leiba                        Informational                      [Page 6]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+   This mechanism is good as a default presentation method, but only
+   works well if the default message order is acceptable.  A client may
+   want to present various sort orders to the user (by subject, by date
+   sent, by sender, and so on) and in that case (lacking a SORT
+   extension on the server side) the client WILL have to retrieve all
+   message descriptors.  A client that provides this service should not
+   do it by default and should inform the user of the costs of choosing
+   this option for large mailboxes.
+
+3.2.1.3.  Fetching a Large Body Part
+
+   The issue here is similar to the one for a list of messages.  In the
+   BODYSTRUCTURE response the client knows the size, in bytes, of the
+   body part it plans to fetch.  Suppose this is a 70 MB video clip. The
+   client can use partial fetches to retrieve the body part in pieces,
+   avoiding the problem of an uninterruptible 70 MB literal coming back
+   from the server:
+
+       C: 022 FETCH 3 BODY[1]<0.20000>
+       S: * 3 FETCH (FLAGS(\Seen) BODY[1]<0> {20000}
+       S: ...data...)
+       S: 022 OK done
+       C: 023 FETCH 3 BODY[1]<20001.20000>
+       S: * 3 FETCH (BODY[1]<20001> {20000}
+       S: ...data...)
+       S: 023 OK done
+       C: 024 FETCH 3 BODY[1]<40001.20000>
+       ...etc...
+
+3.2.1.4.  BODYSTRUCTURE vs. Entire Messages
+
+   Because FETCH BODYSTRUCTURE is necessary in order to determine the
+   number of body parts, and, thus, whether a message has "attachments",
+   clients often use FETCH FULL as their normal method of populating the
+   user's view of a mailbox.  The benefit is that the client can display
+   a paperclip icon or some such indication along with the normal
+   message summary.  However, this comes at a significant cost with some
+   server configurations.  The parsing needed to generate the FETCH
+   BODYSTRUCTURE response may be time-consuming compared with that
+   needed for FETCH ENVELOPE.  The client developer should consider this
+   issue when deciding whether the ability to add a paperclip icon is
+   worth the tradeoff in performance, especially with large mailboxes.
+
+   Some clients, rather than using FETCH BODYSTRUCTURE, use FETCH BODY[]
+   (or the equivalent FETCH RFC822) to retrieve the entire message.
+   They then do the MIME parsing in the client.  This may give the
+   client slightly more flexibility in some areas (access, for instance,
+   to header fields that aren't returned in the BODYSTRUCTURE and
+
+
+
+Leiba                        Informational                      [Page 7]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+   ENVELOPE responses), but it can cause severe performance problems by
+   forcing the transfer of all body parts when the user might only want
+   to see some of them - a user logged on by modem and reading a small
+   text message with a large ZIP file attached may prefer to read the
+   text only and save the ZIP file for later.  Therefore, a client
+   should not normally retrieve entire messages and should retrieve
+   message body parts selectively.
+
+3.2.1.5.  Long Command Lines
+
+   A client can wind up building a very long command line in an effort to
+   try to be efficient about requesting information from a server.  This
+   can typically happen when a client builds a message set from selected
+   messages and doesn't recognise that contiguous blocks of messages may
+   be group in a range.  Suppose a user selects all 10,000 messages in a
+   large mailbox and then unselects message 287.  The client could build
+   that message set as "1:286,288:10000", but a client that doesn't
+   handle that might try to enumerate each message individually and build
+   "1,2,3,4, [and so on] ,9999,10000".  Adding that to the fetch command
+   results in a command line that's almost 49,000 octets long, and,
+   clearly, one can construct a command line that's even longer.
+
+   A client should limit the length of the command lines it generates to
+   approximately 1000 octets (including all quoted strings but not
+   including literals).  If the client is unable to group things into
+   ranges so that the command line is within that length, it should
+   split the request into multiple commands.  The client should use
+   literals instead of long quoted strings, in order to keep the command
+   length down.
+
+   For its part, a server should allow for a command line of at least
+   8000 octets.  This provides plenty of leeway for accepting reasonable
+   length commands from clients.  The server should send a BAD response
+   to a command that does not end within the server's maximum accepted
+   command length.
+
+3.2.2. Subscriptions
+
+   The client isn't the only entity that can get flooded: the end user,
+   too, may need some flood control.  The IMAP4 protocol provides such
+   control in the form of subscriptions.  Most servers support the
+   SUBSCRIBE, UNSUBSCRIBE, and LSUB commands, and many users choose to
+   narrow down a large list of available mailboxes by subscribing to the
+   ones that they usually want to see.  Clients, with this in mind,
+   should give the user a way to see only subscribed mailboxes.  A
+   client that never uses the LSUB command takes a significant usability
+   feature away from the user.  Of course, the client would not want to
+   hide the LIST command completely; the user needs to have a way to
+
+
+
+Leiba                        Informational                      [Page 8]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+   choose between LIST and LSUB.  The usual way to do this is to provide
+   a setting like "show which mailboxes?:  [] all  [] subscribed only".
+
+3.2.3. Searching
+
+   IMAP SEARCH commands can become particularly troublesome (that is,
+   slow) on mailboxes containing a large number of messages.  So let's
+   put a few things in perspective in that regard.
+
+   The flag searches should be fast.  The flag searches (ALL, [UN]SEEN,
+   [UN]ANSWERED, [UN]DELETED, [UN]DRAFT, [UN]FLAGGED, NEW, OLD, RECENT)
+   are known to be used by clients for the client's own use (for
+   instance, some clients use "SEARCH UNSEEN" to find unseen mail and
+   "SEARCH DELETED" to warn the user before expunging messages).
+
+   Other searches, particularly the text searches (HEADER, TEXT, BODY)
+   are initiated by the user, rather than by the client itself, and
+   somewhat slower performance can be tolerated, since the user is aware
+   that the search is being done (and is probably aware that it might be
+   time-consuming).  A smart server might use dynamic indexing to speed
+   commonly used text searches.
+
+   The client may allow other commands to be sent to the server while a
+   SEARCH is in progress, but at the time of this writing there is
+   little or no server support for parallel processing of multiple
+   commands in the same session (and see "Multiple Accesses of the Same
+   Mailbox" above for a description of the dangers of trying to work
+   around this by doing your SEARCH in another session).
+
+   Another word about text searches: some servers, built on database
+   back-ends with indexed search capabilities, may return search results
+   that do not match the IMAP spec's "case-insensitive substring"
+   requirements.  While these servers are in violation of the protocol,
+   there is little harm in the violation as long as the search results
+   are used only in response to a user's request.  Still, developers of
+   such servers should be aware that they ARE violating the protocol,
+   should think carefully about that behaviour, and must be certain that
+   their servers respond accurately to the flag searches for the reasons
+   outlined above.
+
+   In addition, servers should support CHARSET UTF-8 [UTF-8] in
+   searches.
+
+
+
+
+
+
+
+
+
+Leiba                        Informational                      [Page 9]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+3.3    Avoiding Invalid Requests
+
+   IMAP4 provides ways for a server to tell a client in advance what is
+   and isn't permitted in some circumstances.  Clients should use these
+   features to avoid sending requests that a well designed client would
+   know to be invalid.  This section explains this in more detail.
+
+3.3.1. The CAPABILITY Command
+
+   All IMAP4 clients should use the CAPABILITY command to determine what
+   version of IMAP and what optional features a server supports.  The
+   client should not send IMAP4rev1 commands and arguments to a server
+   that does not advertize IMAP4rev1 in its CAPABILITY response.
+   Similarly, the client should not send IMAP4 commands that no longer
+   exist in IMAP4rev1 to a server that does not advertize IMAP4 in its
+   CAPABILITY response.  An IMAP4rev1 server is NOT required to support
+   obsolete IMAP4 or IMAP2bis commands (though some do; do not let this
+   fact lull you into thinking that it's valid to send such commands to
+   an IMAP4rev1 server).
+
+   A client should not send commands to probe for the existance of
+   certain extensions.  All standard and standards-track extensions
+   include CAPABILITY tokens indicating their presense.  All private and
+   experimental extensions should do the same, and clients that take
+   advantage of them should use the CAPABILITY response to determine
+   whether they may be used or not.
+
+3.3.2. Don't Do What the Server Says You Can't
+
+   In many cases, the server, in response to a command, will tell the
+   client something about what can and can't be done with a particular
+   mailbox.  The client should pay attention to this information and
+   should not try to do things that it's been told it can't do.
+
+   Examples:
+
+   *  Do not try to SELECT a mailbox that has the \Noselect flag set.
+   *  Do not try to CREATE a sub-mailbox in a mailbox that has the
+      \Noinferiors flag set.
+   *  Do not respond to a failing COPY or APPEND command by trying to
+      CREATE the target mailbox if the server does not respond with a
+      [TRYCREATE] response code.
+   *  Do not try to expunge a mailbox that has been selected with the
+      [READ-ONLY] response code.
+
+
+
+
+
+
+
+Leiba                        Informational                     [Page 10]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+3.4.   Miscellaneous Protocol Considerations
+
+   We describe here a number of important protocol-related issues, the
+   misunderstanding of which has caused significant interoperability
+   problems in IMAP4 implementations.  One general item is that every
+   implementer should be certain to take note of and to understand
+   section 2.2.2 and the preamble to section 7 of the IMAP4rev1 spec
+   [RFC-2060].
+
+3.4.1. Well Formed Protocol
+
+   We cannot stress enough the importance of adhering strictly to the
+   protocol grammar.  The specification of the protocol is quite rigid;
+   do not assume that you can insert blank space for "readability" if
+   none is called for.  Keep in mind that there are parsers out there
+   that will crash if there are protocol errors.  There are clients that
+   will report every parser burp to the user.  And in any case,
+   information that cannot be parsed is information that is lost.  Be
+   careful in your protocol generation.  And see "A Word About Testing",
+   below.
+
+   In particular, note that the string in the INTERNALDATE response is
+   NOT an RFC-822 date string - that is, it is not in the same format as
+   the first string in the ENVELOPE response.  Since most clients will,
+   in fact, accept an RFC-822 date string in the INTERNALDATE response,
+   it's easy to miss this in your interoperability testing.  But it will
+   cause a problem with some client, so be sure to generate the correct
+   string for this field.
+
+3.4.2. Special Characters
+
+   Certain characters, currently the double-quote and the backslash, may
+   not be sent as-is inside a quoted string.  These characters must be
+   preceded by the escape character if they are in a quoted string, or
+   else the string must be sent as a literal.  Both clients and servers
+   must handle this, both on output (they must send these characters
+   properly) and on input (they must be able to receive escaped
+   characters in quoted strings).  Example:
+
+       C: 001 LIST "" %
+       S: * LIST () "" INBOX
+       S: * LIST () "\\" TEST
+       S: * LIST () "\\" {12}
+       S: "My" mailbox
+       S: 001 OK done
+       C: 002 LIST "" "\"My\" mailbox\\%"
+       S: * LIST () "\\" {17}
+       S: "My" mailbox\Junk
+
+
+
+Leiba                        Informational                     [Page 11]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+       S: 002 OK done
+
+   Note that in the example the server sent the hierarchy delimiter as
+   an escaped character in the quoted string and sent the mailbox name
+   containing imbedded double-quotes as a literal.  The client used only
+   quoted strings, escaping both the backslash and the double-quote
+   characters.
+
+   The CR and LF characters may be sent ONLY in literals; they are not
+   allowed, even if escaped, inside quoted strings.
+
+   And while we're talking about special characters: the IMAP spec, in
+   the section titled "Mailbox International Naming Convention",
+   describes how to encode mailbox names in modified UTF-7 [UTF-7 and
+   RFC-2060].  Implementations must adhere to this in order to be
+   interoperable in the international market, and servers should
+   validate mailbox names sent by client and reject names that do not
+   conform.
+
+   As to special characters in userids and passwords: clients must not
+   restrict what a user may type in for a userid or a password.  The
+   formal grammar specifies that these are "astrings", and an astring
+   can be a literal.  A literal, in turn can contain any 8-bit
+   character, and clients must allow users to enter all 8-bit characters
+   here, and must pass them, unchanged, to the server (being careful to
+   send them as literals when necessary).  In particular, some server
+   configurations use "@" in user names, and some clients do not allow
+   that character to be entered; this creates a severe interoperability
+   problem.
+
+3.4.3. UIDs and UIDVALIDITY
+
+   Servers that support existing back-end mail stores often have no good
+   place to save UIDs for messages.  Often the existing mail store will
+   not have the concept of UIDs in the sense that IMAP has: strictly
+   increasing, never re-issued, 32-bit integers.  Some servers solve
+   this by storing the UIDs in a place that's accessible to end users,
+   allowing for the possibility that the users will delete them.  Others
+   solve it by re-assigning UIDs every time a mailbox is selected.
+
+   The server should maintain UIDs permanently for all messages if it
+   can.  If that's not possible, the server must change the UIDVALIDITY
+   value for the mailbox whenever any of the UIDs may have become
+   invalid.  Clients must recognize that the UIDVALIDITY has changed and
+   must respond to that condition by throwing away any information that
+   they have saved about UIDs in that mailbox.  There have been many
+   problems in this area when clients have failed to do this; in the
+   worst case it will result in loss of mail when a client deletes the
+
+
+
+Leiba                        Informational                     [Page 12]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+   wrong piece of mail by using a stale UID.
+
+   It seems to be a common misunderstanding that "the UIDVALIDITY and
+   the UID, taken together, form a 64-bit identifier that uniquely
+   identifies a message on a server".  This is absolutely NOT TRUE.
+   There is no assurance that the UIDVALIDITY values of two mailboxes be
+   different, so the UIDVALIDITY in no way identifies a mailbox.  The
+   ONLY purpose of UIDVALIDITY is, as its name indicates, to give the
+   client a way to check the validity of the UIDs it has cached.  While
+   it is a valid implementation choice to put these values together to
+   make a 64-bit identifier for the message, the important concept here
+   is that UIDs are not unique between mailboxes; they are only unique
+   WITHIN a given mailbox.
+
+   Some server implementations have attempted to make UIDs unique across
+   the entire server.  This is inadvisable, in that it limits the life
+   of UIDs unnecessarily.  The UID is a 32-bit number and will run out
+   in reasonably finite time if it's global across the server.  If you
+   assign UIDs sequentially in one mailbox, you will not have to start
+   re-using them until you have had, at one time or another, 2**32
+   different messages in that mailbox.  In the global case, you will
+   have to reuse them once you have had, at one time or another, 2**32
+   different messages in the entire mail store.  Suppose your server has
+   around 8000 users registered (2**13).  That gives an average of 2**19
+   UIDs per user.  Suppose each user gets 32 messages (2**5) per day.
+   That gives you 2**14 days (16000+ days = about 45 years) before you
+   run out.  That may seem like enough, but multiply the usage just a
+   little (a lot of spam, a lot of mailing list subscriptions, more
+   users) and you limit yourself too much.
+
+   What's worse is that if you have to wrap the UIDs, and, thus, you
+   have to change UIDVALIDITY and invalidate the UIDs in the mailbox,
+   you have to do it for EVERY mailbox in the system, since they all
+   share the same UID pool.  If you assign UIDs per mailbox and you have
+   a problem, you only have to kill the UIDs for that one mailbox.
+
+   Under extreme circumstances (and this is extreme, indeed), the server
+   may have to invalidate UIDs while a mailbox is in use by a client -
+   that is, the UIDs that the client knows about in its active mailbox
+   are no longer valid.  In that case, the server must immediately
+   change the UIDVALIDITY and must communicate this to the client.  The
+   server may do this by sending an unsolicited UIDVALIDITY message, in
+   the same form as in response to the SELECT command.  Clients must be
+   prepared to handle such a message and the possibly coincident failure
+   of the command in process.  For example:
+
+
+
+
+
+
+Leiba                        Informational                     [Page 13]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+       C: 032 UID STORE 382 +Flags.silent \Deleted
+       S: * OK [UIDVALIDITY 12345] New UIDVALIDITY value!
+       S: 032 NO UID command rejected because UIDVALIDITY changed!
+       C: ...invalidates local information and re-fetches...
+       C: 033 FETCH 1:* UID
+       ...etc...
+
+   At the time of the writing of this document, the only server known to
+   do this does so only under the following condition: the client
+   selects INBOX, but there is not yet a physical INBOX file created.
+   Nonetheless, the SELECT succeeds, exporting an empty INBOX with a
+   temporary UIDVALIDITY of 1.  While the INBOX remains selected, mail
+   is delivered to the user, which creates the real INBOX file and
+   assigns a permanent UIDVALIDITY (that is likely not to be 1).  The
+   server reports the change of UIDVALIDITY, but as there were no
+   messages before, so no UIDs have actually changed, all the client
+   must do is accept the change in UIDVALIDITY.
+
+   Alternatively, a server may force the client to re-select the
+   mailbox, at which time it will obtain a new UIDVALIDITY value.  To do
+   this, the server closes this client session (see "Severed
+   Connections" above) and the client then reconnects and gets back in
+   synch.  Clients must be prepared for either of these behaviours.
+
+   We do not know of, nor do we anticipate the future existance of, a
+   server that changes UIDVALIDITY while there are existing messages,
+   but clients must be prepared to handle this eventuality.
+
+3.4.4. FETCH Responses
+
+   When a client asks for certain information in a FETCH command, the
+   server may return the requested information in any order, not
+   necessarily in the order that it was requested.  Further, the server
+   may return the information in separate FETCH responses and may also
+   return information that was not explicitly requested (to reflect to
+   the client changes in the state of the subject message).  Some
+   examples:
+
+       C: 001 FETCH 1 UID FLAGS INTERNALDATE
+       S: * 5 FETCH (FLAGS (\Deleted))
+       S: * 1 FETCH (FLAGS (\Seen) INTERNALDATE "..." UID 345)
+       S: 001 OK done
+
+   (In this case, the responses are in a different order.  Also, the
+   server returned a flag update for message 5, which wasn't part of the
+   client's request.)
+
+
+
+
+
+Leiba                        Informational                     [Page 14]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+       C: 002 FETCH 2 UID FLAGS INTERNALDATE
+       S: * 2 FETCH (INTERNALDATE "...")
+       S: * 2 FETCH (UID 399)
+       S: * 2 FETCH (FLAGS ())
+       S: 002 OK done
+
+   (In this case, the responses are in a different order and were
+   returned in separate responses.)
+
+       C: 003 FETCH 2 BODY[1]
+       S: * 2 FETCH (FLAGS (\Seen) BODY[1] {14}
+       S: Hello world!
+       S: )
+       S: 003 OK done
+
+   (In this case, the FLAGS response was added by the server, since
+   fetching the body part caused the server to set the \Seen flag.)
+
+   Because of this characteristic a client must be ready to receive any
+   FETCH response at any time and should use that information to update
+   its local information about the message to which the FETCH response
+   refers.  A client must not assume that any FETCH responses will come
+   in any particular order, or even that any will come at all.  If after
+   receiving the tagged response for a FETCH command the client finds
+   that it did not get all of the information requested, the client
+   should send a NOOP command to the server to ensure that the server
+   has an opportunity to send any pending EXPUNGE responses to the
+   client (see [RFC-2180]).
+
+3.4.5. RFC822.SIZE
+
+   Some back-end mail stores keep the mail in a canonical form, rather
+   than retaining the original MIME format of the messages.  This means
+   that the server must reassemble the message to produce a MIME stream
+   when a client does a fetch such as RFC822 or BODY[], requesting the
+   entire message.  It also may mean that the server has no convenient
+   way to know the RFC822.SIZE of the message.  Often, such a server
+   will actually have to build the MIME stream to compute the size, only
+   to throw the stream away and report the size to the client.
+
+   When this is the case, some servers have chosen to estimate the size,
+   rather than to compute it precisely.  Such an estimate allows the
+   client to display an approximate size to the user and to use the
+   estimate in flood control considerations (q.v.), but requires that
+   the client not use the size for things such as allocation of buffers,
+   because those buffers might then be too small to hold the actual MIME
+   stream.  Instead, a client should use the size that's returned in the
+   literal when you fetch the data.
+
+
+
+Leiba                        Informational                     [Page 15]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+   The protocol requires that the RFC822.SIZE value returned by the
+   server be EXACT.  Estimating the size is a protocol violation, and
+   server designers must be aware that, despite the performance savings
+   they might realize in using an estimate, this practice will cause
+   some clients to fail in various ways.  If possible, the server should
+   compute the RFC822.SIZE for a particular message once, and then save
+   it for later retrieval.  If that's not possible, the server must
+   compute the value exactly every time.  Incorrect estimates do cause
+   severe interoperability problems with some clients.
+
+3.4.6. Expunged Messages
+
+   If the server allows multiple connections to the same mailbox, it is
+   often possible for messages to be expunged in one client unbeknownst
+   to another client.  Since the server is not allowed to tell the
+   client about these expunged messages in response to a FETCH command,
+   the server may have to deal with the issue of how to return
+   information about an expunged message.  There was extensive
+   discussion about this issue, and the results of that discussion are
+   summarized in [RFC-2180].  See that reference for a detailed
+   explanation and for recommendations.
+
+3.4.7. The Namespace Issue
+
+   Namespaces are a very muddy area in IMAP4 implementation right now
+   (see [NAMESPACE] for a proposal to clear the water a bit).  Until the
+   issue is resolved, the important thing for client developers to
+   understand is that some servers provide access through IMAP to more
+   than just the user's personal mailboxes, and, in fact, the user's
+   personal mailboxes may be "hidden" somewhere in the user's default
+   hierarchy.  The client, therefore, should provide a setting wherein
+   the user can specify a prefix to be used when accessing mailboxes. If
+   the user's mailboxes are all in "~/mail/", for instance, then the
+   user can put that string in the prefix.  The client would then put
+   the prefix in front of any name pattern in the LIST and LSUB
+   commands:
+
+       C: 001 LIST "" ~/mail/%
+
+   (See also "Reference Names in the LIST Command" below.)
+
+3.4.8. Creating Special-Use Mailboxes
+
+   It may seem at first that this is part of the namespace issue; it is
+   not, and is only indirectly related to it.  A number of clients like
+   to create special-use mailboxes with particular names.  Most
+   commonly, clients with a "trash folder" model of message deletion
+   want to create a mailbox with the name "Trash" or "Deleted".  Some
+
+
+
+Leiba                        Informational                     [Page 16]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+   clients want to create a "Drafts" mailbox, an "Outbox" mailbox, or a
+   "Sent Mail" mailbox.  And so on.  There are two major
+   interoperability problems with this practice:
+
+   1. different clients may use different names for mailboxes with
+      similar functions (such as "Trash" and "Deleted"), or may manage
+      the same mailboxes in different ways, causing problems if a user
+      switches between clients and
+   2. there is no guarantee that the server will allow the creation of
+      the desired mailbox.
+
+   The client developer is, therefore, well advised to consider
+   carefully the creation of any special-use mailboxes on the server,
+   and, further, the client must not require such mailbox creation -
+   that is, if you do decide to do this, you must handle gracefully the
+   failure of the CREATE command and behave reasonably when your
+   special-use mailboxes do not exist and can not be created.
+
+   In addition, the client developer should provide a convenient way for
+   the user to select the names for any special-use mailboxes, allowing
+   the user to make these names the same in all clients used and to put
+   them where the user wants them.
+
+3.4.9. Reference Names in the LIST Command
+
+   Many implementers of both clients and servers are confused by the
+   "reference name" on the LIST command.  The reference name is intended
+   to be used in much the way a "cd" (change directory) command is used
+   on Unix, PC DOS, Windows, and OS/2 systems.  That is, the mailbox
+   name is interpreted in much the same way as a file of that name would
+   be found if one had done a "cd" command into the directory specified
+   by the reference name.  For example, in Unix we have the following:
+
+       > cd /u/jones/junk
+       > vi banana        [file is "/u/jones/junk/banana"]
+       > vi stuff/banana  [file is "/u/jones/junk/stuff/banana"]
+       > vi /etc/hosts    [file is "/etc/hosts"]
+
+   In the past, there have been several interoperability problems with
+   this.  First, while some IMAP servers are built on Unix or PC file
+   systems, many others are not, and the file system semantics do not
+   make sense in those configurations.  Second, while some IMAP servers
+   expose the underlying file system to the clients, others allow access
+   only to the user's personal mailboxes, or to some other limited set
+   of files, making such file-system-like semantics less meaningful.
+   Third, because the IMAP spec leaves the interpretation of the
+   reference name as "implementation-dependent", in the past the various
+   server implementations handled it in vastly differing ways.
+
+
+
+Leiba                        Informational                     [Page 17]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+   The following recommendations are the result of significant
+   operational experience, and are intended to maximize
+   interoperability.
+
+   Server implementations must implement the reference argument in a way
+   that matches the intended "change directory" operation as closely as
+   possible.  As a minimum implementation, the reference argument may be
+   prepended to the mailbox name (while suppressing double delimiters;
+   see the next paragraph).  Even servers that do not provide a way to
+   break out of the current hierarchy (see "breakout facility" below)
+   must provide a reasonable implementation of the reference argument,
+   as described here, so that they will interoperate with clients that
+   use it.
+
+   Server implementations that prepend the reference argument to the
+   mailbox name should insert a hierarchy delimiter between them, and
+   must not insert a second if one is already present:
+
+       C: A001 LIST ABC DEF
+       S: * LIST () "/" ABC/DEF   <=== should do this
+       S: A001 OK done
+
+       C: A002 LIST ABC/ /DEF
+       S: * LIST () "/" ABC//DEF     <=== must not do this
+       S: A002 OK done
+
+   On clients, the reference argument is chiefly used to implement a
+   "breakout facility", wherein the user may directly access a mailbox
+   outside the "current directory" hierarchy.  Client implementations
+   should have an operational mode that does not use the reference
+   argument.  This is to interoperate with older servers that did not
+   implement the reference argument properly.  While it's a good idea to
+   give the user access to a breakout facility, clients that do not
+   intend to do so should not use the reference argument at all.
+
+   Client implementations should always place a trailing hierarchy
+   delimiter on the reference argument.  This is because some servers
+   prepend the reference argument to the mailbox name without inserting
+   a hierarchy delimiter, while others do insert a hierarchy delimiter
+   if one is not already present.  A client that puts the delimiter in
+   will work with both varieties of server.
+
+   Client implementations that implement a breakout facility should
+   allow the user to choose whether or not to use a leading hierarchy
+   delimiter on the mailbox argument.  This is because the handling of a
+   leading mailbox hierarchy delimiter also varies from server to
+   server, and even between different mailstores on the same server.  In
+   some cases, a leading hierarchy delimiter means "discard the
+
+
+
+Leiba                        Informational                     [Page 18]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+   reference argument" (implementing the intended breakout facility),
+   thus:
+
+       C: A001 LIST ABC/ /DEF
+       S: * LIST () "/" /DEF
+       S: A001 OK done
+
+   In other cases, however, the two are catenated and the extra
+   hierarchy delimiter is discarded, thus:
+
+       C: A001 LIST ABC/ /DEF
+       S: * LIST () "/" ABC/DEF
+       S: A001 OK done
+
+   Client implementations must not assume that the server supports a
+   breakout facility, but may provide a way for the user to use one if
+   it is available.  Any breakout facility should be exported to the
+   user interface.  Note that there may be other "breakout" characters
+   besides the hierarchy delimiter (for instance, UNIX filesystem
+   servers are likely to use a leading "~" as well), and that their
+   interpretation is server-dependent.
+
+3.4.10.   Mailbox Hierarchy Delimiters
+
+   The server's selection of what to use as a mailbox hierarchy
+   delimiter is a difficult one, involving several issues: What
+   characters do users expect to see?  What characters can they enter
+   for a hierarchy delimiter if it is desired (or required) that the
+   user enter it?  What character can be used for the hierarchy
+   delimiter, noting that the chosen character can not otherwise be used
+   in the mailbox name?
+
+   Because some interfaces show users the hierarchy delimiters or allow
+   users to enter qualified mailbox names containing them, server
+   implementations should use delimiter characters that users generally
+   expect to see as name separators.  The most common characters used
+   for this are "/" (as in Unix file names), "\" (as in OS/2 and Windows
+   file names), and "." (as in news groups).  There is little to choose
+   among these apart from what users may expect or what is dictated by
+   the underlying file system, if any.  One consideration about using
+   "\" is that it's also a special character in the IMAP protocol. While
+   the use of other hierarchy delimiter characters is permissible, A
+   DESIGNER IS WELL ADVISED TO STAY WITH ONE FROM THIS SET unless the
+   server is intended for special purposes only.  Implementers might be
+   thinking about using characters such as "-", "_", ";", "&", "#", "@",
+   and "!", but they should be aware of the surprise to the user as well
+   as of the effect on URLs and other external specifications (since
+   some of these characters have special meanings there).  Also, a
+
+
+
+Leiba                        Informational                     [Page 19]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+   server that uses "\" (and clients of such a server) must remember to
+   escape that character in quoted strings or to send literals instead.
+   Literals are recommended over escaped characters in quoted strings in
+   order to maintain compatibility with older IMAP versions that did not
+   allow escaped characters in quoted strings (but check the grammar to
+   see where literals are allowed):
+
+       C: 001 LIST "" {13}
+       S: + send literal
+       C: this\%\%\%\h*
+       S: * LIST () "\\" {27}
+       S: this\is\a\mailbox\hierarchy
+       S: 001 OK LIST complete
+
+   In any case, a server should not use normal alpha-numeric characters
+   (such as "X" or "0") as delimiters; a user would be very surprised to
+   find that "EXPENDITURES" actually represented a two-level hierarchy.
+   And a server should not use characters that are non-printable or
+   difficult or impossible to enter on a standard US keyboard.  Control
+   characters, box-drawing characters, and characters from non-US
+   alphabets fit into this category.  Their use presents
+   interoperability problems that are best avoided.
+
+   The UTF-7 encoding of mailbox names also raises questions about what
+   to do with the hierarchy delimiters in encoded names: do we encode
+   each hierarchy level and separate them with delimiters, or do we
+   encode the fully qualified name, delimiters and all?  The answer for
+   IMAP is the former: encode each hierarchy level separately, and
+   insert delimiters between.  This makes it particularly important not
+   to use as a hierarchy delimiter a character that might cause
+   confusion with IMAP's modified UTF-7 [UTF-7 and RFC-2060] encoding.
+
+   To repeat: a server should use "/", "\", or "." as its hierarchy
+   delimiter.  The use of any other character is likely to cause
+   problems and is STRONGLY DISCOURAGED.
+
+3.4.11.   ALERT Response Codes
+
+   The protocol spec is very clear on the matter of what to do with
+   ALERT response codes, and yet there are many clients that violate it
+   so it needs to be said anyway: "The human-readable text contains a
+   special alert that must be presented to the user in a fashion that
+   calls the user's attention to the message."  That should be clear
+   enough, but I'll repeat it here: Clients must present ALERT text
+   clearly to the user.
+
+
+
+
+
+
+Leiba                        Informational                     [Page 20]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+3.4.12.   Deleting Mailboxes
+
+   The protocol does not guarantee that a client may delete a mailbox
+   that is not empty, though on some servers it is permissible and is,
+   in fact, much faster than the alternative or deleting all the
+   messages from the client.  If the client chooses to try to take
+   advantage of this possibility it must be prepared to use the other
+   method in the even that the more convenient one fails.  Further, a
+   client should not try to delete the mailbox that it has selected, but
+   should first close that mailbox; some servers do not permit the
+   deletion of the selected mailbox.
+
+   That said, a server should permit the deletion of a non-empty
+   mailbox; there's little reason to pass this work on to the client.
+   Moreover, forbidding this prevents the deletion of a mailbox that for
+   some reason can not be opened or expunged, leading to possible
+   denial-of-service problems.
+
+   Example:
+
+       [User tells the client to delete mailbox BANANA, which is
+       currently selected...]
+       C: 008 CLOSE
+       S: 008 OK done
+       C: 009 DELETE BANANA
+       S: 009 NO Delete failed; mailbox is not empty.
+       C: 010 SELECT BANANA
+       S: * ... untagged SELECT responses
+       S: 010 OK done
+       C: 011 STORE 1:* +FLAGS.SILENT \DELETED
+       S: 011 OK done
+       C: 012 CLOSE
+       S: 012 OK done
+       C: 013 DELETE BANANA
+       S: 013 OK done
+
+3.5.   A Word About Testing
+
+   Since the whole point of IMAP is interoperability, and since
+   interoperability can not be tested in a vacuum, the final
+   recommendation of this treatise is, "Test against EVERYTHING."  Test
+   your client against every server you can get an account on.  Test
+   your server with every client you can get your hands on.  Many
+   clients make limited test versions available on the Web for the
+   downloading.  Many server owners will give serious client developers
+   guest accounts for testing.  Contact them and ask.  NEVER assume that
+   because your client works with one or two servers, or because your
+   server does fine with one or two clients, you will interoperate well
+
+
+
+Leiba                        Informational                     [Page 21]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+   in general.
+
+   In particular, in addition to everything else, be sure to test
+   against the reference implementations: the PINE client, the
+   University of Washington server, and the Cyrus server.
+
+   See the following URLs on the web for more information here:
+
+       IMAP Products and Sources: http://www.imap.org/products.html
+       IMC MailConnect: http://www.imc.org/imc-mailconnect
+
+4. Security Considerations
+
+   This document describes behaviour of clients and servers that use the
+   IMAP4 protocol, and as such, has the same security considerations as
+   described in [RFC-2060].
+
+5. References
+
+   [RFC-2060]  Crispin, M., "Internet Message Access Protocol - Version
+               4rev1", RFC 2060, December 1996.
+
+   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC-2180]  Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC
+               2180, July 1997.
+
+   [UTF-8]     Yergeau, F., " UTF-8, a transformation format of Unicode
+               and ISO 10646", RFC 2044, October 1996.
+
+   [UTF-7]     Goldsmith, D. and M. Davis, "UTF-7, a Mail-Safe
+               Transformation Format of Unicode", RFC 2152, May 1997.
+
+   [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", Work in
+               Progress.
+
+6. Author's Address
+
+   Barry Leiba
+   IBM T.J. Watson Research Center
+   30 Saw Mill River Road
+   Hawthorne, NY  10532
+
+   Phone: 1-914-784-7941
+   EMail: leiba@watson.ibm.com
+
+
+
+
+
+Leiba                        Informational                     [Page 22]
+
+RFC 2683          IMAP4 Implementation Recommendations    September 1999
+
+
+7. Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Leiba                        Informational                     [Page 23]
+
diff --git a/docs/rfcs/rfc2821.txt b/docs/rfcs/rfc2821.txt
new file mode 100644
index 0000000..0eac911
--- /dev/null
+++ b/docs/rfcs/rfc2821.txt
@@ -0,0 +1,4427 @@
+
+
+
+
+
+
+Network Working Group                                 J. Klensin, Editor
+Request for Comments: 2821                             AT&T Laboratories
+Obsoletes: 821, 974, 1869                                     April 2001
+Updates: 1123
+Category: Standards Track
+
+
+                     Simple Mail Transfer Protocol
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document is a self-contained specification of the basic protocol
+   for the Internet electronic mail transport.  It consolidates, updates
+   and clarifies, but doesn't add new or change existing functionality
+   of the following:
+
+   -  the original SMTP (Simple Mail Transfer Protocol) specification of
+      RFC 821 [30],
+
+   -  domain name system requirements and implications for mail
+      transport from RFC 1035 [22] and RFC 974 [27],
+
+   -  the clarifications and applicability statements in RFC 1123 [2],
+      and
+
+   -  material drawn from the SMTP Extension mechanisms [19].
+
+   It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the
+   mail transport materials of RFC 1123).  However, RFC 821 specifies
+   some features that were not in significant use in the Internet by the
+   mid-1990s and (in appendices) some additional transport models.
+   Those sections are omitted here in the interest of clarity and
+   brevity; readers needing them should refer to RFC 821.
+
+
+
+
+
+
+Klensin                     Standards Track                     [Page 1]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   It also includes some additional material from RFC 1123 that required
+   amplification.  This material has been identified in multiple ways,
+   mostly by tracking flaming on various lists and newsgroups and
+   problems of unusual readings or interpretations that have appeared as
+   the SMTP extensions have been deployed.  Where this specification
+   moves beyond consolidation and actually differs from earlier
+   documents, it supersedes them technically as well as textually.
+
+   Although SMTP was designed as a mail transport and delivery protocol,
+   this specification also contains information that is important to its
+   use as a 'mail submission' protocol, as recommended for POP [3, 26]
+   and IMAP [6].  Additional submission issues are discussed in RFC 2476
+   [15].
+
+   Section 2.3 provides definitions of terms specific to this document.
+   Except when the historical terminology is necessary for clarity, this
+   document uses the current 'client' and 'server' terminology to
+   identify the sending and receiving SMTP processes, respectively.
+
+   A companion document [32] discusses message headers, message bodies
+   and formats and structures for them, and their relationship.
+
+Table of Contents
+
+   1. Introduction ..................................................  4
+   2. The SMTP Model ................................................  5
+   2.1 Basic Structure ..............................................  5
+   2.2 The Extension Model ..........................................  7
+   2.2.1 Background .................................................  7
+   2.2.2 Definition and Registration of Extensions ..................  8
+   2.3 Terminology ..................................................  9
+   2.3.1 Mail Objects ............................................... 10
+   2.3.2 Senders and Receivers ...................................... 10
+   2.3.3 Mail Agents and Message Stores ............................. 10
+   2.3.4 Host ....................................................... 11
+   2.3.5 Domain ..................................................... 11
+   2.3.6 Buffer and State Table ..................................... 11
+   2.3.7 Lines ...................................................... 12
+   2.3.8 Originator, Delivery, Relay, and Gateway Systems ........... 12
+   2.3.9 Message Content and Mail Data .............................. 13
+   2.3.10 Mailbox and Address ....................................... 13
+   2.3.11 Reply ..................................................... 13
+   2.4 General Syntax Principles and Transaction Model .............. 13
+   3. The SMTP Procedures: An Overview .............................. 15
+   3.1 Session Initiation ........................................... 15
+   3.2 Client Initiation ............................................ 16
+   3.3 Mail Transactions ............................................ 16
+   3.4 Forwarding for Address Correction or Updating ................ 19
+
+
+
+Klensin                     Standards Track                     [Page 2]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   3.5 Commands for Debugging Addresses ............................. 20
+   3.5.1 Overview ................................................... 20
+   3.5.2 VRFY Normal Response ....................................... 22
+   3.5.3 Meaning of VRFY or EXPN Success Response ................... 22
+   3.5.4 Semantics and Applications of EXPN ......................... 23
+   3.6 Domains ...................................................... 23
+   3.7 Relaying ..................................................... 24
+   3.8 Mail Gatewaying .............................................. 25
+   3.8.1 Header Fields in Gatewaying ................................ 26
+   3.8.2 Received Lines in Gatewaying ............................... 26
+   3.8.3 Addresses in Gatewaying .................................... 26
+   3.8.4 Other Header Fields in Gatewaying .......................... 27
+   3.8.5 Envelopes in Gatewaying .................................... 27
+   3.9 Terminating Sessions and Connections ......................... 27
+   3.10 Mailing Lists and Aliases ................................... 28
+   3.10.1 Alias ..................................................... 28
+   3.10.2 List ...................................................... 28
+   4. The SMTP Specifications ....................................... 29
+   4.1 SMTP Commands ................................................ 29
+   4.1.1 Command Semantics and Syntax ............................... 29
+   4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO) ................... 29
+   4.1.1.2 MAIL (MAIL) .............................................. 31
+   4.1.1.3 RECIPIENT (RCPT) ......................................... 31
+   4.1.1.4 DATA (DATA) .............................................. 33
+   4.1.1.5 RESET (RSET) ............................................. 34
+   4.1.1.6 VERIFY (VRFY) ............................................ 35
+   4.1.1.7 EXPAND (EXPN) ............................................ 35
+   4.1.1.8 HELP (HELP) .............................................. 35
+   4.1.1.9 NOOP (NOOP) .............................................. 35
+   4.1.1.10 QUIT (QUIT) ............................................. 36
+   4.1.2 Command Argument Syntax .................................... 36
+   4.1.3 Address Literals ........................................... 38
+   4.1.4 Order of Commands .......................................... 39
+   4.1.5 Private-use Commands ....................................... 40
+   4.2  SMTP Replies ................................................ 40
+   4.2.1 Reply Code Severities and Theory ........................... 42
+   4.2.2 Reply Codes by Function Groups ............................. 44
+   4.2.3  Reply Codes in Numeric Order .............................. 45
+   4.2.4 Reply Code 502 ............................................. 46
+   4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> .... 46
+   4.3 Sequencing of Commands and Replies ........................... 47
+   4.3.1 Sequencing Overview ........................................ 47
+   4.3.2 Command-Reply Sequences .................................... 48
+   4.4 Trace Information ............................................ 49
+   4.5 Additional Implementation Issues ............................. 53
+   4.5.1 Minimum Implementation ..................................... 53
+   4.5.2 Transparency ............................................... 53
+   4.5.3 Sizes and Timeouts ......................................... 54
+
+
+
+Klensin                     Standards Track                     [Page 3]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   4.5.3.1 Size limits and minimums ................................. 54
+   4.5.3.2 Timeouts ................................................. 56
+   4.5.4 Retry Strategies ........................................... 57
+   4.5.4.1 Sending Strategy ......................................... 58
+   4.5.4.2 Receiving Strategy ....................................... 59
+   4.5.5 Messages with a null reverse-path .......................... 59
+   5. Address Resolution and Mail Handling .......................... 60
+   6. Problem Detection and Handling ................................ 62
+   6.1 Reliable Delivery and Replies by Email ....................... 62
+   6.2 Loop Detection ............................................... 63
+   6.3 Compensating for Irregularities .............................. 63
+   7. Security Considerations ....................................... 64
+   7.1 Mail Security and Spoofing ................................... 64
+   7.2 "Blind" Copies ............................................... 65
+   7.3 VRFY, EXPN, and Security ..................................... 65
+   7.4 Information Disclosure in Announcements ...................... 66
+   7.5 Information Disclosure in Trace Fields ....................... 66
+   7.6 Information Disclosure in Message Forwarding ................. 67
+   7.7 Scope of Operation of SMTP Servers ........................... 67
+   8. IANA Considerations ........................................... 67
+   9. References .................................................... 68
+   10. Editor's Address ............................................. 70
+   11. Acknowledgments .............................................. 70
+   Appendices ....................................................... 71
+   A. TCP Transport Service ......................................... 71
+   B. Generating SMTP Commands from RFC 822 Headers ................. 71
+   C. Source Routes ................................................. 72
+   D. Scenarios ..................................................... 73
+   E. Other Gateway Issues .......................................... 76
+   F. Deprecated Features of RFC 821 ................................ 76
+   Full Copyright Statement ......................................... 79
+
+1. Introduction
+
+   The objective of the Simple Mail Transfer Protocol (SMTP) is to
+   transfer mail reliably and efficiently.
+
+   SMTP is independent of the particular transmission subsystem and
+   requires only a reliable ordered data stream channel.  While this
+   document specifically discusses transport over TCP, other transports
+   are possible.  Appendices to RFC 821 describe some of them.
+
+   An important feature of SMTP is its capability to transport mail
+   across networks, usually referred to as "SMTP mail relaying" (see
+   section 3.8).  A network consists of the mutually-TCP-accessible
+   hosts on the public Internet, the mutually-TCP-accessible hosts on a
+   firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN
+   environment utilizing a non-TCP transport-level protocol.  Using
+
+
+
+Klensin                     Standards Track                     [Page 4]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   SMTP, a process can transfer mail to another process on the same
+   network or to some other network via a relay or gateway process
+   accessible to both networks.
+
+   In this way, a mail message may pass through a number of intermediate
+   relay or gateway hosts on its path from sender to ultimate recipient.
+   The Mail eXchanger mechanisms of the domain name system [22, 27] (and
+   section 5 of this document) are used to identify the appropriate
+   next-hop destination for a message being transported.
+
+2. The SMTP Model
+
+2.1 Basic Structure
+
+   The SMTP design can be pictured as:
+
+               +----------+                +----------+
+   +------+    |          |                |          |
+   | User |<-->|          |      SMTP      |          |
+   +------+    |  Client- |Commands/Replies| Server-  |
+   +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
+   | File |<-->|          |    and Mail    |          |<-->| File |
+   |System|    |          |                |          |    |System|
+   +------+    +----------+                +----------+    +------+
+                SMTP client                SMTP server
+
+   When an SMTP client has a message to transmit, it establishes a two-
+   way transmission channel to an SMTP server.  The responsibility of an
+   SMTP client is to transfer mail messages to one or more SMTP servers,
+   or report its failure to do so.
+
+   The means by which a mail message is presented to an SMTP client, and
+   how that client determines the domain name(s) to which mail messages
+   are to be transferred is a local matter, and is not addressed by this
+   document.  In some cases, the domain name(s) transferred to, or
+   determined by, an SMTP client will identify the final destination(s)
+   of the mail message.  In other cases, common with SMTP clients
+   associated with implementations of the POP [3, 26] or IMAP [6]
+   protocols, or when the SMTP client is inside an isolated transport
+   service environment, the domain name determined will identify an
+   intermediate destination through which all mail messages are to be
+   relayed.  SMTP clients that transfer all traffic, regardless of the
+   target domain names associated with the individual messages, or that
+   do not maintain queues for retrying message transmissions that
+   initially cannot be completed, may otherwise conform to this
+   specification but are not considered fully-capable.  Fully-capable
+   SMTP implementations, including the relays used by these less capable
+
+
+
+
+Klensin                     Standards Track                     [Page 5]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   ones, and their destinations, are expected to support all of the
+   queuing, retrying, and alternate address functions discussed in this
+   specification.
+
+   The means by which an SMTP client, once it has determined a target
+   domain name, determines the identity of an SMTP server to which a
+   copy of a message is to be transferred, and then performs that
+   transfer, is covered by this document.  To effect a mail transfer to
+   an SMTP server, an SMTP client establishes a two-way transmission
+   channel to that SMTP server.  An SMTP client determines the address
+   of an appropriate host running an SMTP server by resolving a
+   destination domain name to either an intermediate Mail eXchanger host
+   or a final target host.
+
+   An SMTP server may be either the ultimate destination or an
+   intermediate "relay" (that is, it may assume the role of an SMTP
+   client after receiving the message) or "gateway" (that is, it may
+   transport the message further using some protocol other than SMTP).
+   SMTP commands are generated by the SMTP client and sent to the SMTP
+   server.  SMTP replies are sent from the SMTP server to the SMTP
+   client in response to the commands.
+
+   In other words, message transfer can occur in a single connection
+   between the original SMTP-sender and the final SMTP-recipient, or can
+   occur in a series of hops through intermediary systems.  In either
+   case, a formal handoff of responsibility for the message occurs: the
+   protocol requires that a server accept responsibility for either
+   delivering a message or properly reporting the failure to do so.
+
+   Once the transmission channel is established and initial handshaking
+   completed, the SMTP client normally initiates a mail transaction.
+   Such a transaction consists of a series of commands to specify the
+   originator and destination of the mail and transmission of the
+   message content (including any headers or other structure) itself.
+   When the same message is sent to multiple recipients, this protocol
+   encourages the transmission of only one copy of the data for all
+   recipients at the same destination (or intermediate relay) host.
+
+   The server responds to each command with a reply; replies may
+   indicate that the command was accepted, that additional commands are
+   expected, or that a temporary or permanent error condition exists.
+   Commands specifying the sender or recipients may include server-
+   permitted SMTP service extension requests as discussed in section
+   2.2.  The dialog is purposely lock-step, one-at-a-time, although this
+   can be modified by mutually-agreed extension requests such as command
+   pipelining [13].
+
+
+
+
+
+Klensin                     Standards Track                     [Page 6]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   Once a given mail message has been transmitted, the client may either
+   request that the connection be shut down or may initiate other mail
+   transactions.  In addition, an SMTP client may use a connection to an
+   SMTP server for ancillary services such as verification of email
+   addresses or retrieval of mailing list subscriber addresses.
+
+   As suggested above, this protocol provides mechanisms for the
+   transmission of mail.  This transmission normally occurs directly
+   from the sending user's host to the receiving user's host when the
+   two hosts are connected to the same transport service.  When they are
+   not connected to the same transport service, transmission occurs via
+   one or more relay SMTP servers.  An intermediate host that acts as
+   either an SMTP relay or as a gateway into some other transmission
+   environment is usually selected through the use of the domain name
+   service (DNS) Mail eXchanger mechanism.
+
+   Usually, intermediate hosts are determined via the DNS MX record, not
+   by explicit "source" routing (see section 5 and appendices C and
+   F.2).
+
+2.2 The Extension Model
+
+2.2.1 Background
+
+   In an effort that started in 1990, approximately a decade after RFC
+   821 was completed, the protocol was modified with a "service
+   extensions" model that permits the client and server to agree to
+   utilize shared functionality beyond the original SMTP requirements.
+   The SMTP extension mechanism defines a means whereby an extended SMTP
+   client and server may recognize each other, and the server can inform
+   the client as to the service extensions that it supports.
+
+   Contemporary SMTP implementations MUST support the basic extension
+   mechanisms.  For instance, servers MUST support the EHLO command even
+   if they do not implement any specific extensions and clients SHOULD
+   preferentially utilize EHLO rather than HELO.  (However, for
+   compatibility with older conforming implementations, SMTP clients and
+   servers MUST support the original HELO mechanisms as a fallback.)
+   Unless the different characteristics of HELO must be identified for
+   interoperability purposes, this document discusses only EHLO.
+
+   SMTP is widely deployed and high-quality implementations have proven
+   to be very robust.  However, the Internet community now considers
+   some services to be important that were not anticipated when the
+   protocol was first designed.  If support for those services is to be
+   added, it must be done in a way that permits older implementations to
+   continue working acceptably.  The extension framework consists of:
+
+
+
+
+Klensin                     Standards Track                     [Page 7]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   -  The SMTP command EHLO, superseding the earlier HELO,
+
+   -  a registry of SMTP service extensions,
+
+   -  additional parameters to the SMTP MAIL and RCPT commands, and
+
+   -  optional replacements for commands defined in this protocol, such
+      as for DATA in non-ASCII transmissions [33].
+
+   SMTP's strength comes primarily from its simplicity.  Experience with
+   many protocols has shown that protocols with few options tend towards
+   ubiquity, whereas protocols with many options tend towards obscurity.
+
+   Each and every extension, regardless of its benefits, must be
+   carefully scrutinized with respect to its implementation, deployment,
+   and interoperability costs.  In many cases, the cost of extending the
+   SMTP service will likely outweigh the benefit.
+
+2.2.2 Definition and Registration of Extensions
+
+   The IANA maintains a registry of SMTP service extensions.  A
+   corresponding EHLO keyword value is associated with each extension.
+   Each service extension registered with the IANA must be defined in a
+   formal standards-track or IESG-approved experimental protocol
+   document.  The definition must include:
+
+   -  the textual name of the SMTP service extension;
+
+   -  the EHLO keyword value associated with the extension;
+
+   -  the syntax and possible values of parameters associated with the
+      EHLO keyword value;
+
+   -  any additional SMTP verbs associated with the extension
+      (additional verbs will usually be, but are not required to be, the
+      same as the EHLO keyword value);
+
+   -  any new parameters the extension associates with the MAIL or RCPT
+      verbs;
+
+   -  a description of how support for the extension affects the
+      behavior of a server and client SMTP; and,
+
+   -  the increment by which the extension is increasing the maximum
+      length of the commands MAIL and/or RCPT, over that specified in
+      this standard.
+
+
+
+
+
+Klensin                     Standards Track                     [Page 8]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   In addition, any EHLO keyword value starting with an upper or lower
+   case "X" refers to a local SMTP service extension used exclusively
+   through bilateral agreement.  Keywords beginning with "X" MUST NOT be
+   used in a registered service extension.  Conversely, keyword values
+   presented in the EHLO response that do not begin with "X" MUST
+   correspond to a standard, standards-track, or IESG-approved
+   experimental SMTP service extension registered with IANA.  A
+   conforming server MUST NOT offer non-"X"-prefixed keyword values that
+   are not described in a registered extension.
+
+   Additional verbs and parameter names are bound by the same rules as
+   EHLO keywords; specifically, verbs beginning with "X" are local
+   extensions that may not be registered or standardized.  Conversely,
+   verbs not beginning with "X" must always be registered.
+
+2.3 Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described below.
+
+   1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that
+      the definition is an absolute requirement of the specification.
+
+   2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
+      definition is an absolute prohibition of the specification.
+
+   3. SHOULD   This word, or the adjective "RECOMMENDED", mean that
+      there may exist valid reasons in particular circumstances to
+      ignore a particular item, but the full implications must be
+      understood and carefully weighed before choosing a different
+      course.
+
+   4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean
+      that there may exist valid reasons in particular circumstances
+      when the particular behavior is acceptable or even useful, but the
+      full implications should be understood and the case carefully
+      weighed before implementing any behavior described with this
+      label.
+
+   5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
+      truly optional.  One vendor may choose to include the item because
+      a particular marketplace requires it or because the vendor feels
+      that it enhances the product while another vendor may omit the
+      same item.  An implementation which does not include a particular
+      option MUST be prepared to interoperate with another
+      implementation which does include the option, though perhaps with
+      reduced functionality.  In the same vein an implementation which
+
+
+
+Klensin                     Standards Track                     [Page 9]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      does include a particular option MUST be prepared to interoperate
+      with another implementation which does not include the option
+      (except, of course, for the feature the option provides.)
+
+2.3.1 Mail Objects
+
+   SMTP transports a mail object.  A mail object contains an envelope
+   and content.
+
+   The SMTP envelope is sent as a series of SMTP protocol units
+   (described in section 3).  It consists of an originator address (to
+   which error reports should be directed); one or more recipient
+   addresses; and optional protocol extension material.  Historically,
+   variations on the recipient address specification command (RCPT TO)
+   could be used to specify alternate delivery modes, such as immediate
+   display; those variations have now been deprecated (see appendix F,
+   section F.6).
+
+   The SMTP content is sent in the SMTP DATA protocol unit and has two
+   parts:  the headers and the body.  If the content conforms to other
+   contemporary standards, the headers form a collection of field/value
+   pairs structured as in the message format specification [32]; the
+   body, if structured, is defined according to MIME [12].  The content
+   is textual in nature, expressed using the US-ASCII repertoire [1].
+   Although SMTP extensions (such as "8BITMIME" [20]) may relax this
+   restriction for the content body, the content headers are always
+   encoded using the US-ASCII repertoire.  A MIME extension [23] defines
+   an algorithm for representing header values outside the US-ASCII
+   repertoire, while still encoding them using the US-ASCII repertoire.
+
+2.3.2 Senders and Receivers
+
+   In RFC 821, the two hosts participating in an SMTP transaction were
+   described as the "SMTP-sender" and "SMTP-receiver".  This document
+   has been changed to reflect current industry terminology and hence
+   refers to them as the "SMTP client" (or sometimes just "the client")
+   and "SMTP server" (or just "the server"), respectively.  Since a
+   given host may act both as server and client in a relay situation,
+   "receiver" and "sender" terminology is still used where needed for
+   clarity.
+
+2.3.3 Mail Agents and Message Stores
+
+   Additional mail system terminology became common after RFC 821 was
+   published and, where convenient, is used in this specification.  In
+   particular, SMTP servers and clients provide a mail transport service
+   and therefore act as "Mail Transfer Agents" (MTAs).  "Mail User
+   Agents" (MUAs or UAs) are normally thought of as the sources and
+
+
+
+Klensin                     Standards Track                    [Page 10]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   targets of mail.  At the source, an MUA might collect mail to be
+   transmitted from a user and hand it off to an MTA; the final
+   ("delivery") MTA would be thought of as handing the mail off to an
+   MUA (or at least transferring responsibility to it, e.g., by
+   depositing the message in a "message store").  However, while these
+   terms are used with at least the appearance of great precision in
+   other environments, the implied boundaries between MUAs and MTAs
+   often do not accurately match common, and conforming, practices with
+   Internet mail.  Hence, the reader should be cautious about inferring
+   the strong relationships and responsibilities that might be implied
+   if these terms were used elsewhere.
+
+2.3.4 Host
+
+   For the purposes of this specification, a host is a computer system
+   attached to the Internet (or, in some cases, to a private TCP/IP
+   network) and supporting the SMTP protocol.  Hosts are known by names
+   (see "domain"); identifying them by numerical address is discouraged.
+
+2.3.5 Domain
+
+   A domain (or domain name) consists of one or more dot-separated
+   components.  These components ("labels" in DNS terminology [22]) are
+   restricted for SMTP purposes to consist of a sequence of letters,
+   digits, and hyphens drawn from the ASCII character set [1].  Domain
+   names are used as names of hosts and of other entities in the domain
+   name hierarchy.  For example, a domain may refer to an alias (label
+   of a CNAME RR) or the label of Mail eXchanger records to be used to
+   deliver mail instead of representing a host name.  See [22] and
+   section 5 of this specification.
+
+   The domain name, as described in this document and in [22], is the
+   entire, fully-qualified name (often referred to as an "FQDN").  A
+   domain name that is not in FQDN form is no more than a local alias.
+   Local aliases MUST NOT appear in any SMTP transaction.
+
+2.3.6 Buffer and State Table
+
+   SMTP sessions are stateful, with both parties carefully maintaining a
+   common view of the current state.  In this document we model this
+   state by a virtual "buffer" and a "state table" on the server which
+   may be used by the client to, for example, "clear the buffer" or
+   "reset the state table," causing the information in the buffer to be
+   discarded and the state to be returned to some previous state.
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 11]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+2.3.7 Lines
+
+   SMTP commands and, unless altered by a service extension, message
+   data, are transmitted in "lines".  Lines consist of zero or more data
+   characters terminated by the sequence ASCII character "CR" (hex value
+   0D) followed immediately by ASCII character "LF" (hex value 0A).
+   This termination sequence is denoted as <CRLF> in this document.
+   Conforming implementations MUST NOT recognize or generate any other
+   character or character sequence as a line terminator.  Limits MAY be
+   imposed on line lengths by servers (see section 4.5.3).
+
+   In addition, the appearance of "bare" "CR" or "LF" characters in text
+   (i.e., either without the other) has a long history of causing
+   problems in mail implementations and applications that use the mail
+   system as a tool.  SMTP client implementations MUST NOT transmit
+   these characters except when they are intended as line terminators
+   and then MUST, as indicated above, transmit them only as a <CRLF>
+   sequence.
+
+2.3.8 Originator, Delivery, Relay, and Gateway Systems
+
+   This specification makes a distinction among four types of SMTP
+   systems, based on the role those systems play in transmitting
+   electronic mail.  An "originating" system (sometimes called an SMTP
+   originator) introduces mail into the Internet or, more generally,
+   into a transport service environment.  A "delivery" SMTP system is
+   one that receives mail from a transport service environment and
+   passes it to a mail user agent or deposits it in a message store
+   which a mail user agent is expected to subsequently access.  A
+   "relay" SMTP system (usually referred to just as a "relay") receives
+   mail from an SMTP client and transmits it, without modification to
+   the message data other than adding trace information, to another SMTP
+   server for further relaying or for delivery.
+
+   A "gateway" SMTP system (usually referred to just as a "gateway")
+   receives mail from a client system in one transport environment and
+   transmits it to a server system in another transport environment.
+   Differences in protocols or message semantics between the transport
+   environments on either side of a gateway may require that the gateway
+   system perform transformations to the message that are not permitted
+   to SMTP relay systems.  For the purposes of this specification,
+   firewalls that rewrite addresses should be considered as gateways,
+   even if SMTP is used on both sides of them (see [11]).
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 12]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+2.3.9 Message Content and Mail Data
+
+   The terms "message content" and "mail data" are used interchangeably
+   in this document to describe the material transmitted after the DATA
+   command is accepted and before the end of data indication is
+   transmitted.  Message content includes message headers and the
+   possibly-structured message body.  The MIME specification [12]
+   provides the standard mechanisms for structured message bodies.
+
+2.3.10 Mailbox and Address
+
+   As used in this specification, an "address" is a character string
+   that identifies a user to whom mail will be sent or a location into
+   which mail will be deposited.  The term "mailbox" refers to that
+   depository.  The two terms are typically used interchangeably unless
+   the distinction between the location in which mail is placed (the
+   mailbox) and a reference to it (the address) is important.  An
+   address normally consists of user and domain specifications.  The
+   standard mailbox naming convention is defined to be "local-
+   part@domain": contemporary usage permits a much broader set of
+   applications than simple "user names".  Consequently, and due to a
+   long history of problems when intermediate hosts have attempted to
+   optimize transport by modifying them, the local-part MUST be
+   interpreted and assigned semantics only by the host specified in the
+   domain part of the address.
+
+2.3.11 Reply
+
+   An SMTP reply is an acknowledgment (positive or negative) sent from
+   receiver to sender via the transmission channel in response to a
+   command.  The general form of a reply is a numeric completion code
+   (indicating failure or success) usually followed by a text string.
+   The codes are for use by programs and the text is usually intended
+   for human users.  Recent work [34] has specified further structuring
+   of the reply strings, including the use of supplemental and more
+   specific completion codes.
+
+2.4 General Syntax Principles and Transaction Model
+
+   SMTP commands and replies have a rigid syntax.  All commands begin
+   with a command verb.  All Replies begin with a three digit numeric
+   code.  In some commands and replies, arguments MUST follow the verb
+   or reply code.  Some commands do not accept arguments (after the
+   verb), and some reply codes are followed, sometimes optionally, by
+   free form text.  In both cases, where text appears, it is separated
+   from the verb or reply code by a space character.  Complete
+   definitions of commands and replies appear in section 4.
+
+
+
+
+Klensin                     Standards Track                    [Page 13]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
+   and extension name keywords) are not case sensitive, with the sole
+   exception in this specification of a mailbox local-part (SMTP
+   Extensions may explicitly specify case-sensitive elements).  That is,
+   a command verb, an argument value other than a mailbox local-part,
+   and free form text MAY be encoded in upper case, lower case, or any
+   mixture of upper and lower case with no impact on its meaning.  This
+   is NOT true of a mailbox local-part.  The local-part of a mailbox
+   MUST BE treated as case sensitive.  Therefore, SMTP implementations
+   MUST take care to preserve the case of mailbox local-parts.  Mailbox
+   domains are not case sensitive.  In particular, for some hosts the
+   user "smith" is different from the user "Smith".  However, exploiting
+   the case sensitivity of mailbox local-parts impedes interoperability
+   and is discouraged.
+
+   A few SMTP servers, in violation of this specification (and RFC 821)
+   require that command verbs be encoded by clients in upper case.
+   Implementations MAY wish to employ this encoding to accommodate those
+   servers.
+
+   The argument field consists of a variable length character string
+   ending with the end of the line, i.e., with the character sequence
+   <CRLF>.  The receiver will take no action until this sequence is
+   received.
+
+   The syntax for each command is shown with the discussion of that
+   command.  Common elements and parameters are shown in section 4.1.2.
+
+   Commands and replies are composed of characters from the ASCII
+   character set [1].  When the transport service provides an 8-bit byte
+   (octet) transmission channel, each 7-bit character is transmitted
+   right justified in an octet with the high order bit cleared to zero.
+   More specifically, the unextended SMTP service provides seven bit
+   transport only.  An originating SMTP client which has not
+   successfully negotiated an appropriate extension with a particular
+   server MUST NOT transmit messages with information in the high-order
+   bit of octets.  If such messages are transmitted in violation of this
+   rule, receiving SMTP servers MAY clear the high-order bit or reject
+   the message as invalid.  In general, a relay SMTP SHOULD assume that
+   the message content it has received is valid and, assuming that the
+   envelope permits doing so, relay it without inspecting that content.
+   Of course, if the content is mislabeled and the data path cannot
+   accept the actual content, this may result in ultimate delivery of a
+   severely garbled message to the recipient.  Delivery SMTP systems MAY
+   reject ("bounce") such messages rather than deliver them.  No sending
+   SMTP system is permitted to send envelope commands in any character
+
+
+
+
+
+Klensin                     Standards Track                    [Page 14]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   set other than US-ASCII; receiving systems SHOULD reject such
+   commands, normally using "500 syntax error - invalid character"
+   replies.
+
+   Eight-bit message content transmission MAY be requested of the server
+   by a client using extended SMTP facilities, notably the "8BITMIME"
+   extension [20].  8BITMIME SHOULD be supported by SMTP servers.
+   However, it MUST not be construed as authorization to transmit
+   unrestricted eight bit material.  8BITMIME MUST NOT be requested by
+   senders for material with the high bit on that is not in MIME format
+   with an appropriate content-transfer encoding; servers MAY reject
+   such messages.
+
+   The metalinguistic notation used in this document corresponds to the
+   "Augmented BNF" used in other Internet mail system documents.  The
+   reader who is not familiar with that syntax should consult the ABNF
+   specification [8].  Metalanguage terms used in running text are
+   surrounded by pointed brackets (e.g., <CRLF>) for clarity.
+
+3. The SMTP Procedures: An Overview
+
+   This section contains descriptions of the procedures used in SMTP:
+   session initiation, the mail transaction, forwarding mail, verifying
+   mailbox names and expanding mailing lists, and the opening and
+   closing exchanges.  Comments on relaying, a note on mail domains, and
+   a discussion of changing roles are included at the end of this
+   section.  Several complete scenarios are presented in appendix D.
+
+3.1 Session Initiation
+
+   An SMTP session is initiated when a client opens a connection to a
+   server and the server responds with an opening message.
+
+   SMTP server implementations MAY include identification of their
+   software and version information in the connection greeting reply
+   after the 220 code, a practice that permits more efficient isolation
+   and repair of any problems.  Implementations MAY make provision for
+   SMTP servers to disable the software and version announcement where
+   it causes security concerns.  While some systems also identify their
+   contact point for mail problems, this is not a substitute for
+   maintaining the required "postmaster" address (see section 4.5.1).
+
+   The SMTP protocol allows a server to formally reject a transaction
+   while still allowing the initial connection as follows: a 554
+   response MAY be given in the initial connection opening message
+   instead of the 220.  A server taking this approach MUST still wait
+   for the client to send a QUIT (see section 4.1.1.10) before closing
+   the connection and SHOULD respond to any intervening commands with
+
+
+
+Klensin                     Standards Track                    [Page 15]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   "503 bad sequence of commands".  Since an attempt to make an SMTP
+   connection to such a system is probably in error, a server returning
+   a 554 response on connection opening SHOULD provide enough
+   information in the reply text to facilitate debugging of the sending
+   system.
+
+3.2 Client Initiation
+
+   Once the server has sent the welcoming message and the client has
+   received it, the client normally sends the EHLO command to the
+   server, indicating the client's identity.  In addition to opening the
+   session, use of EHLO indicates that the client is able to process
+   service extensions and requests that the server provide a list of the
+   extensions it supports.  Older SMTP systems which are unable to
+   support service extensions and contemporary clients which do not
+   require service extensions in the mail session being initiated, MAY
+   use HELO instead of EHLO.  Servers MUST NOT return the extended
+   EHLO-style response to a HELO command.  For a particular connection
+   attempt, if the server returns a "command not recognized" response to
+   EHLO, the client SHOULD be able to fall back and send HELO.
+
+   In the EHLO command the host sending the command identifies itself;
+   the command may be interpreted as saying "Hello, I am <domain>" (and,
+   in the case of EHLO, "and I support service extension requests").
+
+3.3 Mail Transactions
+
+   There are three steps to SMTP mail transactions.  The transaction
+   starts with a MAIL command which gives the sender identification.
+   (In general, the MAIL command may be sent only when no mail
+   transaction is in progress; see section 4.1.4.)  A series of one or
+   more RCPT commands follows giving the receiver information.  Then a
+   DATA command initiates transfer of the mail data and is terminated by
+   the "end of mail" data indicator, which also confirms the
+   transaction.
+
+   The first step in the procedure is the MAIL command.
+
+      MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
+
+   This command tells the SMTP-receiver that a new mail transaction is
+   starting and to reset all its state tables and buffers, including any
+   recipients or mail data.  The <reverse-path> portion of the first or
+   only argument contains the source mailbox (between "<" and ">"
+   brackets), which can be used to report errors (see section 4.2 for a
+   discussion of error reporting).  If accepted, the SMTP server returns
+   a 250 OK reply.  If the mailbox specification is not acceptable for
+   some reason, the server MUST return a reply indicating whether the
+
+
+
+Klensin                     Standards Track                    [Page 16]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   failure is permanent (i.e., will occur again if the client tries to
+   send the same address again) or temporary (i.e., the address might be
+   accepted if the client tries again later).  Despite the apparent
+   scope of this requirement, there are circumstances in which the
+   acceptability of the reverse-path may not be determined until one or
+   more forward-paths (in RCPT commands) can be examined.  In those
+   cases, the server MAY reasonably accept the reverse-path (with a 250
+   reply) and then report problems after the forward-paths are received
+   and examined.  Normally, failures produce 550 or 553 replies.
+
+   Historically, the <reverse-path> can contain more than just a
+   mailbox, however, contemporary systems SHOULD NOT use source routing
+   (see appendix C).
+
+   The optional <mail-parameters> are associated with negotiated SMTP
+   service extensions (see section 2.2).
+
+   The second step in the procedure is the RCPT command.
+
+      RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
+
+   The first or only argument to this command includes a forward-path
+   (normally a mailbox and domain, always surrounded by "<" and ">"
+   brackets) identifying one recipient.  If accepted, the SMTP server
+   returns a 250 OK reply and stores the forward-path.  If the recipient
+   is known not to be a deliverable address, the SMTP server returns a
+   550 reply, typically with a string such as "no such user - " and the
+   mailbox name (other circumstances and reply codes are possible).
+   This step of the procedure can be repeated any number of times.
+
+   The <forward-path> can contain more than just a mailbox.
+   Historically, the <forward-path> can be a source routing list of
+   hosts and the destination mailbox, however, contemporary SMTP clients
+   SHOULD NOT utilize source routes (see appendix C).  Servers MUST be
+   prepared to encounter a list of source routes in the forward path,
+   but SHOULD ignore the routes or MAY decline to support the relaying
+   they imply.  Similarly, servers MAY decline to accept mail that is
+   destined for other hosts or systems.  These restrictions make a
+   server useless as a relay for clients that do not support full SMTP
+   functionality.  Consequently, restricted-capability clients MUST NOT
+   assume that any SMTP server on the Internet can be used as their mail
+   processing (relaying) site.  If a RCPT command appears without a
+   previous MAIL command, the server MUST return a 503 "Bad sequence of
+   commands" response.  The optional <rcpt-parameters> are associated
+   with negotiated SMTP service extensions (see section 2.2).
+
+   The third step in the procedure is the DATA command (or some
+   alternative specified in a service extension).
+
+
+
+Klensin                     Standards Track                    [Page 17]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      DATA <CRLF>
+
+   If accepted, the SMTP server returns a 354 Intermediate reply and
+   considers all succeeding lines up to but not including the end of
+   mail data indicator to be the message text.  When the end of text is
+   successfully received and stored the SMTP-receiver sends a 250 OK
+   reply.
+
+   Since the mail data is sent on the transmission channel, the end of
+   mail data must be indicated so that the command and reply dialog can
+   be resumed.  SMTP indicates the end of the mail data by sending a
+   line containing only a "." (period or full stop).  A transparency
+   procedure is used to prevent this from interfering with the user's
+   text (see section 4.5.2).
+
+   The end of mail data indicator also confirms the mail transaction and
+   tells the SMTP server to now process the stored recipients and mail
+   data.  If accepted, the SMTP server returns a 250 OK reply.  The DATA
+   command can fail at only two points in the protocol exchange:
+
+   -  If there was no MAIL, or no RCPT, command, or all such commands
+      were rejected, the server MAY return a "command out of sequence"
+      (503) or "no valid recipients" (554) reply in response to the DATA
+      command.  If one of those replies (or any other 5yz reply) is
+      received, the client MUST NOT send the message data; more
+      generally, message data MUST NOT be sent unless a 354 reply is
+      received.
+
+   -  If the verb is initially accepted and the 354 reply issued, the
+      DATA command should fail only if the mail transaction was
+      incomplete (for example, no recipients), or if resources were
+      unavailable (including, of course, the server unexpectedly
+      becoming unavailable), or if the server determines that the
+      message should be rejected for policy or other reasons.
+
+   However, in practice, some servers do not perform recipient
+   verification until after the message text is received.  These servers
+   SHOULD treat a failure for one or more recipients as a "subsequent
+   failure" and return a mail message as discussed in section 6.  Using
+   a "550 mailbox not found" (or equivalent) reply code after the data
+   are accepted makes it difficult or impossible for the client to
+   determine which recipients failed.
+
+   When RFC 822 format [7, 32] is being used, the mail data include the
+   memo header items such as Date, Subject, To, Cc, From.  Server SMTP
+   systems SHOULD NOT reject messages based on perceived defects in the
+   RFC 822 or MIME [12] message header or message body.  In particular,
+
+
+
+
+Klensin                     Standards Track                    [Page 18]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   they MUST NOT reject messages in which the numbers of Resent-fields
+   do not match or Resent-to appears without Resent-from and/or Resent-
+   date.
+
+   Mail transaction commands MUST be used in the order discussed above.
+
+3.4 Forwarding for Address Correction or Updating
+
+   Forwarding support is most often required to consolidate and simplify
+   addresses within, or relative to, some enterprise and less frequently
+   to establish addresses to link a person's prior address with current
+   one.  Silent forwarding of messages (without server notification to
+   the sender), for security or non-disclosure purposes, is common in
+   the contemporary Internet.
+
+   In both the enterprise and the "new address" cases, information
+   hiding (and sometimes security) considerations argue against exposure
+   of the "final" address through the SMTP protocol as a side-effect of
+   the forwarding activity.  This may be especially important when the
+   final address may not even be reachable by the sender.  Consequently,
+   the "forwarding" mechanisms described in section 3.2 of RFC 821, and
+   especially the 251 (corrected destination) and 551 reply codes from
+   RCPT must be evaluated carefully by implementers and, when they are
+   available, by those configuring systems.
+
+   In particular:
+
+   *  Servers MAY forward messages when they are aware of an address
+      change.  When they do so, they MAY either provide address-updating
+      information with a 251 code, or may forward "silently" and return
+      a 250 code.  But, if a 251 code is used, they MUST NOT assume that
+      the client will actually update address information or even return
+      that information to the user.
+
+   Alternately,
+
+   *  Servers MAY reject or bounce messages when they are not
+      deliverable when addressed.  When they do so, they MAY either
+      provide address-updating information with a 551 code, or may
+      reject the message as undeliverable with a 550 code and no
+      address-specific information.  But, if a 551 code is used, they
+      MUST NOT assume that the client will actually update address
+      information or even return that information to the user.
+
+   SMTP server implementations that support the 251 and/or 551 reply
+   codes are strongly encouraged to provide configuration mechanisms so
+   that sites which conclude that they would undesirably disclose
+   information can disable or restrict their use.
+
+
+
+Klensin                     Standards Track                    [Page 19]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+3.5 Commands for Debugging Addresses
+
+3.5.1 Overview
+
+   SMTP provides commands to verify a user name or obtain the content of
+   a mailing list.  This is done with the VRFY and EXPN commands, which
+   have character string arguments.  Implementations SHOULD support VRFY
+   and EXPN (however, see section 3.5.2 and 7.3).
+
+   For the VRFY command, the string is a user name or a user name and
+   domain (see below).  If a normal (i.e., 250) response is returned,
+   the response MAY include the full name of the user and MUST include
+   the mailbox of the user.  It MUST be in either of the following
+   forms:
+
+      User Name <local-part@domain>
+      local-part@domain
+
+   When a name that is the argument to VRFY could identify more than one
+   mailbox, the server MAY either note the ambiguity or identify the
+   alternatives.  In other words, any of the following are legitimate
+   response to VRFY:
+
+      553 User ambiguous
+
+   or
+
+      553- Ambiguous;  Possibilities are
+      553-Joe Smith <jsmith@foo.com>
+      553-Harry Smith <hsmith@foo.com>
+      553 Melvin Smith <dweep@foo.com>
+
+   or
+
+      553-Ambiguous;  Possibilities
+      553- <jsmith@foo.com>
+      553- <hsmith@foo.com>
+      553 <dweep@foo.com>
+
+   Under normal circumstances, a client receiving a 553 reply would be
+   expected to expose the result to the user.  Use of exactly the forms
+   given, and the "user ambiguous" or "ambiguous" keywords, possibly
+   supplemented by extended reply codes such as those described in [34],
+   will facilitate automated translation into other languages as needed.
+   Of course, a client that was highly automated or that was operating
+   in another language than English, might choose to try to translate
+   the response, to return some other indication to the user than the
+
+
+
+
+Klensin                     Standards Track                    [Page 20]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   literal text of the reply, or to take some automated action such as
+   consulting a directory service for additional information before
+   reporting to the user.
+
+   For the EXPN command, the string identifies a mailing list, and the
+   successful (i.e., 250) multiline response MAY include the full name
+   of the users and MUST give the mailboxes on the mailing list.
+
+   In some hosts the distinction between a mailing list and an alias for
+   a single mailbox is a bit fuzzy, since a common data structure may
+   hold both types of entries, and it is possible to have mailing lists
+   containing only one mailbox.  If a request is made to apply VRFY to a
+   mailing list, a positive response MAY be given if a message so
+   addressed would be delivered to everyone on the list, otherwise an
+   error SHOULD be reported (e.g., "550 That is a mailing list, not a
+   user" or "252 Unable to verify members of mailing list").  If a
+   request is made to expand a user name, the server MAY return a
+   positive response consisting of a list containing one name, or an
+   error MAY be reported (e.g., "550 That is a user name, not a mailing
+   list").
+
+   In the case of a successful multiline reply (normal for EXPN) exactly
+   one mailbox is to be specified on each line of the reply.  The case
+   of an ambiguous request is discussed above.
+
+   "User name" is a fuzzy term and has been used deliberately.  An
+   implementation of the VRFY or EXPN commands MUST include at least
+   recognition of local mailboxes as "user names".  However, since
+   current Internet practice often results in a single host handling
+   mail for multiple domains, hosts, especially hosts that provide this
+   functionality, SHOULD accept the "local-part@domain" form as a "user
+   name"; hosts MAY also choose to recognize other strings as "user
+   names".
+
+   The case of expanding a mailbox list requires a multiline reply, such
+   as:
+
+      C: EXPN Example-People
+      S: 250-Jon Postel <Postel@isi.edu>
+      S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
+      S: 250 Sam Q. Smith <SQSmith@specific.generic.com>
+
+   or
+
+      C: EXPN Executive-Washroom-List
+      S: 550 Access Denied to You.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 21]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   The character string arguments of the VRFY and EXPN commands cannot
+   be further restricted due to the variety of implementations of the
+   user name and mailbox list concepts.  On some systems it may be
+   appropriate for the argument of the EXPN command to be a file name
+   for a file containing a mailing list, but again there are a variety
+   of file naming conventions in the Internet.  Similarly, historical
+   variations in what is returned by these commands are such that the
+   response SHOULD be interpreted very carefully, if at all, and SHOULD
+   generally only be used for diagnostic purposes.
+
+3.5.2 VRFY Normal Response
+
+   When normal (2yz or 551) responses are returned from a VRFY or EXPN
+   request, the reply normally includes the mailbox name, i.e.,
+   "<local-part@domain>", where "domain" is a fully qualified domain
+   name, MUST appear in the syntax.  In circumstances exceptional enough
+   to justify violating the intent of this specification, free-form text
+   MAY be returned.  In order to facilitate parsing by both computers
+   and people, addresses SHOULD appear in pointed brackets.  When
+   addresses, rather than free-form debugging information, are returned,
+   EXPN and VRFY MUST return only valid domain addresses that are usable
+   in SMTP RCPT commands.  Consequently, if an address implies delivery
+   to a program or other system, the mailbox name used to reach that
+   target MUST be given.  Paths (explicit source routes) MUST NOT be
+   returned by VRFY or EXPN.
+
+   Server implementations SHOULD support both VRFY and EXPN.  For
+   security reasons, implementations MAY provide local installations a
+   way to disable either or both of these commands through configuration
+   options or the equivalent.  When these commands are supported, they
+   are not required to work across relays when relaying is supported.
+   Since they were both optional in RFC 821, they MUST be listed as
+   service extensions in an EHLO response, if they are supported.
+
+3.5.3 Meaning of VRFY or EXPN Success Response
+
+   A server MUST NOT return a 250 code in response to a VRFY or EXPN
+   command unless it has actually verified the address.  In particular,
+   a server MUST NOT return 250 if all it has done is to verify that the
+   syntax given is valid.  In that case, 502 (Command not implemented)
+   or 500 (Syntax error, command unrecognized) SHOULD be returned.  As
+   stated elsewhere, implementation (in the sense of actually validating
+   addresses and returning information) of VRFY and EXPN are strongly
+   recommended.  Hence, implementations that return 500 or 502 for VRFY
+   are not in full compliance with this specification.
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 22]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   There may be circumstances where an address appears to be valid but
+   cannot reasonably be verified in real time, particularly when a
+   server is acting as a mail exchanger for another server or domain.
+   "Apparent validity" in this case would normally involve at least
+   syntax checking and might involve verification that any domains
+   specified were ones to which the host expected to be able to relay
+   mail.  In these situations, reply code 252 SHOULD be returned.  These
+   cases parallel the discussion of RCPT verification discussed in
+   section 2.1.  Similarly, the discussion in section 3.4 applies to the
+   use of reply codes 251 and 551 with VRFY (and EXPN) to indicate
+   addresses that are recognized but that would be forwarded or bounced
+   were mail received for them.  Implementations generally SHOULD be
+   more aggressive about address verification in the case of VRFY than
+   in the case of RCPT, even if it takes a little longer to do so.
+
+3.5.4 Semantics and Applications of EXPN
+
+   EXPN is often very useful in debugging and understanding problems
+   with mailing lists and multiple-target-address aliases.  Some systems
+   have attempted to use source expansion of mailing lists as a means of
+   eliminating duplicates.  The propagation of aliasing systems with
+   mail on the Internet, for hosts (typically with MX and CNAME DNS
+   records), for mailboxes (various types of local host aliases), and in
+   various proxying arrangements, has made it nearly impossible for
+   these strategies to work consistently, and mail systems SHOULD NOT
+   attempt them.
+
+3.6 Domains
+
+   Only resolvable, fully-qualified, domain names (FQDNs) are permitted
+   when domain names are used in SMTP.  In other words, names that can
+   be resolved to MX RRs or A RRs (as discussed in section 5) are
+   permitted, as are CNAME RRs whose targets can be resolved, in turn,
+   to MX or A RRs.  Local nicknames or unqualified names MUST NOT be
+   used.  There are two exceptions to the rule requiring FQDNs:
+
+   -  The domain name given in the EHLO command MUST BE either a primary
+      host name (a domain name that resolves to an A RR) or, if the host
+      has no name, an address literal as described in section 4.1.1.1.
+
+   -  The reserved mailbox name "postmaster" may be used in a RCPT
+      command without domain qualification (see section 4.1.1.3) and
+      MUST be accepted if so used.
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 23]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+3.7 Relaying
+
+   In general, the availability of Mail eXchanger records in the domain
+   name system [22, 27] makes the use of explicit source routes in the
+   Internet mail system unnecessary.  Many historical problems with
+   their interpretation have made their use undesirable.  SMTP clients
+   SHOULD NOT generate explicit source routes except under unusual
+   circumstances.  SMTP servers MAY decline to act as mail relays or to
+   accept addresses that specify source routes.  When route information
+   is encountered, SMTP servers are also permitted to ignore the route
+   information and simply send to the final destination specified as the
+   last element in the route and SHOULD do so.  There has been an
+   invalid practice of using names that do not appear in the DNS as
+   destination names, with the senders counting on the intermediate
+   hosts specified in source routing to resolve any problems.  If source
+   routes are stripped, this practice will cause failures.  This is one
+   of several reasons why SMTP clients MUST NOT generate invalid source
+   routes or depend on serial resolution of names.
+
+   When source routes are not used, the process described in RFC 821 for
+   constructing a reverse-path from the forward-path is not applicable
+   and the reverse-path at the time of delivery will simply be the
+   address that appeared in the MAIL command.
+
+   A relay SMTP server is usually the target of a DNS MX record that
+   designates it, rather than the final delivery system.  The relay
+   server may accept or reject the task of relaying the mail in the same
+   way it accepts or rejects mail for a local user.  If it accepts the
+   task, it then becomes an SMTP client, establishes a transmission
+   channel to the next SMTP server specified in the DNS (according to
+   the rules in section 5), and sends it the mail.  If it declines to
+   relay mail to a particular address for policy reasons, a 550 response
+   SHOULD be returned.
+
+   Many mail-sending clients exist, especially in conjunction with
+   facilities that receive mail via POP3 or IMAP, that have limited
+   capability to support some of the requirements of this specification,
+   such as the ability to queue messages for subsequent delivery
+   attempts.  For these clients, it is common practice to make private
+   arrangements to send all messages to a single server for processing
+   and subsequent distribution.  SMTP, as specified here, is not ideally
+   suited for this role, and work is underway on standardized mail
+   submission protocols that might eventually supercede the current
+   practices.  In any event, because these arrangements are private and
+   fall outside the scope of this specification, they are not described
+   here.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 24]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   It is important to note that MX records can point to SMTP servers
+   which act as gateways into other environments, not just SMTP relays
+   and final delivery systems; see sections 3.8 and 5.
+
+   If an SMTP server has accepted the task of relaying the mail and
+   later finds that the destination is incorrect or that the mail cannot
+   be delivered for some other reason, then it MUST construct an
+   "undeliverable mail" notification message and send it to the
+   originator of the undeliverable mail (as indicated by the reverse-
+   path).  Formats specified for non-delivery reports by other standards
+   (see, for example, [24, 25]) SHOULD be used if possible.
+
+   This notification message must be from the SMTP server at the relay
+   host or the host that first determines that delivery cannot be
+   accomplished.  Of course, SMTP servers MUST NOT send notification
+   messages about problems transporting notification messages.  One way
+   to prevent loops in error reporting is to specify a null reverse-path
+   in the MAIL command of a notification message.  When such a message
+   is transmitted the reverse-path MUST be set to null (see section
+   4.5.5 for additional discussion).  A MAIL command with a null
+   reverse-path appears as follows:
+
+      MAIL FROM:<>
+
+   As discussed in section 2.4.1, a relay SMTP has no need to inspect or
+   act upon the headers or body of the message data and MUST NOT do so
+   except to add its own "Received:" header (section 4.4) and,
+   optionally, to attempt to detect looping in the mail system (see
+   section 6.2).
+
+3.8 Mail Gatewaying
+
+   While the relay function discussed above operates within the Internet
+   SMTP transport service environment, MX records or various forms of
+   explicit routing may require that an intermediate SMTP server perform
+   a translation function between one transport service and another.  As
+   discussed in section 2.3.8, when such a system is at the boundary
+   between two transport service environments, we refer to it as a
+   "gateway" or "gateway SMTP".
+
+   Gatewaying mail between different mail environments, such as
+   different mail formats and protocols, is complex and does not easily
+   yield to standardization.  However, some general requirements may be
+   given for a gateway between the Internet and another mail
+   environment.
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 25]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+3.8.1 Header Fields in Gatewaying
+
+   Header fields MAY be rewritten when necessary as messages are
+   gatewayed across mail environment boundaries.  This may involve
+   inspecting the message body or interpreting the local-part of the
+   destination address in spite of the prohibitions in section 2.4.1.
+
+   Other mail systems gatewayed to the Internet often use a subset of
+   RFC 822 headers or provide similar functionality with a different
+   syntax, but some of these mail systems do not have an equivalent to
+   the SMTP envelope.  Therefore, when a message leaves the Internet
+   environment, it may be necessary to fold the SMTP envelope
+   information into the message header.  A possible solution would be to
+   create new header fields to carry the envelope information (e.g.,
+   "X-SMTP-MAIL:"  and "X-SMTP-RCPT:"); however, this would require
+   changes in mail programs in foreign environments and might risk
+   disclosure of private information (see section 7.2).
+
+3.8.2 Received Lines in Gatewaying
+
+   When forwarding a message into or out of the Internet environment, a
+   gateway MUST prepend a Received: line, but it MUST NOT alter in any
+   way a Received: line that is already in the header.
+
+   "Received:" fields of messages originating from other environments
+   may not conform exactly to this specification.  However, the most
+   important use of Received: lines is for debugging mail faults, and
+   this debugging can be severely hampered by well-meaning gateways that
+   try to "fix" a Received: line.  As another consequence of trace
+   fields arising in non-SMTP environments, receiving systems MUST NOT
+   reject mail based on the format of a trace field and SHOULD be
+   extremely robust in the light of unexpected information or formats in
+   those fields.
+
+   The gateway SHOULD indicate the environment and protocol in the "via"
+   clauses of Received field(s) that it supplies.
+
+3.8.3 Addresses in Gatewaying
+
+   From the Internet side, the gateway SHOULD accept all valid address
+   formats in SMTP commands and in RFC 822 headers, and all valid RFC
+   822 messages.  Addresses and headers generated by gateways MUST
+   conform to applicable Internet standards (including this one and RFC
+   822).  Gateways are, of course, subject to the same rules for
+   handling source routes as those described for other SMTP systems in
+   section 3.3.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 26]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+3.8.4 Other Header Fields in Gatewaying
+
+   The gateway MUST ensure that all header fields of a message that it
+   forwards into the Internet mail environment meet the requirements for
+   Internet mail.  In particular, all addresses in "From:", "To:",
+   "Cc:", etc., fields MUST be transformed (if necessary) to satisfy RFC
+   822 syntax, MUST reference only fully-qualified domain names, and
+   MUST be effective and useful for sending replies.  The translation
+   algorithm used to convert mail from the Internet protocols to another
+   environment's protocol SHOULD ensure that error messages from the
+   foreign mail environment are delivered to the return path from the
+   SMTP envelope, not to the sender listed in the "From:" field (or
+   other fields) of the RFC 822 message.
+
+3.8.5 Envelopes in Gatewaying
+
+   Similarly, when forwarding a message from another environment into
+   the Internet, the gateway SHOULD set the envelope return path in
+   accordance with an error message return address, if supplied by the
+   foreign environment.  If the foreign environment has no equivalent
+   concept, the gateway must select and use a best approximation, with
+   the message originator's address as the default of last resort.
+
+3.9 Terminating Sessions and Connections
+
+   An SMTP connection is terminated when the client sends a QUIT
+   command.  The server responds with a positive reply code, after which
+   it closes the connection.
+
+   An SMTP server MUST NOT intentionally close the connection except:
+
+   -  After receiving a QUIT command and responding with a 221 reply.
+
+   -  After detecting the need to shut down the SMTP service and
+      returning a 421 response code.  This response code can be issued
+      after the server receives any command or, if necessary,
+      asynchronously from command receipt (on the assumption that the
+      client will receive it after the next command is issued).
+
+   In particular, a server that closes connections in response to
+   commands that are not understood is in violation of this
+   specification.  Servers are expected to be tolerant of unknown
+   commands, issuing a 500 reply and awaiting further instructions from
+   the client.
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 27]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   An SMTP server which is forcibly shut down via external means SHOULD
+   attempt to send a line containing a 421 response code to the SMTP
+   client before exiting.  The SMTP client will normally read the 421
+   response code after sending its next command.
+
+   SMTP clients that experience a connection close, reset, or other
+   communications failure due to circumstances not under their control
+   (in violation of the intent of this specification but sometimes
+   unavoidable) SHOULD, to maintain the robustness of the mail system,
+   treat the mail transaction as if a 451 response had been received and
+   act accordingly.
+
+3.10 Mailing Lists and Aliases
+
+   An SMTP-capable host SHOULD support both the alias and the list
+   models of address expansion for multiple delivery.  When a message is
+   delivered or forwarded to each address of an expanded list form, the
+   return address in the envelope ("MAIL FROM:") MUST be changed to be
+   the address of a person or other entity who administers the list.
+   However, in this case, the message header [32] MUST be left
+   unchanged; in particular, the "From" field of the message header is
+   unaffected.
+
+   An important mail facility is a mechanism for multi-destination
+   delivery of a single message, by transforming (or "expanding" or
+   "exploding") a pseudo-mailbox address into a list of destination
+   mailbox addresses.  When a message is sent to such a pseudo-mailbox
+   (sometimes called an "exploder"), copies are forwarded or
+   redistributed to each mailbox in the expanded list.  Servers SHOULD
+   simply utilize the addresses on the list; application of heuristics
+   or other matching rules to eliminate some addresses, such as that of
+   the originator, is strongly discouraged.  We classify such a pseudo-
+   mailbox as an "alias" or a "list", depending upon the expansion
+   rules.
+
+3.10.1 Alias
+
+   To expand an alias, the recipient mailer simply replaces the pseudo-
+   mailbox address in the envelope with each of the expanded addresses
+   in turn; the rest of the envelope and the message body are left
+   unchanged.  The message is then delivered or forwarded to each
+   expanded address.
+
+3.10.2 List
+
+   A mailing list may be said to operate by "redistribution" rather than
+   by "forwarding".  To expand a list, the recipient mailer replaces the
+   pseudo-mailbox address in the envelope with all of the expanded
+
+
+
+Klensin                     Standards Track                    [Page 28]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   addresses.  The return address in the envelope is changed so that all
+   error messages generated by the final deliveries will be returned to
+   a list administrator, not to the message originator, who generally
+   has no control over the contents of the list and will typically find
+   error messages annoying.
+
+4. The SMTP Specifications
+
+4.1 SMTP Commands
+
+4.1.1 Command Semantics and Syntax
+
+   The SMTP commands define the mail transfer or the mail system
+   function requested by the user.  SMTP commands are character strings
+   terminated by <CRLF>.  The commands themselves are alphabetic
+   characters terminated by <SP> if parameters follow and <CRLF>
+   otherwise.  (In the interest of improved interoperability, SMTP
+   receivers are encouraged to tolerate trailing white space before the
+   terminating <CRLF>.)  The syntax of the local part of a mailbox must
+   conform to receiver site conventions and the syntax specified in
+   section 4.1.2.  The SMTP commands are discussed below.  The SMTP
+   replies are discussed in section 4.2.
+
+   A mail transaction involves several data objects which are
+   communicated as arguments to different commands.  The reverse-path is
+   the argument of the MAIL command, the forward-path is the argument of
+   the RCPT command, and the mail data is the argument of the DATA
+   command.  These arguments or data objects must be transmitted and
+   held pending the confirmation communicated by the end of mail data
+   indication which finalizes the transaction.  The model for this is
+   that distinct buffers are provided to hold the types of data objects,
+   that is, there is a reverse-path buffer, a forward-path buffer, and a
+   mail data buffer.  Specific commands cause information to be appended
+   to a specific buffer, or cause one or more buffers to be cleared.
+
+   Several commands (RSET, DATA, QUIT) are specified as not permitting
+   parameters.  In the absence of specific extensions offered by the
+   server and accepted by the client, clients MUST NOT send such
+   parameters and servers SHOULD reject commands containing them as
+   having invalid syntax.
+
+4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)
+
+   These commands are used to identify the SMTP client to the SMTP
+   server.  The argument field contains the fully-qualified domain name
+   of the SMTP client if one is available.  In situations in which the
+   SMTP client system does not have a meaningful domain name (e.g., when
+   its address is dynamically allocated and no reverse mapping record is
+
+
+
+Klensin                     Standards Track                    [Page 29]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   available), the client SHOULD send an address literal (see section
+   4.1.3), optionally followed by information that will help to identify
+   the client system.  y The SMTP server identifies itself to the SMTP
+   client in the connection greeting reply and in the response to this
+   command.
+
+   A client SMTP SHOULD start an SMTP session by issuing the EHLO
+   command.  If the SMTP server supports the SMTP service extensions it
+   will give a successful response, a failure response, or an error
+   response.  If the SMTP server, in violation of this specification,
+   does not support any SMTP service extensions it will generate an
+   error response.  Older client SMTP systems MAY, as discussed above,
+   use HELO (as specified in RFC 821) instead of EHLO, and servers MUST
+   support the HELO command and reply properly to it.  In any event, a
+   client MUST issue HELO or EHLO before starting a mail transaction.
+
+   These commands, and a "250 OK" reply to one of them, confirm that
+   both the SMTP client and the SMTP server are in the initial state,
+   that is, there is no transaction in progress and all state tables and
+   buffers are cleared.
+
+   Syntax:
+
+      ehlo            = "EHLO" SP Domain CRLF
+      helo            = "HELO" SP Domain CRLF
+
+   Normally, the response to EHLO will be a multiline reply.  Each line
+   of the response contains a keyword and, optionally, one or more
+   parameters.  Following the normal syntax for multiline replies, these
+   keyworks follow the code (250) and a hyphen for all but the last
+   line, and the code and a space for the last line.  The syntax for a
+   positive response, using the ABNF notation and terminal symbols of
+   [8], is:
+
+      ehlo-ok-rsp  =    ( "250"    domain [ SP ehlo-greet ] CRLF )
+                   / (    "250-"   domain [ SP ehlo-greet ] CRLF
+                       *( "250-"   ehlo-line                CRLF )
+                          "250"    SP ehlo-line             CRLF  )
+
+      ehlo-greet   = 1*(%d0-9 / %d11-12 / %d14-127)
+                   ; string of any characters other than CR or LF
+
+      ehlo-line    = ehlo-keyword *( SP ehlo-param )
+
+      ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+                   ; additional syntax of ehlo-params depends on
+                   ; ehlo-keyword
+
+
+
+
+Klensin                     Standards Track                    [Page 30]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      ehlo-param   = 1*(%d33-127)
+                   ; any CHAR excluding <SP> and all
+                   ; control characters (US-ASCII 0-31 inclusive)
+
+   Although EHLO keywords may be specified in upper, lower, or mixed
+   case, they MUST always be recognized and processed in a case-
+   insensitive manner.  This is simply an extension of practices
+   specified in RFC 821 and section 2.4.1.
+
+4.1.1.2 MAIL (MAIL)
+
+   This command is used to initiate a mail transaction in which the mail
+   data is delivered to an SMTP server which may, in turn, deliver it to
+   one or more mailboxes or pass it on to another system (possibly using
+   SMTP).  The argument field contains a reverse-path and may contain
+   optional parameters.  In general, the MAIL command may be sent only
+   when no mail transaction is in progress, see section 4.1.4.
+
+   The reverse-path consists of the sender mailbox.  Historically, that
+   mailbox might optionally have been preceded by a list of hosts, but
+   that behavior is now deprecated (see appendix C).  In some types of
+   reporting messages for which a reply is likely to cause a mail loop
+   (for example, mail delivery and nondelivery notifications), the
+   reverse-path may be null (see section 3.7).
+
+   This command clears the reverse-path buffer, the forward-path buffer,
+   and the mail data buffer; and inserts the reverse-path information
+   from this command into the reverse-path buffer.
+
+   If service extensions were negotiated, the MAIL command may also
+   carry parameters associated with a particular service extension.
+
+   Syntax:
+
+      "MAIL FROM:" ("<>" / Reverse-Path)
+                       [SP Mail-parameters] CRLF
+
+4.1.1.3 RECIPIENT (RCPT)
+
+   This command is used to identify an individual recipient of the mail
+   data; multiple recipients are specified by multiple use of this
+   command.  The argument field contains a forward-path and may contain
+   optional parameters.
+
+   The forward-path normally consists of the required destination
+   mailbox.  Sending systems SHOULD not generate the optional list of
+   hosts known as a source route.  Receiving systems MUST recognize
+
+
+
+
+Klensin                     Standards Track                    [Page 31]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   source route syntax but SHOULD strip off the source route
+   specification and utilize the domain name associated with the mailbox
+   as if the source route had not been provided.
+
+   Similarly, relay hosts SHOULD strip or ignore source routes, and
+   names MUST NOT be copied into the reverse-path.  When mail reaches
+   its ultimate destination (the forward-path contains only a
+   destination mailbox), the SMTP server inserts it into the destination
+   mailbox in accordance with its host mail conventions.
+
+   For example, mail received at relay host xyz.com with envelope
+   commands
+
+      MAIL FROM:<userx@y.foo.org>
+      RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
+
+   will normally be sent directly on to host d.bar.org with envelope
+   commands
+
+      MAIL FROM:<userx@y.foo.org>
+      RCPT TO:<userc@d.bar.org>
+
+   As provided in appendix C, xyz.com MAY also choose to relay the
+   message to hosta.int, using the envelope commands
+
+      MAIL FROM:<userx@y.foo.org>
+      RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
+
+   or to jkl.org, using the envelope commands
+
+      MAIL FROM:<userx@y.foo.org>
+      RCPT TO:<@jkl.org:userc@d.bar.org>
+
+   Of course, since hosts are not required to relay mail at all, xyz.com
+   may also reject the message entirely when the RCPT command is
+   received, using a 550 code (since this is a "policy reason").
+
+   If service extensions were negotiated, the RCPT command may also
+   carry parameters associated with a particular service extension
+   offered by the server.  The client MUST NOT transmit parameters other
+   than those associated with a service extension offered by the server
+   in its EHLO response.
+
+Syntax:
+   "RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>" / Forward-Path)
+                    [SP Rcpt-parameters] CRLF
+
+
+
+
+
+Klensin                     Standards Track                    [Page 32]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+4.1.1.4 DATA (DATA)
+
+   The receiver normally sends a 354 response to DATA, and then treats
+   the lines (strings ending in <CRLF> sequences, as described in
+   section 2.3.7) following the command as mail data from the sender.
+   This command causes the mail data to be appended to the mail data
+   buffer.  The mail data may contain any of the 128 ASCII character
+   codes, although experience has indicated that use of control
+   characters other than SP, HT, CR, and LF may cause problems and
+   SHOULD be avoided when possible.
+
+   The mail data is terminated by a line containing only a period, that
+   is, the character sequence "<CRLF>.<CRLF>" (see section 4.5.2).  This
+   is the end of mail data indication.  Note that the first <CRLF> of
+   this terminating sequence is also the <CRLF> that ends the final line
+   of the data (message text) or, if there was no data, ends the DATA
+   command itself.  An extra <CRLF> MUST NOT be added, as that would
+   cause an empty line to be added to the message.  The only exception
+   to this rule would arise if the message body were passed to the
+   originating SMTP-sender with a final "line" that did not end in
+   <CRLF>; in that case, the originating SMTP system MUST either reject
+   the message as invalid or add <CRLF> in order to have the receiving
+   SMTP server recognize the "end of data" condition.
+
+   The custom of accepting lines ending only in <LF>, as a concession to
+   non-conforming behavior on the part of some UNIX systems, has proven
+   to cause more interoperability problems than it solves, and SMTP
+   server systems MUST NOT do this, even in the name of improved
+   robustness.  In particular, the sequence "<LF>.<LF>" (bare line
+   feeds, without carriage returns) MUST NOT be treated as equivalent to
+   <CRLF>.<CRLF> as the end of mail data indication.
+
+   Receipt of the end of mail data indication requires the server to
+   process the stored mail transaction information.  This processing
+   consumes the information in the reverse-path buffer, the forward-path
+   buffer, and the mail data buffer, and on the completion of this
+   command these buffers are cleared.  If the processing is successful,
+   the receiver MUST send an OK reply.  If the processing fails the
+   receiver MUST send a failure reply.  The SMTP model does not allow
+   for partial failures at this point: either the message is accepted by
+   the server for delivery and a positive response is returned or it is
+   not accepted and a failure reply is returned.  In sending a positive
+   completion reply to the end of data indication, the receiver takes
+   full responsibility for the message (see section 6.1).  Errors that
+   are diagnosed subsequently MUST be reported in a mail message, as
+   discussed in section 4.4.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 33]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   When the SMTP server accepts a message either for relaying or for
+   final delivery, it inserts a trace record (also referred to
+   interchangeably as a "time stamp line" or "Received" line) at the top
+   of the mail data.  This trace record indicates the identity of the
+   host that sent the message, the identity of the host that received
+   the message (and is inserting this time stamp), and the date and time
+   the message was received.  Relayed messages will have multiple time
+   stamp lines.  Details for formation of these lines, including their
+   syntax, is specified in section 4.4.
+
+   Additional discussion about the operation of the DATA command appears
+   in section 3.3.
+
+   Syntax:
+      "DATA" CRLF
+
+4.1.1.5 RESET (RSET)
+
+   This command specifies that the current mail transaction will be
+   aborted.  Any stored sender, recipients, and mail data MUST be
+   discarded, and all buffers and state tables cleared.  The receiver
+   MUST send a "250 OK" reply to a RSET command with no arguments.  A
+   reset command may be issued by the client at any time.  It is
+   effectively equivalent to a NOOP (i.e., if has no effect) if issued
+   immediately after EHLO, before EHLO is issued in the session, after
+   an end-of-data indicator has been sent and acknowledged, or
+   immediately before a QUIT.  An SMTP server MUST NOT close the
+   connection as the result of receiving a RSET; that action is reserved
+   for QUIT (see section 4.1.1.10).
+
+   Since EHLO implies some additional processing and response by the
+   server, RSET will normally be more efficient than reissuing that
+   command, even though the formal semantics are the same.
+
+   There are circumstances, contrary to the intent of this
+   specification, in which an SMTP server may receive an indication that
+   the underlying TCP connection has been closed or reset.  To preserve
+   the robustness of the mail system, SMTP servers SHOULD be prepared
+   for this condition and SHOULD treat it as if a QUIT had been received
+   before the connection disappeared.
+
+   Syntax:
+      "RSET" CRLF
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 34]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+4.1.1.6 VERIFY (VRFY)
+
+   This command asks the receiver to confirm that the argument
+   identifies a user or mailbox.  If it is a user name, information is
+   returned as specified in section 3.5.
+
+   This command has no effect on the reverse-path buffer, the forward-
+   path buffer, or the mail data buffer.
+
+   Syntax:
+      "VRFY" SP String CRLF
+
+4.1.1.7 EXPAND (EXPN)
+
+   This command asks the receiver to confirm that the argument
+   identifies a mailing list, and if so, to return the membership of
+   that list.  If the command is successful, a reply is returned
+   containing information as described in section 3.5.  This reply will
+   have multiple lines except in the trivial case of a one-member list.
+
+   This command has no effect on the reverse-path buffer, the forward-
+   path buffer, or the mail data buffer and may be issued at any time.
+
+   Syntax:
+      "EXPN" SP String CRLF
+
+4.1.1.8 HELP (HELP)
+
+   This command causes the server to send helpful information to the
+   client.  The command MAY take an argument (e.g., any command name)
+   and return more specific information as a response.
+
+   This command has no effect on the reverse-path buffer, the forward-
+   path buffer, or the mail data buffer and may be issued at any time.
+
+   SMTP servers SHOULD support HELP without arguments and MAY support it
+   with arguments.
+
+   Syntax:
+      "HELP" [ SP String ] CRLF
+
+4.1.1.9 NOOP (NOOP)
+
+   This command does not affect any parameters or previously entered
+   commands.  It specifies no action other than that the receiver send
+   an OK reply.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 35]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   This command has no effect on the reverse-path buffer, the forward-
+   path buffer, or the mail data buffer and may be issued at any time.
+   If a parameter string is specified, servers SHOULD ignore it.
+
+   Syntax:
+      "NOOP" [ SP String ] CRLF
+
+4.1.1.10 QUIT (QUIT)
+
+   This command specifies that the receiver MUST send an OK reply, and
+   then close the transmission channel.
+
+   The receiver MUST NOT intentionally close the transmission channel
+   until it receives and replies to a QUIT command (even if there was an
+   error).  The sender MUST NOT intentionally close the transmission
+   channel until it sends a QUIT command and SHOULD wait until it
+   receives the reply (even if there was an error response to a previous
+   command).  If the connection is closed prematurely due to violations
+   of the above or system or network failure, the server MUST cancel any
+   pending transaction, but not undo any previously completed
+   transaction, and generally MUST act as if the command or transaction
+   in progress had received a temporary error (i.e., a 4yz response).
+
+   The QUIT command may be issued at any time.
+
+   Syntax:
+      "QUIT" CRLF
+
+4.1.2 Command Argument Syntax
+
+   The syntax of the argument fields of the above commands (using the
+   syntax specified in [8] where applicable) is given below.  Some of
+   the productions given below are used only in conjunction with source
+   routes as described in appendix C.  Terminals not defined in this
+   document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in
+   the "core" syntax [8 (section 6)] or in the message format syntax
+   [32].
+
+      Reverse-path = Path
+      Forward-path = Path
+      Path = "<" [ A-d-l ":" ] Mailbox ">"
+      A-d-l = At-domain *( "," A-d-l )
+            ; Note that this form, the so-called "source route",
+            ; MUST BE accepted, SHOULD NOT be generated, and SHOULD be
+            ; ignored.
+      At-domain = "@" domain
+      Mail-parameters = esmtp-param *(SP esmtp-param)
+      Rcpt-parameters = esmtp-param *(SP esmtp-param)
+
+
+
+Klensin                     Standards Track                    [Page 36]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      esmtp-param     = esmtp-keyword ["=" esmtp-value]
+      esmtp-keyword   = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+      esmtp-value     = 1*(%d33-60 / %d62-127)
+            ; any CHAR excluding "=", SP, and control characters
+      Keyword  = Ldh-str
+      Argument = Atom
+      Domain = (sub-domain 1*("." sub-domain)) / address-literal
+      sub-domain = Let-dig [Ldh-str]
+
+      address-literal = "[" IPv4-address-literal /
+                            IPv6-address-literal /
+                            General-address-literal "]"
+            ; See section 4.1.3
+
+      Mailbox = Local-part "@" Domain
+
+      Local-part = Dot-string / Quoted-string
+            ; MAY be case-sensitive
+
+      Dot-string = Atom *("." Atom)
+
+      Atom = 1*atext
+
+      Quoted-string = DQUOTE *qcontent DQUOTE
+
+      String = Atom / Quoted-string
+
+   While the above definition for Local-part is relatively permissive,
+   for maximum interoperability, a host that expects to receive mail
+   SHOULD avoid defining mailboxes where the Local-part requires (or
+   uses) the Quoted-string form or where the Local-part is case-
+   sensitive.  For any purposes that require generating or comparing
+   Local-parts (e.g., to specific mailbox names), all quoted forms MUST
+   be treated as equivalent and the sending system SHOULD transmit the
+   form that uses the minimum quoting possible.
+
+   Systems MUST NOT define mailboxes in such a way as to require the use
+   in SMTP of non-ASCII characters (octets with the high order bit set
+   to one) or ASCII "control characters" (decimal value 0-31 and 127).
+   These characters MUST NOT be used in MAIL or RCPT commands or other
+   commands that require mailbox names.
+
+   Note that the backslash, "\", is a quote character, which is used to
+   indicate that the next character is to be used literally (instead of
+   its normal interpretation).  For example, "Joe\,Smith" indicates a
+   single nine character user field with the comma being the fourth
+   character of the field.
+
+
+
+
+Klensin                     Standards Track                    [Page 37]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   To promote interoperability and consistent with long-standing
+   guidance about conservative use of the DNS in naming and applications
+   (e.g., see section 2.3.1 of the base DNS document, RFC1035 [22]),
+   characters outside the set of alphas, digits, and hyphen MUST NOT
+   appear in domain name labels for SMTP clients or servers.  In
+   particular, the underscore character is not permitted.  SMTP servers
+   that receive a command in which invalid character codes have been
+   employed, and for which there are no other reasons for rejection,
+   MUST reject that command with a 501 response.
+
+4.1.3 Address Literals
+
+   Sometimes a host is not known to the domain name system and
+   communication (and, in particular, communication to report and repair
+   the error) is blocked.  To bypass this barrier a special literal form
+   of the address is allowed as an alternative to a domain name.  For
+   IPv4 addresses, this form uses four small decimal integers separated
+   by dots and enclosed by brackets such as [123.255.37.2], which
+   indicates an (IPv4) Internet Address in sequence-of-octets form.  For
+   IPv6 and other forms of addressing that might eventually be
+   standardized, the form consists of a standardized "tag" that
+   identifies the address syntax, a colon, and the address itself, in a
+   format specified as part of the IPv6 standards [17].
+
+   Specifically:
+
+      IPv4-address-literal = Snum 3("." Snum)
+      IPv6-address-literal = "IPv6:" IPv6-addr
+      General-address-literal = Standardized-tag ":" 1*dcontent
+      Standardized-tag = Ldh-str
+            ; MUST be specified in a standards-track RFC
+            ; and registered with IANA
+
+      Snum = 1*3DIGIT  ; representing a decimal integer
+            ; value in the range 0 through 255
+      Let-dig = ALPHA / DIGIT
+      Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
+
+      IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
+      IPv6-hex  = 1*4HEXDIG
+      IPv6-full = IPv6-hex 7(":" IPv6-hex)
+      IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":"
+                 IPv6-hex)]
+            ; The "::" represents at least 2 16-bit groups of zeros
+            ; No more than 6 groups in addition to the "::" may be
+            ; present
+      IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
+      IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"
+
+
+
+Klensin                     Standards Track                    [Page 38]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+                   [IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal
+            ; The "::" represents at least 2 16-bit groups of zeros
+            ; No more than 4 groups in addition to the "::" and
+            ; IPv4-address-literal may be present
+
+4.1.4 Order of Commands
+
+   There are restrictions on the order in which these commands may be
+   used.
+
+   A session that will contain mail transactions MUST first be
+   initialized by the use of the EHLO command.  An SMTP server SHOULD
+   accept commands for non-mail transactions (e.g., VRFY or EXPN)
+   without this initialization.
+
+   An EHLO command MAY be issued by a client later in the session.  If
+   it is issued after the session begins, the SMTP server MUST clear all
+   buffers and reset the state exactly as if a RSET command had been
+   issued.  In other words, the sequence of RSET followed immediately by
+   EHLO is redundant, but not harmful other than in the performance cost
+   of executing unnecessary commands.
+
+   If the EHLO command is not acceptable to the SMTP server, 501, 500,
+   or 502 failure replies MUST be returned as appropriate.  The SMTP
+   server MUST stay in the same state after transmitting these replies
+   that it was in before the EHLO was received.
+
+   The SMTP client MUST, if possible, ensure that the domain parameter
+   to the EHLO command is a valid principal host name (not a CNAME or MX
+   name) for its host.  If this is not possible (e.g., when the client's
+   address is dynamically assigned and the client does not have an
+   obvious name), an address literal SHOULD be substituted for the
+   domain name and supplemental information provided that will assist in
+   identifying the client.
+
+   An SMTP server MAY verify that the domain name parameter in the EHLO
+   command actually corresponds to the IP address of the client.
+   However, the server MUST NOT refuse to accept a message for this
+   reason if the verification fails: the information about verification
+   failure is for logging and tracing only.
+
+   The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time
+   during a session, or without previously initializing a session.  SMTP
+   servers SHOULD process these normally (that is, not return a 503
+   code) even if no EHLO command has yet been received; clients SHOULD
+   open a session with EHLO before sending these commands.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 39]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   If these rules are followed, the example in RFC 821 that shows "550
+   access denied to you" in response to an EXPN command is incorrect
+   unless an EHLO command precedes the EXPN or the denial of access is
+   based on the client's IP address or other authentication or
+   authorization-determining mechanisms.
+
+   The MAIL command (or the obsolete SEND, SOML, or SAML commands)
+   begins a mail transaction.  Once started, a mail transaction consists
+   of a transaction beginning command, one or more RCPT commands, and a
+   DATA command, in that order.  A mail transaction may be aborted by
+   the RSET (or a new EHLO) command.  There may be zero or more
+   transactions in a session.  MAIL (or SEND, SOML, or SAML) MUST NOT be
+   sent if a mail transaction is already open, i.e., it should be sent
+   only if no mail transaction had been started in the session, or it
+   the previous one successfully concluded with a successful DATA
+   command, or if the previous one was aborted with a RSET.
+
+   If the transaction beginning command argument is not acceptable, a
+   501 failure reply MUST be returned and the SMTP server MUST stay in
+   the same state.  If the commands in a transaction are out of order to
+   the degree that they cannot be processed by the server, a 503 failure
+   reply MUST be returned and the SMTP server MUST stay in the same
+   state.
+
+   The last command in a session MUST be the QUIT command.  The QUIT
+   command cannot be used at any other time in a session, but SHOULD be
+   used by the client SMTP to request connection closure, even when no
+   session opening command was sent and accepted.
+
+4.1.5 Private-use Commands
+
+   As specified in section 2.2.2, commands starting in "X" may be used
+   by bilateral agreement between the client (sending) and server
+   (receiving) SMTP agents.  An SMTP server that does not recognize such
+   a command is expected to reply with "500 Command not recognized".  An
+   extended SMTP server MAY list the feature names associated with these
+   private commands in the response to the EHLO command.
+
+   Commands sent or accepted by SMTP systems that do not start with "X"
+   MUST conform to the requirements of section 2.2.2.
+
+4.2 SMTP Replies
+
+   Replies to SMTP commands serve to ensure the synchronization of
+   requests and actions in the process of mail transfer and to guarantee
+   that the SMTP client always knows the state of the SMTP server.
+   Every command MUST generate exactly one reply.
+
+
+
+
+Klensin                     Standards Track                    [Page 40]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   The details of the command-reply sequence are described in section
+   4.3.
+
+   An SMTP reply consists of a three digit number (transmitted as three
+   numeric characters) followed by some text unless specified otherwise
+   in this document.  The number is for use by automata to determine
+   what state to enter next; the text is for the human user.  The three
+   digits contain enough encoded information that the SMTP client need
+   not examine the text and may either discard it or pass it on to the
+   user, as appropriate.  Exceptions are as noted elsewhere in this
+   document.  In particular, the 220, 221, 251, 421, and 551 reply codes
+   are associated with message text that must be parsed and interpreted
+   by machines.  In the general case, the text may be receiver dependent
+   and context dependent, so there are likely to be varying texts for
+   each reply code.  A discussion of the theory of reply codes is given
+   in section 4.2.1.  Formally, a reply is defined to be the sequence: a
+   three-digit code, <SP>, one line of text, and <CRLF>, or a multiline
+   reply (as defined in section 4.2.1).  Since, in violation of this
+   specification, the text is sometimes not sent, clients which do not
+   receive it SHOULD be prepared to process the code alone (with or
+   without a trailing space character).  Only the EHLO, EXPN, and HELP
+   commands are expected to result in multiline replies in normal
+   circumstances, however, multiline replies are allowed for any
+   command.
+
+   In ABNF, server responses are:
+
+      Greeting = "220 " Domain [ SP text ] CRLF
+      Reply-line = Reply-code [ SP text ] CRLF
+
+   where "Greeting" appears only in the 220 response that announces that
+   the server is opening its part of the connection.
+
+   An SMTP server SHOULD send only the reply codes listed in this
+   document.  An SMTP server SHOULD use the text shown in the examples
+   whenever appropriate.
+
+   An SMTP client MUST determine its actions only by the reply code, not
+   by the text (except for the "change of address" 251 and 551 and, if
+   necessary, 220, 221, and 421 replies); in the general case, any text,
+   including no text at all (although senders SHOULD NOT send bare
+   codes), MUST be acceptable.  The space (blank) following the reply
+   code is considered part of the text.  Whenever possible, a receiver-
+   SMTP SHOULD test the first digit (severity indication) of the reply
+   code.
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 41]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   The list of codes that appears below MUST NOT be construed as
+   permanent.  While the addition of new codes should be a rare and
+   significant activity, with supplemental information in the textual
+   part of the response being preferred, new codes may be added as the
+   result of new Standards or Standards-track specifications.
+   Consequently, a sender-SMTP MUST be prepared to handle codes not
+   specified in this document and MUST do so by interpreting the first
+   digit only.
+
+4.2.1 Reply Code Severities and Theory
+
+   The three digits of the reply each have a special significance.  The
+   first digit denotes whether the response is good, bad or incomplete.
+   An unsophisticated SMTP client, or one that receives an unexpected
+   code, will be able to determine its next action (proceed as planned,
+   redo, retrench, etc.) by examining this first digit.  An SMTP client
+   that wants to know approximately what kind of error occurred (e.g.,
+   mail system error, command syntax error) may examine the second
+   digit.  The third digit and any supplemental information that may be
+   present is reserved for the finest gradation of information.
+
+   There are five values for the first digit of the reply code:
+
+   1yz   Positive Preliminary reply
+      The command has been accepted, but the requested action is being
+      held in abeyance, pending confirmation of the information in this
+      reply.  The SMTP client should send another command specifying
+      whether to continue or abort the action.  Note: unextended SMTP
+      does not have any commands that allow this type of reply, and so
+      does not have continue or abort commands.
+
+   2yz   Positive Completion reply
+      The requested action has been successfully completed.  A new
+      request may be initiated.
+
+   3yz   Positive Intermediate reply
+      The command has been accepted, but the requested action is being
+      held in abeyance, pending receipt of further information.  The
+      SMTP client should send another command specifying this
+      information.  This reply is used in command sequence groups (i.e.,
+      in DATA).
+
+   4yz   Transient Negative Completion reply
+      The command was not accepted, and the requested action did not
+      occur.  However, the error condition is temporary and the action
+      may be requested again.  The sender should return to the beginning
+      of the command sequence (if any).  It is difficult to assign a
+      meaning to "transient" when two different sites (receiver- and
+
+
+
+Klensin                     Standards Track                    [Page 42]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      sender-SMTP agents) must agree on the interpretation.  Each reply
+      in this category might have a different time value, but the SMTP
+      client is encouraged to try again.  A rule of thumb to determine
+      whether a reply fits into the 4yz or the 5yz category (see below)
+      is that replies are 4yz if they can be successful if repeated
+      without any change in command form or in properties of the sender
+      or receiver (that is, the command is repeated identically and the
+      receiver does not put up a new implementation.)
+
+   5yz   Permanent Negative Completion reply
+      The command was not accepted and the requested action did not
+      occur.  The SMTP client is discouraged from repeating the exact
+      request (in the same sequence).  Even some "permanent" error
+      conditions can be corrected, so the human user may want to direct
+      the SMTP client to reinitiate the command sequence by direct
+      action at some point in the future (e.g., after the spelling has
+      been changed, or the user has altered the account status).
+
+   The second digit encodes responses in specific categories:
+
+   x0z   Syntax: These replies refer to syntax errors, syntactically
+      correct commands that do not fit any functional category, and
+      unimplemented or superfluous commands.
+
+   x1z   Information:  These are replies to requests for information,
+      such as status or help.
+
+   x2z   Connections: These are replies referring to the transmission
+      channel.
+
+   x3z   Unspecified.
+
+   x4z   Unspecified.
+
+   x5z   Mail system: These replies indicate the status of the receiver
+      mail system vis-a-vis the requested transfer or other mail system
+      action.
+
+   The third digit gives a finer gradation of meaning in each category
+   specified by the second digit.  The list of replies illustrates this.
+   Each reply text is recommended rather than mandatory, and may even
+   change according to the command with which it is associated.  On the
+   other hand, the reply codes must strictly follow the specifications
+   in this section.  Receiver implementations should not invent new
+   codes for slightly different situations from the ones described here,
+   but rather adapt codes already defined.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 43]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   For example, a command such as NOOP, whose successful execution does
+   not offer the SMTP client any new information, will return a 250
+   reply.  The reply is 502 when the command requests an unimplemented
+   non-site-specific action.  A refinement of that is the 504 reply for
+   a command that is implemented, but that requests an unimplemented
+   parameter.
+
+   The reply text may be longer than a single line; in these cases the
+   complete text must be marked so the SMTP client knows when it can
+   stop reading the reply.  This requires a special format to indicate a
+   multiple line reply.
+
+   The format for multiline replies requires that every line, except the
+   last, begin with the reply code, followed immediately by a hyphen,
+   "-" (also known as minus), followed by text.  The last line will
+   begin with the reply code, followed immediately by <SP>, optionally
+   some text, and <CRLF>.  As noted above, servers SHOULD send the <SP>
+   if subsequent text is not sent, but clients MUST be prepared for it
+   to be omitted.
+
+   For example:
+
+      123-First line
+      123-Second line
+      123-234 text beginning with numbers
+      123 The last line
+
+   In many cases the SMTP client then simply needs to search for a line
+   beginning with the reply code followed by <SP> or <CRLF> and ignore
+   all preceding lines.  In a few cases, there is important data for the
+   client in the reply "text".  The client will be able to identify
+   these cases from the current context.
+
+4.2.2 Reply Codes by Function Groups
+
+      500 Syntax error, command unrecognized
+         (This may include errors such as command line too long)
+      501 Syntax error in parameters or arguments
+      502 Command not implemented  (see section 4.2.4)
+      503 Bad sequence of commands
+      504 Command parameter not implemented
+
+      211 System status, or system help reply
+      214 Help message
+         (Information on how to use the receiver or the meaning of a
+         particular non-standard command; this reply is useful only
+         to the human user)
+
+
+
+
+Klensin                     Standards Track                    [Page 44]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      220 <domain> Service ready
+      221 <domain> Service closing transmission channel
+      421 <domain> Service not available, closing transmission channel
+         (This may be a reply to any command if the service knows it
+         must shut down)
+
+      250 Requested mail action okay, completed
+      251 User not local; will forward to <forward-path>
+         (See section 3.4)
+      252 Cannot VRFY user, but will accept message and attempt
+          delivery
+         (See section 3.5.3)
+      450 Requested mail action not taken: mailbox unavailable
+         (e.g., mailbox busy)
+      550 Requested action not taken: mailbox unavailable
+         (e.g., mailbox not found, no access, or command rejected
+         for policy reasons)
+      451 Requested action aborted: error in processing
+      551 User not local; please try <forward-path>
+         (See section 3.4)
+      452 Requested action not taken: insufficient system storage
+      552 Requested mail action aborted: exceeded storage allocation
+      553 Requested action not taken: mailbox name not allowed
+         (e.g., mailbox syntax incorrect)
+      354 Start mail input; end with <CRLF>.<CRLF>
+      554 Transaction failed (Or, in the case of a connection-opening
+          response, "No SMTP service here")
+
+4.2.3  Reply Codes in Numeric Order
+
+      211 System status, or system help reply
+      214 Help message
+         (Information on how to use the receiver or the meaning of a
+         particular non-standard command; this reply is useful only
+         to the human user)
+      220 <domain> Service ready
+      221 <domain> Service closing transmission channel
+      250 Requested mail action okay, completed
+      251 User not local; will forward to <forward-path>
+         (See section 3.4)
+      252 Cannot VRFY user, but will accept message and attempt
+         delivery
+         (See section 3.5.3)
+
+      354 Start mail input; end with <CRLF>.<CRLF>
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 45]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      421 <domain> Service not available, closing transmission channel
+         (This may be a reply to any command if the service knows it
+         must shut down)
+      450 Requested mail action not taken: mailbox unavailable
+         (e.g., mailbox busy)
+      451 Requested action aborted: local error in processing
+      452 Requested action not taken: insufficient system storage
+      500 Syntax error, command unrecognized
+         (This may include errors such as command line too long)
+      501 Syntax error in parameters or arguments
+      502 Command not implemented (see section 4.2.4)
+      503 Bad sequence of commands
+      504 Command parameter not implemented
+      550 Requested action not taken: mailbox unavailable
+         (e.g., mailbox not found, no access, or command rejected
+         for policy reasons)
+      551 User not local; please try <forward-path>
+         (See section 3.4)
+      552 Requested mail action aborted: exceeded storage allocation
+      553 Requested action not taken: mailbox name not allowed
+         (e.g., mailbox syntax incorrect)
+      554 Transaction failed  (Or, in the case of a connection-opening
+          response, "No SMTP service here")
+
+4.2.4 Reply Code 502
+
+   Questions have been raised as to when reply code 502 (Command not
+   implemented) SHOULD be returned in preference to other codes.  502
+   SHOULD be used when the command is actually recognized by the SMTP
+   server, but not implemented.  If the command is not recognized, code
+   500 SHOULD be returned.  Extended SMTP systems MUST NOT list
+   capabilities in response to EHLO for which they will return 502 (or
+   500) replies.
+
+4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
+
+   When an SMTP server returns a positive completion status (2yz code)
+   after the DATA command is completed with <CRLF>.<CRLF>, it accepts
+   responsibility for:
+
+   -  delivering the message (if the recipient mailbox exists), or
+
+   -  if attempts to deliver the message fail due to transient
+      conditions, retrying delivery some reasonable number of times at
+      intervals as specified in section 4.5.4.
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 46]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   -  if attempts to deliver the message fail due to permanent
+      conditions, or if repeated attempts to deliver the message fail
+      due to transient conditions, returning appropriate notification to
+      the sender of the original message (using the address in the SMTP
+      MAIL command).
+
+   When an SMTP server returns a permanent error status (5yz) code after
+   the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
+   any subsequent attempt to deliver that message.  The SMTP client
+   retains responsibility for delivery of that message and may either
+   return it to the user or requeue it for a subsequent attempt (see
+   section 4.5.4.1).
+
+   The user who originated the message SHOULD be able to interpret the
+   return of a transient failure status (by mail message or otherwise)
+   as a non-delivery indication, just as a permanent failure would be
+   interpreted.  I.e., if the client SMTP successfully handles these
+   conditions, the user will not receive such a reply.
+
+   When an SMTP server returns a permanent error status (5yz) code after
+   the DATA command is completely with <CRLF>.<CRLF>, it MUST NOT make
+   any subsequent attempt to deliver the message.  As with temporary
+   error status codes, the SMTP client retains responsibility for the
+   message, but SHOULD not again attempt delivery to the same server
+   without user review and intervention of the message.
+
+4.3 Sequencing of Commands and Replies
+
+4.3.1 Sequencing Overview
+
+   The communication between the sender and receiver is an alternating
+   dialogue, controlled by the sender.  As such, the sender issues a
+   command and the receiver responds with a reply.  Unless other
+   arrangements are negotiated through service extensions, the sender
+   MUST wait for this response before sending further commands.
+
+   One important reply is the connection greeting.  Normally, a receiver
+   will send a 220 "Service ready" reply when the connection is
+   completed.  The sender SHOULD wait for this greeting message before
+   sending any commands.
+
+   Note: all the greeting-type replies have the official name (the
+   fully-qualified primary domain name) of the server host as the first
+   word following the reply code.  Sometimes the host will have no
+   meaningful name.  See 4.1.3 for a discussion of alternatives in these
+   situations.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 47]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   For example,
+
+      220 ISIF.USC.EDU Service ready
+   or
+      220 mail.foo.com SuperSMTP v 6.1.2 Service ready
+   or
+      220 [10.0.0.1] Clueless host service ready
+
+   The table below lists alternative success and failure replies for
+   each command.  These SHOULD be strictly adhered to: a receiver may
+   substitute text in the replies, but the meaning and action implied by
+   the code numbers and by the specific command reply sequence cannot be
+   altered.
+
+4.3.2 Command-Reply Sequences
+
+   Each command is listed with its usual possible replies.  The prefixes
+   used before the possible replies are "I" for intermediate, "S" for
+   success, and "E" for error.  Since some servers may generate other
+   replies under special circumstances, and to allow for future
+   extension, SMTP clients SHOULD, when possible, interpret only the
+   first digit of the reply and MUST be prepared to deal with
+   unrecognized reply codes by interpreting the first digit only.
+   Unless extended using the mechanisms described in section 2.2, SMTP
+   servers MUST NOT transmit reply codes to an SMTP client that are
+   other than three digits or that do not start in a digit between 2 and
+   5 inclusive.
+
+   These sequencing rules and, in principle, the codes themselves, can
+   be extended or modified by SMTP extensions offered by the server and
+   accepted (requested) by the client.
+
+   In addition to the codes listed below, any SMTP command can return
+   any of the following codes if the corresponding unusual circumstances
+   are encountered:
+
+   500  For the "command line too long" case or if the command name was
+      not recognized.  Note that producing a "command not recognized"
+      error in response to the required subset of these commands is a
+      violation of this specification.
+
+   501  Syntax error in command or arguments.  In order to provide for
+      future extensions, commands that are specified in this document as
+      not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501
+      message if arguments are supplied in the absence of EHLO-
+      advertised extensions.
+
+   421  Service shutting down and closing transmission channel
+
+
+
+Klensin                     Standards Track                    [Page 48]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   Specific sequences are:
+
+   CONNECTION ESTABLISHMENT
+      S: 220
+      E: 554
+   EHLO or HELO
+      S: 250
+      E: 504, 550
+   MAIL
+      S: 250
+      E: 552, 451, 452, 550, 553, 503
+   RCPT
+      S: 250, 251 (but see section 3.4 for discussion of 251 and 551)
+      E: 550, 551, 552, 553, 450, 451, 452, 503, 550
+   DATA
+      I: 354 -> data -> S: 250
+                        E: 552, 554, 451, 452
+      E: 451, 554, 503
+   RSET
+      S: 250
+   VRFY
+      S: 250, 251, 252
+      E: 550, 551, 553, 502, 504
+   EXPN
+      S: 250, 252
+      E: 550, 500, 502, 504
+   HELP
+      S: 211, 214
+      E: 502, 504
+   NOOP
+      S: 250
+   QUIT
+      S: 221
+
+4.4 Trace Information
+
+   When an SMTP server receives a message for delivery or further
+   processing, it MUST insert trace ("time stamp" or "Received")
+   information at the beginning of the message content, as discussed in
+   section 4.1.1.4.
+
+   This line MUST be structured as follows:
+
+   -  The FROM field, which MUST be supplied in an SMTP environment,
+      SHOULD contain both (1) the name of the source host as presented
+      in the EHLO command and (2) an address literal containing the IP
+      address of the source, determined from the TCP connection.
+
+
+
+
+Klensin                     Standards Track                    [Page 49]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   -  The ID field MAY contain an "@" as suggested in RFC 822, but this
+      is not required.
+
+   -  The FOR field MAY contain a list of <path> entries when multiple
+      RCPT commands have been given.  This may raise some security
+      issues and is usually not desirable; see section 7.2.
+
+   An Internet mail program MUST NOT change a Received: line that was
+   previously added to the message header.  SMTP servers MUST prepend
+   Received lines to messages; they MUST NOT change the order of
+   existing lines or insert Received lines in any other location.
+
+   As the Internet grows, comparability of Received fields is important
+   for detecting problems, especially slow relays.  SMTP servers that
+   create Received fields SHOULD use explicit offsets in the dates
+   (e.g., -0800), rather than time zone names of any type.  Local time
+   (with an offset) is preferred to UT when feasible.  This formulation
+   allows slightly more information about local circumstances to be
+   specified.  If UT is needed, the receiver need merely do some simple
+   arithmetic to convert the values.  Use of UT loses information about
+   the time zone-location of the server.  If it is desired to supply a
+   time zone name, it SHOULD be included in a comment.
+
+   When the delivery SMTP server makes the "final delivery" of a
+   message, it inserts a return-path line at the beginning of the mail
+   data.  This use of return-path is required; mail systems MUST support
+   it.  The return-path line preserves the information in the <reverse-
+   path> from the MAIL command.  Here, final delivery means the message
+   has left the SMTP environment.  Normally, this would mean it had been
+   delivered to the destination user or an associated mail drop, but in
+   some cases it may be further processed and transmitted by another
+   mail system.
+
+   It is possible for the mailbox in the return path to be different
+   from the actual sender's mailbox, for example, if error responses are
+   to be delivered to a special error handling mailbox rather than to
+   the message sender.  When mailing lists are involved, this
+   arrangement is common and useful as a means of directing errors to
+   the list maintainer rather than the message originator.
+
+   The text above implies that the final mail data will begin with a
+   return path line, followed by one or more time stamp lines.  These
+   lines will be followed by the mail data headers and body [32].
+
+   It is sometimes difficult for an SMTP server to determine whether or
+   not it is making final delivery since forwarding or other operations
+   may occur after the message is accepted for delivery.  Consequently,
+
+
+
+
+Klensin                     Standards Track                    [Page 50]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   any further (forwarding, gateway, or relay) systems MAY remove the
+   return path and rebuild the MAIL command as needed to ensure that
+   exactly one such line appears in a delivered message.
+
+   A message-originating SMTP system SHOULD NOT send a message that
+   already contains a Return-path header.  SMTP servers performing a
+   relay function MUST NOT inspect the message data, and especially not
+   to the extent needed to determine if Return-path headers are present.
+   SMTP servers making final delivery MAY remove Return-path headers
+   before adding their own.
+
+   The primary purpose of the Return-path is to designate the address to
+   which messages indicating non-delivery or other mail system failures
+   are to be sent.  For this to be unambiguous, exactly one return path
+   SHOULD be present when the message is delivered.  Systems using RFC
+   822 syntax with non-SMTP transports SHOULD designate an unambiguous
+   address, associated with the transport envelope, to which error
+   reports (e.g., non-delivery messages) should be sent.
+
+   Historical note: Text in RFC 822 that appears to contradict the use
+   of the Return-path header (or the envelope reverse path address from
+   the MAIL command) as the destination for error messages is not
+   applicable on the Internet.  The reverse path address (as copied into
+   the Return-path) MUST be used as the target of any mail containing
+   delivery error messages.
+
+   In particular:
+
+   -  a gateway from SMTP->elsewhere SHOULD insert a return-path header,
+      unless it is known that the "elsewhere" transport also uses
+      Internet domain addresses and maintains the envelope sender
+      address separately.
+
+   -  a gateway from elsewhere->SMTP SHOULD delete any return-path
+      header present in the message, and either copy that information to
+      the SMTP envelope or combine it with information present in the
+      envelope of the other transport system to construct the reverse
+      path argument to the MAIL command in the SMTP envelope.
+
+   The server must give special treatment to cases in which the
+   processing following the end of mail data indication is only
+   partially successful.  This could happen if, after accepting several
+   recipients and the mail data, the SMTP server finds that the mail
+   data could be successfully delivered to some, but not all, of the
+   recipients.  In such cases, the response to the DATA command MUST be
+   an OK reply.  However, the SMTP server MUST compose and send an
+   "undeliverable mail" notification message to the originator of the
+   message.
+
+
+
+Klensin                     Standards Track                    [Page 51]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   A single notification listing all of the failed recipients or
+   separate notification messages MUST be sent for each failed
+   recipient.  For economy of processing by the sender, the former is
+   preferred when possible.  All undeliverable mail notification
+   messages are sent using the MAIL command (even if they result from
+   processing the obsolete SEND, SOML, or SAML commands) and use a null
+   return path as discussed in section 3.7.
+
+   The time stamp line and the return path line are formally defined as
+   follows:
+
+Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
+
+Time-stamp-line = "Received:" FWS Stamp <CRLF>
+
+Stamp = From-domain By-domain Opt-info ";"  FWS date-time
+
+      ; where "date-time" is as defined in [32]
+      ; but the "obs-" forms, especially two-digit
+      ; years, are prohibited in SMTP and MUST NOT be used.
+
+From-domain = "FROM" FWS Extended-Domain CFWS
+
+By-domain = "BY" FWS Extended-Domain CFWS
+
+Extended-Domain = Domain /
+           ( Domain FWS "(" TCP-info ")" ) /
+           ( Address-literal FWS "(" TCP-info ")" )
+
+TCP-info = Address-literal / ( Domain FWS Address-literal )
+      ; Information derived by server from TCP connection
+      ; not client EHLO.
+
+Opt-info = [Via] [With] [ID] [For]
+
+Via = "VIA" FWS Link CFWS
+
+With = "WITH" FWS Protocol CFWS
+
+ID = "ID" FWS String / msg-id CFWS
+
+For = "FOR" FWS 1*( Path / Mailbox ) CFWS
+
+Link = "TCP" / Addtl-Link
+Addtl-Link = Atom
+      ; Additional standard names for links are registered with the
+         ; Internet Assigned Numbers Authority (IANA).  "Via" is
+         ; primarily of value with non-Internet transports.  SMTP
+
+
+
+Klensin                     Standards Track                    [Page 52]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+         ; servers SHOULD NOT use unregistered names.
+Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
+Attdl-Protocol = Atom
+      ; Additional standard names for protocols are registered with the
+         ; Internet Assigned Numbers Authority (IANA).  SMTP servers
+         ; SHOULD NOT use unregistered names.
+
+4.5 Additional Implementation Issues
+
+4.5.1 Minimum Implementation
+
+   In order to make SMTP workable, the following minimum implementation
+   is required for all receivers.  The following commands MUST be
+   supported to conform to this specification:
+
+      EHLO
+      HELO
+      MAIL
+      RCPT
+      DATA
+      RSET
+      NOOP
+      QUIT
+      VRFY
+
+   Any system that includes an SMTP server supporting mail relaying or
+   delivery MUST support the reserved mailbox "postmaster" as a case-
+   insensitive local name.  This postmaster address is not strictly
+   necessary if the server always returns 554 on connection opening (as
+   described in section 3.1).  The requirement to accept mail for
+   postmaster implies that RCPT commands which specify a mailbox for
+   postmaster at any of the domains for which the SMTP server provides
+   mail service, as well as the special case of "RCPT TO:<Postmaster>"
+   (with no domain specification), MUST be supported.
+
+   SMTP systems are expected to make every reasonable effort to accept
+   mail directed to Postmaster from any other system on the Internet.
+   In extreme cases --such as to contain a denial of service attack or
+   other breach of security-- an SMTP server may block mail directed to
+   Postmaster.  However, such arrangements SHOULD be narrowly tailored
+   so as to avoid blocking messages which are not part of such attacks.
+
+4.5.2 Transparency
+
+   Without some provision for data transparency, the character sequence
+   "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user.
+   In general, users are not aware of such "forbidden" sequences.  To
+
+
+
+
+Klensin                     Standards Track                    [Page 53]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   allow all user composed text to be transmitted transparently, the
+   following procedures are used:
+
+   -  Before sending a line of mail text, the SMTP client checks the
+      first character of the line.  If it is a period, one additional
+      period is inserted at the beginning of the line.
+
+   -  When a line of mail text is received by the SMTP server, it checks
+      the line.  If the line is composed of a single period, it is
+      treated as the end of mail indicator.  If the first character is a
+      period and there are other characters on the line, the first
+      character is deleted.
+
+   The mail data may contain any of the 128 ASCII characters.  All
+   characters are to be delivered to the recipient's mailbox, including
+   spaces, vertical and horizontal tabs, and other control characters.
+   If the transmission channel provides an 8-bit byte (octet) data
+   stream, the 7-bit ASCII codes are transmitted right justified in the
+   octets, with the high order bits cleared to zero.  See 3.7 for
+   special treatment of these conditions in SMTP systems serving a relay
+   function.
+
+   In some systems it may be necessary to transform the data as it is
+   received and stored.  This may be necessary for hosts that use a
+   different character set than ASCII as their local character set, that
+   store data in records rather than strings, or which use special
+   character sequences as delimiters inside mailboxes.  If such
+   transformations are necessary, they MUST be reversible, especially if
+   they are applied to mail being relayed.
+
+4.5.3 Sizes and Timeouts
+
+4.5.3.1 Size limits and minimums
+
+   There are several objects that have required minimum/maximum sizes.
+   Every implementation MUST be able to receive objects of at least
+   these sizes.  Objects larger than these sizes SHOULD be avoided when
+   possible.  However, some Internet mail constructs such as encoded
+   X.400 addresses [16] will often require larger objects: clients MAY
+   attempt to transmit these, but MUST be prepared for a server to
+   reject them if they cannot be handled by it.  To the maximum extent
+   possible, implementation techniques which impose no limits on the
+   length of these objects should be used.
+
+   local-part
+      The maximum total length of a user name or other local-part is 64
+      characters.
+
+
+
+
+Klensin                     Standards Track                    [Page 54]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   domain
+      The maximum total length of a domain name or number is 255
+      characters.
+
+   path
+      The maximum total length of a reverse-path or forward-path is 256
+      characters (including the punctuation and element separators).
+
+   command line
+      The maximum total length of a command line including the command
+      word and the <CRLF> is 512 characters.  SMTP extensions may be
+      used to increase this limit.
+
+   reply line
+      The maximum total length of a reply line including the reply code
+      and the <CRLF> is 512 characters.  More information may be
+      conveyed through multiple-line replies.
+
+   text line
+      The maximum total length of a text line including the <CRLF> is
+      1000 characters (not counting the leading dot duplicated for
+      transparency).  This number may be increased by the use of SMTP
+      Service Extensions.
+
+   message content
+      The maximum total length of a message content (including any
+      message headers as well as the message body) MUST BE at least 64K
+      octets.  Since the introduction of Internet standards for
+      multimedia mail [12], message lengths on the Internet have grown
+      dramatically, and message size restrictions should be avoided if
+      at all possible.  SMTP server systems that must impose
+      restrictions SHOULD implement the "SIZE" service extension [18],
+      and SMTP client systems that will send large messages SHOULD
+      utilize it when possible.
+
+   recipients buffer
+      The minimum total number of recipients that must be buffered is
+      100 recipients.  Rejection of messages (for excessive recipients)
+      with fewer than 100 RCPT commands is a violation of this
+      specification.  The general principle that relaying SMTP servers
+      MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation
+      tests on message headers suggests that rejecting a message based
+      on the total number of recipients shown in header fields is to be
+      discouraged.  A server which imposes a limit on the number of
+      recipients MUST behave in an orderly fashion,  such as to reject
+      additional addresses over its limit rather than silently
+      discarding addresses previously accepted.  A client that needs to
+
+
+
+
+Klensin                     Standards Track                    [Page 55]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      deliver a message containing over 100 RCPT commands SHOULD be
+      prepared to transmit in 100-recipient "chunks" if the server
+      declines to accept more than 100 recipients in a single message.
+
+   Errors due to exceeding these limits may be reported by using the
+   reply codes.  Some examples of reply codes are:
+
+      500 Line too long.
+   or
+      501 Path too long
+   or
+      452 Too many recipients  (see below)
+   or
+      552 Too much mail data.
+
+   RFC 821 [30] incorrectly listed the error where an SMTP server
+   exhausts its implementation limit on the number of RCPT commands
+   ("too many recipients") as having reply code 552.  The correct reply
+   code for this condition is 452.  Clients SHOULD treat a 552 code in
+   this case as a temporary, rather than permanent, failure so the logic
+   below works.
+
+   When a conforming SMTP server encounters this condition, it has at
+   least 100 successful RCPT commands in its recipients buffer.  If the
+   server is able to accept the message, then at least these 100
+   addresses will be removed from the SMTP client's queue.  When the
+   client attempts retransmission of those addresses which received 452
+   responses, at least 100 of these will be able to fit in the SMTP
+   server's recipients buffer.  Each retransmission attempt which is
+   able to deliver anything will be able to dispose of at least 100 of
+   these recipients.
+
+   If an SMTP server has an implementation limit on the number of RCPT
+   commands and this limit is exhausted, it MUST use a response code of
+   452 (but the client SHOULD also be prepared for a 552, as noted
+   above).  If the server has a configured site-policy limitation on the
+   number of RCPT commands, it MAY instead use a 5XX response code.
+   This would be most appropriate if the policy limitation was intended
+   to apply if the total recipient count for a particular message body
+   were enforced even if that message body was sent in multiple mail
+   transactions.
+
+4.5.3.2 Timeouts
+
+   An SMTP client MUST provide a timeout mechanism.  It MUST use per-
+   command timeouts rather than somehow trying to time the entire mail
+   transaction.  Timeouts SHOULD be easily reconfigurable, preferably
+   without recompiling the SMTP code.  To implement this, a timer is set
+
+
+
+Klensin                     Standards Track                    [Page 56]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   for each SMTP command and for each buffer of the data transfer.  The
+   latter means that the overall timeout is inherently proportional to
+   the size of the message.
+
+   Based on extensive experience with busy mail-relay hosts, the minimum
+   per-command timeout values SHOULD be as follows:
+
+   Initial 220 Message: 5 minutes
+      An SMTP client process needs to distinguish between a failed TCP
+      connection and a delay in receiving the initial 220 greeting
+      message.  Many SMTP servers accept a TCP connection but delay
+      delivery of the 220 message until their system load permits more
+      mail to be processed.
+
+   MAIL Command: 5 minutes
+
+   RCPT Command: 5 minutes
+      A longer timeout is required if processing of mailing lists and
+      aliases is not deferred until after the message was accepted.
+
+   DATA Initiation: 2 minutes
+      This is while awaiting the "354 Start Input" reply to a DATA
+      command.
+
+   Data Block: 3 minutes
+      This is while awaiting the completion of each TCP SEND call
+      transmitting a chunk of data.
+
+   DATA Termination: 10 minutes.
+      This is while awaiting the "250 OK" reply.  When the receiver gets
+      the final period terminating the message data, it typically
+      performs processing to deliver the message to a user mailbox.  A
+      spurious timeout at this point would be very wasteful and would
+      typically result in delivery of multiple copies of the message,
+      since it has been successfully sent and the server has accepted
+      responsibility for delivery.  See section 6.1 for additional
+      discussion.
+
+   An SMTP server SHOULD have a timeout of at least 5 minutes while it
+   is awaiting the next command from the sender.
+
+4.5.4 Retry Strategies
+
+   The common structure of a host SMTP implementation includes user
+   mailboxes, one or more areas for queuing messages in transit, and one
+   or more daemon processes for sending and receiving mail.  The exact
+   structure will vary depending on the needs of the users on the host
+
+
+
+
+Klensin                     Standards Track                    [Page 57]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   and the number and size of mailing lists supported by the host.  We
+   describe several optimizations that have proved helpful, particularly
+   for mailers supporting high traffic levels.
+
+   Any queuing strategy MUST include timeouts on all activities on a
+   per-command basis.  A queuing strategy MUST NOT send error messages
+   in response to error messages under any circumstances.
+
+4.5.4.1 Sending Strategy
+
+   The general model for an SMTP client is one or more processes that
+   periodically attempt to transmit outgoing mail.  In a typical system,
+   the program that composes a message has some method for requesting
+   immediate attention for a new piece of outgoing mail, while mail that
+   cannot be transmitted immediately MUST be queued and periodically
+   retried by the sender.  A mail queue entry will include not only the
+   message itself but also the envelope information.
+
+   The sender MUST delay retrying a particular destination after one
+   attempt has failed.  In general, the retry interval SHOULD be at
+   least 30 minutes; however, more sophisticated and variable strategies
+   will be beneficial when the SMTP client can determine the reason for
+   non-delivery.
+
+   Retries continue until the message is transmitted or the sender gives
+   up; the give-up time generally needs to be at least 4-5 days.  The
+   parameters to the retry algorithm MUST be configurable.
+
+   A client SHOULD keep a list of hosts it cannot reach and
+   corresponding connection timeouts, rather than just retrying queued
+   mail items.
+
+   Experience suggests that failures are typically transient (the target
+   system or its connection has crashed), favoring a policy of two
+   connection attempts in the first hour the message is in the queue,
+   and then backing off to one every two or three hours.
+
+   The SMTP client can shorten the queuing delay in cooperation with the
+   SMTP server.  For example, if mail is received from a particular
+   address, it is likely that mail queued for that host can now be sent.
+   Application of this principle may, in many cases, eliminate the
+   requirement for an explicit "send queues now" function such as ETRN
+   [9].
+
+   The strategy may be further modified as a result of multiple
+   addresses per host (see below) to optimize delivery time vs. resource
+   usage.
+
+
+
+
+Klensin                     Standards Track                    [Page 58]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   An SMTP client may have a large queue of messages for each
+   unavailable destination host.  If all of these messages were retried
+   in every retry cycle, there would be excessive Internet overhead and
+   the sending system would be blocked for a long period.  Note that an
+   SMTP client can generally determine that a delivery attempt has
+   failed only after a timeout of several minutes and even a one-minute
+   timeout per connection will result in a very large delay if retries
+   are repeated for dozens, or even hundreds, of queued messages to the
+   same host.
+
+   At the same time, SMTP clients SHOULD use great care in caching
+   negative responses from servers.  In an extreme case, if EHLO is
+   issued multiple times during the same SMTP connection, different
+   answers may be returned by the server.  More significantly, 5yz
+   responses to the MAIL command MUST NOT be cached.
+
+   When a mail message is to be delivered to multiple recipients, and
+   the SMTP server to which a copy of the message is to be sent is the
+   same for multiple recipients, then only one copy of the message
+   SHOULD be transmitted.  That is, the SMTP client SHOULD use the
+   command sequence:  MAIL, RCPT, RCPT,... RCPT, DATA instead of the
+   sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA.  However, if there
+   are very many addresses, a limit on the number of RCPT commands per
+   MAIL command MAY be imposed.  Implementation of this efficiency
+   feature is strongly encouraged.
+
+   Similarly, to achieve timely delivery, the SMTP client MAY support
+   multiple concurrent outgoing mail transactions.  However, some limit
+   may be appropriate to protect the host from devoting all its
+   resources to mail.
+
+4.5.4.2 Receiving Strategy
+
+   The SMTP server SHOULD attempt to keep a pending listen on the SMTP
+   port at all times.  This requires the support of multiple incoming
+   TCP connections for SMTP.  Some limit MAY be imposed but servers that
+   cannot handle more than one SMTP transaction at a time are not in
+   conformance with the intent of this specification.
+
+   As discussed above, when the SMTP server receives mail from a
+   particular host address, it could activate its own SMTP queuing
+   mechanisms to retry any mail pending for that host address.
+
+4.5.5   Messages with a null reverse-path
+
+   There are several types of notification messages which are required
+   by existing and proposed standards to be sent with a null reverse
+   path, namely non-delivery notifications as discussed in section 3.7,
+
+
+
+Klensin                     Standards Track                    [Page 59]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   other kinds of Delivery Status Notifications (DSNs) [24], and also
+   Message Disposition Notifications (MDNs) [10].  All of these kinds of
+   messages are notifications about a previous message, and they are
+   sent to the reverse-path of the previous mail message.  (If the
+   delivery of such a notification message fails, that usually indicates
+   a problem with the mail system of the host to which the notification
+   message is addressed.  For this reason, at some hosts the MTA is set
+   up to forward such failed notification messages to someone who is
+   able to fix problems with the mail system, e.g., via the postmaster
+   alias.)
+
+   All other types of messages (i.e., any message which is not required
+   by a standards-track RFC to have a null reverse-path) SHOULD be sent
+   with with a valid, non-null reverse-path.
+
+   Implementors of automated email processors should be careful to make
+   sure that the various kinds of messages with null reverse-path are
+   handled correctly, in particular such systems SHOULD NOT reply to
+   messages with null reverse-path.
+
+5. Address Resolution and Mail Handling
+
+   Once an SMTP client lexically identifies a domain to which mail will
+   be delivered for processing (as described in sections 3.6 and 3.7), a
+   DNS lookup MUST be performed to resolve the domain name [22].  The
+   names are expected to be fully-qualified domain names (FQDNs):
+   mechanisms for inferring FQDNs from partial names or local aliases
+   are outside of this specification and, due to a history of problems,
+   are generally discouraged.  The lookup first attempts to locate an MX
+   record associated with the name.  If a CNAME record is found instead,
+   the resulting name is processed as if it were the initial name.  If
+   no MX records are found, but an A RR is found, the A RR is treated as
+   if it was associated with an implicit MX RR, with a preference of 0,
+   pointing to that host.  If one or more MX RRs are found for a given
+   name, SMTP systems MUST NOT utilize any A RRs associated with that
+   name unless they are located using the MX RRs; the "implicit MX" rule
+   above applies only if there are no MX records present.  If MX records
+   are present, but none of them are usable, this situation MUST be
+   reported as an error.
+
+   When the lookup succeeds, the mapping can result in a list of
+   alternative delivery addresses rather than a single address, because
+   of multiple MX records, multihoming, or both.  To provide reliable
+   mail transmission, the SMTP client MUST be able to try (and retry)
+   each of the relevant addresses in this list in order, until a
+   delivery attempt succeeds.  However, there MAY also be a configurable
+   limit on the number of alternate addresses that can be tried.  In any
+   case, the SMTP client SHOULD try at least two addresses.
+
+
+
+Klensin                     Standards Track                    [Page 60]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   Two types of information is used to rank the host addresses: multiple
+   MX records, and multihomed hosts.
+
+   Multiple MX records contain a preference indication that MUST be used
+   in sorting (see below).  Lower numbers are more preferred than higher
+   ones.  If there are multiple destinations with the same preference
+   and there is no clear reason to favor one (e.g., by recognition of an
+   easily-reached address), then the sender-SMTP MUST randomize them to
+   spread the load across multiple mail exchangers for a specific
+   organization.
+
+   The destination host (perhaps taken from the preferred MX record) may
+   be multihomed, in which case the domain name resolver will return a
+   list of alternative IP addresses.  It is the responsibility of the
+   domain name resolver interface to have ordered this list by
+   decreasing preference if necessary, and SMTP MUST try them in the
+   order presented.
+
+   Although the capability to try multiple alternative addresses is
+   required, specific installations may want to limit or disable the use
+   of alternative addresses.  The question of whether a sender should
+   attempt retries using the different addresses of a multihomed host
+   has been controversial.  The main argument for using the multiple
+   addresses is that it maximizes the probability of timely delivery,
+   and indeed sometimes the probability of any delivery; the counter-
+   argument is that it may result in unnecessary resource use.  Note
+   that resource use is also strongly determined by the sending strategy
+   discussed in section 4.5.4.1.
+
+   If an SMTP server receives a message with a destination for which it
+   is a designated Mail eXchanger, it MAY relay the message (potentially
+   after having rewritten the MAIL FROM and/or RCPT TO addresses), make
+   final delivery of the message, or hand it off using some mechanism
+   outside the SMTP-provided transport environment.  Of course, neither
+   of the latter require that the list of MX records be examined
+   further.
+
+   If it determines that it should relay the message without rewriting
+   the address, it MUST sort the MX records to determine candidates for
+   delivery.  The records are first ordered by preference, with the
+   lowest-numbered records being most preferred.  The relay host MUST
+   then inspect the list for any of the names or addresses by which it
+   might be known in mail transactions.  If a matching record is found,
+   all records at that preference level and higher-numbered ones MUST be
+   discarded from consideration.  If there are no records left at that
+   point, it is an error condition, and the message MUST be returned as
+   undeliverable.  If records do remain, they SHOULD be tried, best
+   preference first, as described above.
+
+
+
+Klensin                     Standards Track                    [Page 61]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+6. Problem Detection and Handling
+
+6.1 Reliable Delivery and Replies by Email
+
+   When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
+   message in response to DATA), it is accepting responsibility for
+   delivering or relaying the message.  It must take this responsibility
+   seriously.  It MUST NOT lose the message for frivolous reasons, such
+   as because the host later crashes or because of a predictable
+   resource shortage.
+
+   If there is a delivery failure after acceptance of a message, the
+   receiver-SMTP MUST formulate and mail a notification message.  This
+   notification MUST be sent using a null ("<>") reverse path in the
+   envelope.  The recipient of this notification MUST be the address
+   from the envelope return path (or the Return-Path: line).  However,
+   if this address is null ("<>"), the receiver-SMTP MUST NOT send a
+   notification.  Obviously, nothing in this section can or should
+   prohibit local decisions (i.e., as part of the same system
+   environment as the receiver-SMTP) to log or otherwise transmit
+   information about null address events locally if that is desired.  If
+   the address is an explicit source route, it MUST be stripped down to
+   its final hop.
+
+   For example, suppose that an error notification must be sent for a
+   message that arrived with:
+
+      MAIL FROM:<@a,@b:user@d>
+
+   The notification message MUST be sent using:
+
+      RCPT TO:<user@d>
+
+   Some delivery failures after the message is accepted by SMTP will be
+   unavoidable.  For example, it may be impossible for the receiving
+   SMTP server to validate all the delivery addresses in RCPT command(s)
+   due to a "soft" domain system error, because the target is a mailing
+   list (see earlier discussion of RCPT), or because the server is
+   acting as a relay and has no immediate access to the delivering
+   system.
+
+   To avoid receiving duplicate messages as the result of timeouts, a
+   receiver-SMTP MUST seek to minimize the time required to respond to
+   the final <CRLF>.<CRLF> end of data indicator.  See RFC 1047 [28] for
+   a discussion of this problem.
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 62]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+6.2 Loop Detection
+
+   Simple counting of the number of "Received:" headers in a message has
+   proven to be an effective, although rarely optimal, method of
+   detecting loops in mail systems.  SMTP servers using this technique
+   SHOULD use a large rejection threshold, normally at least 100
+   Received entries.  Whatever mechanisms are used, servers MUST contain
+   provisions for detecting and stopping trivial loops.
+
+6.3 Compensating for Irregularities
+
+   Unfortunately, variations, creative interpretations, and outright
+   violations of Internet mail protocols do occur; some would suggest
+   that they occur quite frequently.  The debate as to whether a well-
+   behaved SMTP receiver or relay should reject a malformed message,
+   attempt to pass it on unchanged, or attempt to repair it to increase
+   the odds of successful delivery (or subsequent reply) began almost
+   with the dawn of structured network mail and shows no signs of
+   abating.  Advocates of rejection claim that attempted repairs are
+   rarely completely adequate and that rejection of bad messages is the
+   only way to get the offending software repaired.  Advocates of
+   "repair" or "deliver no matter what" argue that users prefer that
+   mail go through it if at all possible and that there are significant
+   market pressures in that direction.  In practice, these market
+   pressures may be more important to particular vendors than strict
+   conformance to the standards, regardless of the preference of the
+   actual developers.
+
+   The problems associated with ill-formed messages were exacerbated by
+   the introduction of the split-UA mail reading protocols [3, 26, 5,
+   21].  These protocols have encouraged the use of SMTP as a posting
+   protocol, and SMTP servers as relay systems for these client hosts
+   (which are often only intermittently connected to the Internet).
+   Historically, many of those client machines lacked some of the
+   mechanisms and information assumed by SMTP (and indeed, by the mail
+   format protocol [7]).  Some could not keep adequate track of time;
+   others had no concept of time zones; still others could not identify
+   their own names or addresses; and, of course, none could satisfy the
+   assumptions that underlay RFC 822's conception of authenticated
+   addresses.
+
+   In response to these weak SMTP clients, many SMTP systems now
+   complete messages that are delivered to them in incomplete or
+   incorrect form.  This strategy is generally considered appropriate
+   when the server can identify or authenticate the client, and there
+   are prior agreements between them.  By contrast, there is at best
+   great concern about fixes applied by a relay or delivery SMTP server
+   that has little or no knowledge of the user or client machine.
+
+
+
+Klensin                     Standards Track                    [Page 63]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   The following changes to a message being processed MAY be applied
+   when necessary by an originating SMTP server, or one used as the
+   target of SMTP as an initial posting protocol:
+
+   -  Addition of a message-id field when none appears
+
+   -  Addition of a date, time or time zone when none appears
+
+   -  Correction of addresses to proper FQDN format
+
+   The less information the server has about the client, the less likely
+   these changes are to be correct and the more caution and conservatism
+   should be applied when considering whether or not to perform fixes
+   and how.  These changes MUST NOT be applied by an SMTP server that
+   provides an intermediate relay function.
+
+   In all cases, properly-operating clients supplying correct
+   information are preferred to corrections by the SMTP server.  In all
+   cases, documentation of actions performed by the servers (in trace
+   fields and/or header comments) is strongly encouraged.
+
+7. Security Considerations
+
+7.1 Mail Security and Spoofing
+
+   SMTP mail is inherently insecure in that it is feasible for even
+   fairly casual users to negotiate directly with receiving and relaying
+   SMTP servers and create messages that will trick a naive recipient
+   into believing that they came from somewhere else.  Constructing such
+   a message so that the "spoofed" behavior cannot be detected by an
+   expert is somewhat more difficult, but not sufficiently so as to be a
+   deterrent to someone who is determined and knowledgeable.
+   Consequently, as knowledge of Internet mail increases, so does the
+   knowledge that SMTP mail inherently cannot be authenticated, or
+   integrity checks provided, at the transport level.  Real mail
+   security lies only in end-to-end methods involving the message
+   bodies, such as those which use digital signatures (see [14] and,
+   e.g., PGP [4] or S/MIME [31]).
+
+   Various protocol extensions and configuration options that provide
+   authentication at the transport level (e.g., from an SMTP client to
+   an SMTP server) improve somewhat on the traditional situation
+   described above.  However, unless they are accompanied by careful
+   handoffs of responsibility in a carefully-designed trust environment,
+   they remain inherently weaker than end-to-end mechanisms which use
+   digitally signed messages rather than depending on the integrity of
+   the transport system.
+
+
+
+
+Klensin                     Standards Track                    [Page 64]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   Efforts to make it more difficult for users to set envelope return
+   path and header "From" fields to point to valid addresses other than
+   their own are largely misguided: they frustrate legitimate
+   applications in which mail is sent by one user on behalf of another
+   or in which error (or normal) replies should be directed to a special
+   address.  (Systems that provide convenient ways for users to alter
+   these fields on a per-message basis should attempt to establish a
+   primary and permanent mailbox address for the user so that Sender
+   fields within the message data can be generated sensibly.)
+
+   This specification does not further address the authentication issues
+   associated with SMTP other than to advocate that useful functionality
+   not be disabled in the hope of providing some small margin of
+   protection against an ignorant user who is trying to fake mail.
+
+7.2 "Blind" Copies
+
+   Addresses that do not appear in the message headers may appear in the
+   RCPT commands to an SMTP server for a number of reasons.  The two
+   most common involve the use of a mailing address as a "list exploder"
+   (a single address that resolves into multiple addresses) and the
+   appearance of "blind copies".  Especially when more than one RCPT
+   command is present, and in order to avoid defeating some of the
+   purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy
+   the full set of RCPT command arguments into the headers, either as
+   part of trace headers or as informational or private-extension
+   headers.  Since this rule is often violated in practice, and cannot
+   be enforced, sending SMTP systems that are aware of "bcc" use MAY
+   find it helpful to send each blind copy as a separate message
+   transaction containing only a single RCPT command.
+
+   There is no inherent relationship between either "reverse" (from
+   MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP
+   transaction ("envelope") and the addresses in the headers.  Receiving
+   systems SHOULD NOT attempt to deduce such relationships and use them
+   to alter the headers of the message for delivery.  The popular
+   "Apparently-to" header is a violation of this principle as well as a
+   common source of unintended information disclosure and SHOULD NOT be
+   used.
+
+7.3 VRFY, EXPN, and Security
+
+   As discussed in section 3.5, individual sites may want to disable
+   either or both of VRFY or EXPN for security reasons.  As a corollary
+   to the above, implementations that permit this MUST NOT appear to
+   have verified addresses that are not, in fact, verified.  If a site
+
+
+
+
+
+Klensin                     Standards Track                    [Page 65]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   disables these commands for security reasons, the SMTP server MUST
+   return a 252 response, rather than a code that could be confused with
+   successful or unsuccessful verification.
+
+   Returning a 250 reply code with the address listed in the VRFY
+   command after having checked it only for syntax violates this rule.
+   Of course, an implementation that "supports" VRFY by always returning
+   550 whether or not the address is valid is equally not in
+   conformance.
+
+   Within the last few years, the contents of mailing lists have become
+   popular as an address information source for so-called "spammers."
+   The use of EXPN to "harvest" addresses has increased as list
+   administrators have installed protections against inappropriate uses
+   of the lists themselves.  Implementations SHOULD still provide
+   support for EXPN, but sites SHOULD carefully evaluate the tradeoffs.
+   As authentication mechanisms are introduced into SMTP, some sites may
+   choose to make EXPN available only to authenticated requestors.
+
+7.4 Information Disclosure in Announcements
+
+   There has been an ongoing debate about the tradeoffs between the
+   debugging advantages of announcing server type and version (and,
+   sometimes, even server domain name) in the greeting response or in
+   response to the HELP command and the disadvantages of exposing
+   information that might be useful in a potential hostile attack.  The
+   utility of the debugging information is beyond doubt.  Those who
+   argue for making it available point out that it is far better to
+   actually secure an SMTP server rather than hope that trying to
+   conceal known vulnerabilities by hiding the server's precise identity
+   will provide more protection.  Sites are encouraged to evaluate the
+   tradeoff with that issue in mind; implementations are strongly
+   encouraged to minimally provide for making type and version
+   information available in some way to other network hosts.
+
+7.5 Information Disclosure in Trace Fields
+
+   In some circumstances, such as when mail originates from within a LAN
+   whose hosts are not directly on the public Internet, trace
+   ("Received") fields produced in conformance with this specification
+   may disclose host names and similar information that would not
+   normally be available.  This ordinarily does not pose a problem, but
+   sites with special concerns about name disclosure should be aware of
+   it.  Also, the optional FOR clause should be supplied with caution or
+   not at all when multiple recipients are involved lest it
+   inadvertently disclose the identities of "blind copy" recipients to
+   others.
+
+
+
+
+Klensin                     Standards Track                    [Page 66]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+7.6 Information Disclosure in Message Forwarding
+
+   As discussed in section 3.4, use of the 251 or 551 reply codes to
+   identify the replacement address associated with a mailbox may
+   inadvertently disclose sensitive information.  Sites that are
+   concerned about those issues should ensure that they select and
+   configure servers appropriately.
+
+7.7 Scope of Operation of SMTP Servers
+
+   It is a well-established principle that an SMTP server may refuse to
+   accept mail for any operational or technical reason that makes sense
+   to the site providing the server.  However, cooperation among sites
+   and installations makes the Internet possible.  If sites take
+   excessive advantage of the right to reject traffic, the ubiquity of
+   email availability (one of the strengths of the Internet) will be
+   threatened; considerable care should be taken and balance maintained
+   if a site decides to be selective about the traffic it will accept
+   and process.
+
+   In recent years, use of the relay function through arbitrary sites
+   has been used as part of hostile efforts to hide the actual origins
+   of mail.  Some sites have decided to limit the use of the relay
+   function to known or identifiable sources, and implementations SHOULD
+   provide the capability to perform this type of filtering.  When mail
+   is rejected for these or other policy reasons, a 550 code SHOULD be
+   used in response to EHLO, MAIL, or RCPT as appropriate.
+
+8. IANA Considerations
+
+   IANA will maintain three registries in support of this specification.
+   The first consists of SMTP service extensions with the associated
+   keywords, and, as needed, parameters and verbs.  As specified in
+   section 2.2.2, no entry may be made in this registry that starts in
+   an "X".  Entries may be made only for service extensions (and
+   associated keywords, parameters, or verbs) that are defined in
+   standards-track or experimental RFCs specifically approved by the
+   IESG for this purpose.
+
+   The second registry consists of "tags" that identify forms of domain
+   literals other than those for IPv4 addresses (specified in RFC 821
+   and in this document) and IPv6 addresses (specified in this
+   document).  Additional literal types require standardization before
+   being used; none are anticipated at this time.
+
+   The third, established by RFC 821 and renewed by this specification,
+   is a registry of link and protocol identifiers to be used with the
+   "via" and "with" subclauses of the time stamp ("Received: header")
+
+
+
+Klensin                     Standards Track                    [Page 67]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   described in section 4.4.  Link and protocol identifiers in addition
+   to those specified in this document may be registered only by
+   standardization or by way of an RFC-documented, IESG-approved,
+   Experimental protocol extension.
+
+9. References
+
+   [1]  American National Standards Institute (formerly United States of
+        America Standards Institute), X3.4, 1968, "USA Code for
+        Information Interchange". ANSI X3.4-1968 has been replaced by
+        newer versions with slight modifications, but the 1968 version
+        remains definitive for the Internet.
+
+   [2]  Braden, R., "Requirements for Internet hosts - application and
+        support", STD 3, RFC 1123, October 1989.
+
+   [3]  Butler, M., Chase, D., Goldberger, J., Postel, J. and J.
+        Reynolds, "Post Office Protocol - version 2", RFC 937, February
+        1985.
+
+   [4]  Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
+        Message Format", RFC 2440, November 1998.
+
+   [5]  Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC
+        1176, August 1990.
+
+   [6]  Crispin, M., "Internet Message Access Protocol - Version 4", RFC
+        2060, December 1996.
+
+   [7]  Crocker, D., "Standard for the Format of ARPA Internet Text
+        Messages", RFC 822, August 1982.
+
+   [8]  Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax
+        Specifications: ABNF", RFC 2234, November 1997.
+
+   [9]  De Winter, J., "SMTP Service Extension for Remote Message Queue
+        Starting", RFC 1985, August 1996.
+
+   [10] Fajman, R., "An Extensible Message Format for Message
+        Disposition Notifications", RFC 2298, March 1998.
+
+   [11] Freed, N, "Behavior of and Requirements for Internet Firewalls",
+        RFC 2979, October 2000.
+
+   [12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+        Extensions (MIME) Part One: Format of Internet Message Bodies",
+        RFC 2045, December 1996.
+
+
+
+
+Klensin                     Standards Track                    [Page 68]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   [13] Freed, N., "SMTP Service Extension for Command Pipelining", RFC
+        2920, September 2000.
+
+   [14] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
+        Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
+        RFC 1847, October 1995.
+
+   [15] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
+        December 1998.
+
+   [16] Kille, S., "Mapping between X.400 and RFC822/MIME", RFC 2156,
+        January 1998.
+
+   [17] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing
+        Architecture", RFC 2373, July 1998.
+
+   [18] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension for
+        Message Size Declaration", STD 10, RFC 1870, November 1995.
+
+   [19] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
+        "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
+
+   [20] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
+        "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July
+        1994.
+
+   [21] Lambert, M., "PCMAIL: A distributed mail system for personal
+        computers", RFC 1056, July 1988.
+
+   [22] Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+        Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
+        Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
+        December 1996.
+
+   [24] Moore, K., "SMTP Service Extension for Delivery Status
+        Notifications", RFC 1891, January 1996.
+
+   [25] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
+        Delivery Status Notifications", RFC 1894, January 1996.
+
+   [26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
+        53, RFC 1939, May 1996.
+
+
+
+
+Klensin                     Standards Track                    [Page 69]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   [27] Partridge, C., "Mail routing and the domain system", RFC 974,
+        January 1986.
+
+   [28] Partridge, C., "Duplicate messages and SMTP", RFC 1047, February
+        1988.
+
+   [29] Postel, J., ed., "Transmission Control Protocol - DARPA Internet
+        Program Protocol Specification", STD 7, RFC 793, September 1981.
+
+   [30] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August
+        1982.
+
+   [31] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC
+        2633, June 1999.
+
+   [32] Resnick, P., Ed., "Internet Message Format", RFC 2822, April
+        2001.
+
+   [33] Vaudreuil, G., "SMTP Service Extensions for Transmission of
+        Large and Binary MIME Messages", RFC 1830, August 1995.
+
+   [34] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
+        January 1996.
+
+10. Editor's Address
+
+   John C. Klensin
+   AT&T Laboratories
+   99 Bedford St
+   Boston, MA 02111 USA
+
+   Phone: 617-574-3076
+   EMail: klensin@research.att.com
+
+11. Acknowledgments
+
+   Many people worked long and hard on the many iterations of this
+   document.  There was wide-ranging debate in the IETF DRUMS Working
+   Group, both on its mailing list and in face to face discussions,
+   about many technical issues and the role of a revised standard for
+   Internet mail transport, and many contributors helped form the
+   wording in this specification.  The hundreds of participants in the
+   many discussions since RFC 821 was produced are too numerous to
+   mention, but they all helped this document become what it is.
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 70]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+APPENDICES
+
+A. TCP Transport Service
+
+   The TCP connection supports the transmission of 8-bit bytes.  The
+   SMTP data is 7-bit ASCII characters.  Each character is transmitted
+   as an 8-bit byte with the high-order bit cleared to zero.  Service
+   extensions may modify this rule to permit transmission of full 8-bit
+   data bytes as part of the message body, but not in SMTP commands or
+   responses.
+
+B. Generating SMTP Commands from RFC 822 Headers
+
+   Some systems use RFC 822 headers (only) in a mail submission
+   protocol, or otherwise generate SMTP commands from RFC 822 headers
+   when such a message is handed to an MTA from a UA.  While the MTA-UA
+   protocol is a private matter, not covered by any Internet Standard,
+   there are problems with this approach.  For example, there have been
+   repeated problems with proper handling of "bcc" copies and
+   redistribution lists when information that conceptually belongs to a
+   mail envelopes is not separated early in processing from header
+   information (and kept separate).
+
+   It is recommended that the UA provide its initial ("submission
+   client") MTA with an envelope separate from the message itself.
+   However, if the envelope is not supplied, SMTP commands SHOULD be
+   generated as follows:
+
+   1. Each recipient address from a TO, CC, or BCC header field SHOULD
+      be copied to a RCPT command (generating multiple message copies if
+      that is required for queuing or delivery).  This includes any
+      addresses listed in a RFC 822 "group".  Any BCC fields SHOULD then
+      be removed from the headers.  Once this process is completed, the
+      remaining headers SHOULD be checked to verify that at least one
+      To:, Cc:, or Bcc: header remains.  If none do, then a bcc: header
+      with no additional information SHOULD be inserted as specified in
+      [32].
+
+   2. The return address in the MAIL command SHOULD, if possible, be
+      derived from the system's identity for the submitting (local)
+      user, and the "From:" header field otherwise.  If there is a
+      system identity available, it SHOULD also be copied to the Sender
+      header field if it is different from the address in the From
+      header field.  (Any Sender field that was already there SHOULD be
+      removed.)  Systems may provide a way for submitters to override
+      the envelope return address, but may want to restrict its use to
+      privileged users.  This will not prevent mail forgery, but may
+      lessen its incidence; see section 7.1.
+
+
+
+Klensin                     Standards Track                    [Page 71]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   When an MTA is being used in this way, it bears responsibility for
+   ensuring that the message being transmitted is valid.  The mechanisms
+   for checking that validity, and for handling (or returning) messages
+   that are not valid at the time of arrival, are part of the MUA-MTA
+   interface and not covered by this specification.
+
+   A submission protocol based on Standard RFC 822 information alone
+   MUST NOT be used to gateway a message from a foreign (non-SMTP) mail
+   system into an SMTP environment.  Additional information to construct
+   an envelope must come from some source in the other environment,
+   whether supplemental headers or the foreign system's envelope.
+
+   Attempts to gateway messages using only their header "to" and "cc"
+   fields have repeatedly caused mail loops and other behavior adverse
+   to the proper functioning of the Internet mail environment.  These
+   problems have been especially common when the message originates from
+   an Internet mailing list and is distributed into the foreign
+   environment using envelope information.  When these messages are then
+   processed by a header-only remailer, loops back to the Internet
+   environment (and the mailing list) are almost inevitable.
+
+C. Source Routes
+
+   Historically, the <reverse-path> was a reverse source routing list of
+   hosts and a source mailbox.  The first host in the <reverse-path>
+   SHOULD be the host sending the MAIL command.  Similarly, the
+   <forward-path> may be a source routing lists of hosts and a
+   destination mailbox.  However, in general, the <forward-path> SHOULD
+   contain only a mailbox and domain name, relying on the domain name
+   system to supply routing information if required.  The use of source
+   routes is deprecated; while servers MUST be prepared to receive and
+   handle them as discussed in section 3.3 and F.2, clients SHOULD NOT
+   transmit them and this section was included only to provide context.
+
+   For relay purposes, the forward-path may be a source route of the
+   form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE fully-
+   qualified domain names.  This form is used to emphasize the
+   distinction between an address and a route.  The mailbox is an
+   absolute address, and the route is information about how to get
+   there.  The two concepts should not be confused.
+
+   If source routes are used, RFC 821 and the text below should be
+   consulted for the mechanisms for constructing and updating the
+   forward- and reverse-paths.
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 72]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+   The SMTP server transforms the command arguments by moving its own
+   identifier (its domain name or that of any domain for which it is
+   acting as a mail exchanger), if it appears, from the forward-path to
+   the beginning of the reverse-path.
+
+   Notice that the forward-path and reverse-path appear in the SMTP
+   commands and replies, but not necessarily in the message.  That is,
+   there is no need for these paths and especially this syntax to appear
+   in the "To:" , "From:", "CC:", etc. fields of the message header.
+   Conversely, SMTP servers MUST NOT derive final message delivery
+   information from message header fields.
+
+   When the list of hosts is present, it is a "reverse" source route and
+   indicates that the mail was relayed through each host on the list
+   (the first host in the list was the most recent relay).  This list is
+   used as a source route to return non-delivery notices to the sender.
+   As each relay host adds itself to the beginning of the list, it MUST
+   use its name as known in the transport environment to which it is
+   relaying the mail rather than that of the transport environment from
+   which the mail came (if they are different).
+
+D. Scenarios
+
+   This section presents complete scenarios of several types of SMTP
+   sessions.  In the examples, "C:" indicates what is said by the SMTP
+   client, and "S:" indicates what is said by the SMTP server.
+
+D.1 A Typical SMTP Transaction Scenario
+
+   This SMTP example shows mail sent by Smith at host bar.com, to Jones,
+   Green, and Brown at host foo.com.  Here we assume that host bar.com
+   contacts host foo.com directly.  The mail is accepted for Jones and
+   Brown.  Green does not have a mailbox at host foo.com.
+
+      S: 220 foo.com Simple Mail Transfer Service Ready
+      C: EHLO bar.com
+      S: 250-foo.com greets bar.com
+      S: 250-8BITMIME
+      S: 250-SIZE
+      S: 250-DSN
+      S: 250 HELP
+      C: MAIL FROM:<Smith@bar.com>
+      S: 250 OK
+      C: RCPT TO:<Jones@foo.com>
+      S: 250 OK
+      C: RCPT TO:<Green@foo.com>
+      S: 550 No such user here
+      C: RCPT TO:<Brown@foo.com>
+
+
+
+Klensin                     Standards Track                    [Page 73]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      S: 250 OK
+      C: DATA
+      S: 354 Start mail input; end with <CRLF>.<CRLF>
+      C: Blah blah blah...
+      C: ...etc. etc. etc.
+      C: .
+      S: 250 OK
+      C: QUIT
+      S: 221 foo.com Service closing transmission channel
+
+D.2 Aborted SMTP Transaction Scenario
+
+      S: 220 foo.com Simple Mail Transfer Service Ready
+      C: EHLO bar.com
+      S: 250-foo.com greets bar.com
+      S: 250-8BITMIME
+      S: 250-SIZE
+      S: 250-DSN
+      S: 250 HELP
+      C: MAIL FROM:<Smith@bar.com>
+      S: 250 OK
+      C: RCPT TO:<Jones@foo.com>
+      S: 250 OK
+      C: RCPT TO:<Green@foo.com>
+      S: 550 No such user here
+      C: RSET
+      S: 250 OK
+      C: QUIT
+      S: 221 foo.com Service closing transmission channel
+
+D.3 Relayed Mail Scenario
+
+   Step 1  --  Source Host to Relay Host
+
+      S: 220 foo.com Simple Mail Transfer Service Ready
+      C: EHLO bar.com
+      S: 250-foo.com greets bar.com
+      S: 250-8BITMIME
+      S: 250-SIZE
+      S: 250-DSN
+      S: 250 HELP
+      C: MAIL FROM:<JQP@bar.com>
+      S: 250 OK
+      C: RCPT TO:<@foo.com:Jones@XYZ.COM>
+      S: 250 OK
+      C: DATA
+      S: 354 Start mail input; end with <CRLF>.<CRLF>
+      C: Date: Thu, 21 May 1998 05:33:29 -0700
+
+
+
+Klensin                     Standards Track                    [Page 74]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      C: From: John Q. Public <JQP@bar.com>
+      C: Subject:  The Next Meeting of the Board
+      C: To: Jones@xyz.com
+      C:
+      C: Bill:
+      C: The next meeting of the board of directors will be
+      C: on Tuesday.
+      C:                         John.
+      C: .
+      S: 250 OK
+      C: QUIT
+      S: 221 foo.com Service closing transmission channel
+
+   Step 2  --  Relay Host to Destination Host
+
+      S: 220 xyz.com Simple Mail Transfer Service Ready
+      C: EHLO foo.com
+      S: 250 xyz.com is on the air
+      C: MAIL FROM:<@foo.com:JQP@bar.com>
+      S: 250 OK
+      C: RCPT TO:<Jones@XYZ.COM>
+      S: 250 OK
+      C: DATA
+      S: 354 Start mail input; end with <CRLF>.<CRLF>
+      C: Received: from bar.com by foo.com ; Thu, 21 May 1998
+      C:     05:33:29 -0700
+      C: Date: Thu, 21 May 1998 05:33:22 -0700
+      C: From: John Q. Public <JQP@bar.com>
+      C: Subject:  The Next Meeting of the Board
+      C: To: Jones@xyz.com
+      C:
+      C: Bill:
+      C: The next meeting of the board of directors will be
+      C: on Tuesday.
+      C:                         John.
+      C: .
+      S: 250 OK
+      C: QUIT
+      S: 221 foo.com Service closing transmission channel
+
+D.4 Verifying and Sending Scenario
+
+      S: 220 foo.com Simple Mail Transfer Service Ready
+      C: EHLO bar.com
+      S: 250-foo.com greets bar.com
+      S: 250-8BITMIME
+      S: 250-SIZE
+      S: 250-DSN
+
+
+
+Klensin                     Standards Track                    [Page 75]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+      S: 250-VRFY
+      S: 250 HELP
+      C: VRFY Crispin
+      S: 250 Mark Crispin <Admin.MRC@foo.com>
+      C: SEND FROM:<EAK@bar.com>
+      S: 250 OK
+      C: RCPT TO:<Admin.MRC@foo.com>
+      S: 250 OK
+      C: DATA
+      S: 354 Start mail input; end with <CRLF>.<CRLF>
+      C: Blah blah blah...
+      C: ...etc. etc. etc.
+      C: .
+      S: 250 OK
+      C: QUIT
+      S: 221 foo.com Service closing transmission channel
+
+E. Other Gateway Issues
+
+   In general, gateways between the Internet and other mail systems
+   SHOULD attempt to preserve any layering semantics across the
+   boundaries between the two mail systems involved.  Gateway-
+   translation approaches that attempt to take shortcuts by mapping,
+   (such as envelope information from one system to the message headers
+   or body of another) have generally proven to be inadequate in
+   important ways.  Systems translating between environments that do not
+   support both envelopes and headers and Internet mail must be written
+   with the understanding that some information loss is almost
+   inevitable.
+
+F. Deprecated Features of RFC 821
+
+   A few features of RFC 821 have proven to be problematic and SHOULD
+   NOT be used in Internet mail.
+
+F.1 TURN
+
+   This command, described in RFC 821, raises important security issues
+   since, in the absence of strong authentication of the host requesting
+   that the client and server switch roles, it can easily be used to
+   divert mail from its correct destination.  Its use is deprecated;
+   SMTP systems SHOULD NOT use it unless the server can authenticate the
+   client.
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 76]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+F.2 Source Routing
+
+   RFC 821 utilized the concept of explicit source routing to get mail
+   from one host to another via a series of relays.  The requirement to
+   utilize source routes in regular mail traffic was eliminated by the
+   introduction of the domain name system "MX" record and the last
+   significant justification for them was eliminated by the
+   introduction, in RFC 1123, of a clear requirement that addresses
+   following an "@" must all be fully-qualified domain names.
+   Consequently, the only remaining justifications for the use of source
+   routes are support for very old SMTP clients or MUAs and in mail
+   system debugging.  They can, however, still be useful in the latter
+   circumstance and for routing mail around serious, but temporary,
+   problems such as problems with the relevant DNS records.
+
+   SMTP servers MUST continue to accept source route syntax as specified
+   in the main body of this document and in RFC 1123.  They MAY, if
+   necessary, ignore the routes and utilize only the target domain in
+   the address.  If they do utilize the source route, the message MUST
+   be sent to the first domain shown in the address.  In particular, a
+   server MUST NOT guess at shortcuts within the source route.
+
+   Clients SHOULD NOT utilize explicit source routing except under
+   unusual circumstances, such as debugging or potentially relaying
+   around firewall or mail system configuration errors.
+
+F.3 HELO
+
+   As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to
+   HELO when the server will accept the former.  Servers must continue
+   to accept and process HELO in order to support older clients.
+
+F.4 #-literals
+
+   RFC 821 provided for specifying an Internet address as a decimal
+   integer host number prefixed by a pound sign, "#".  In practice, that
+   form has been obsolete since the introduction of TCP/IP.  It is
+   deprecated and MUST NOT be used.
+
+F.5 Dates and Years
+
+   When dates are inserted into messages by SMTP clients or servers
+   (e.g., in trace fields), four-digit years MUST BE used.  Two-digit
+   years are deprecated; three-digit years were never permitted in the
+   Internet mail system.
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 77]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+F.6 Sending versus Mailing
+
+   In addition to specifying a mechanism for delivering messages to
+   user's mailboxes, RFC 821 provided additional, optional, commands to
+   deliver messages directly to the user's terminal screen.  These
+   commands (SEND, SAML, SOML) were rarely implemented, and changes in
+   workstation technology and the introduction of other protocols may
+   have rendered them obsolete even where they are implemented.
+
+   Clients SHOULD NOT provide SEND, SAML, or SOML as services.  Servers
+   MAY implement them.  If they are implemented by servers, the
+   implementation model specified in RFC 821 MUST be used and the
+   command names MUST be published in the response to the EHLO command.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 78]
+
+RFC 2821             Simple Mail Transfer Protocol            April 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 79]
+
diff --git a/docs/rfcs/rfc2971.txt b/docs/rfcs/rfc2971.txt
new file mode 100644
index 0000000..9e7264d
--- /dev/null
+++ b/docs/rfcs/rfc2971.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                        T. Showalter
+Request for Comments: 2971                                Mirapoint, Inc.
+Category: Standards Track                                    October 2000
+
+
+                           IMAP4 ID extension
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   The ID extension to the Internet Message Access Protocol - Version
+   4rev1 (IMAP4rev1) protocol allows the server and client to exchange
+   identification information on their implementation in order to make
+   bug reports and usage statistics more complete.
+
+1. Introduction
+
+   The IMAP4rev1 protocol described in [IMAP4rev1] provides a method for
+   accessing remote mail stores, but it provides no facility to
+   advertise what program a client or server uses to provide service.
+   This makes it difficult for implementors to get complete bug reports
+   from users, as it is frequently difficult to know what client or
+   server is in use.
+
+   Additionally, some sites may wish to assemble usage statistics based
+   on what clients are used, but in an an environment where users are
+   permitted to obtain and maintain their own clients this is difficult
+   to accomplish.
+
+   The ID command provides a facility to advertise information on what
+   programs are being used along with contact information (should bugs
+   ever occur).
+
+
+
+
+
+
+
+
+Showalter                   Standards Track                     [Page 1]
+
+RFC 2971                   IMAP4 ID extension               October 2000
+
+
+2. Conventions Used in this Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [KEYWORDS].
+
+   The conventions used in this document are the same as specified in
+   [IMAP4rev1].  In examples, "C:" and "S:" indicate lines sent by the
+   client and server respectively.  Line breaks have been inserted for
+   readability.
+
+3. Specification
+
+   The sole purpose of the ID extension is to enable clients and servers
+   to exchange information on their implementations for the purposes of
+   statistical analysis and problem determination.
+
+   This information is be submitted to a server by any client wishing to
+   provide information for statistical purposes, provided the server
+   advertises its willingness to take the information with the atom "ID"
+   included in the list of capabilities returned by the CAPABILITY
+   command.
+
+   Implementations MUST NOT make operational changes based on the data
+   sent as part of the ID command or response.  The ID command is for
+   human consumption only, and is not to be used in improving the
+   performance of clients or servers.
+
+   This includes, but is not limited to, the following:
+
+      Servers MUST NOT attempt to work around client bugs by using
+      information from the ID command.  Clients MUST NOT attempt to work
+      around server bugs based on the ID response.
+
+      Servers MUST NOT provide features to a client or otherwise
+      optimize for a particular client by using information from the ID
+      command.  Clients MUST NOT provide features to a server or
+      otherwise optimize for a particular server based on the ID
+      response.
+
+      Servers MUST NOT deny access to or refuse service for a client
+      based on information from the ID command.  Clients MUST NOT refuse
+      to operate or limit their operation with a server based on the ID
+      response.
+
+
+
+
+
+
+
+Showalter                   Standards Track                     [Page 2]
+
+RFC 2971                   IMAP4 ID extension               October 2000
+
+
+   Rationale: It is imperative that this extension not supplant IMAP's
+   CAPABILITY mechanism with a ad-hoc approach where implementations
+   guess each other's features based on who they claim to be.
+
+   Implementations MUST NOT send false information in an ID command.
+
+   Implementations MAY send less information than they have available or
+   no information at all.  Such behavior may be useful to preserve user
+   privacy.  See Security Considerations, section 7.
+
+3.1. ID Command
+
+   Arguments:  client parameter list or NIL
+
+   Responses:  OPTIONAL untagged response: ID
+
+   Result:     OK    identification information accepted
+               BAD   command unknown or arguments invalid
+
+   Implementation identification information is sent by the client with
+   the ID command.
+
+   This command is valid in any state.
+
+   The information sent is in the form of a list of field/value pairs.
+   Fields are permitted to be any IMAP4 string, and values are permitted
+   to be any IMAP4 string or NIL.  A value of NIL indicates that the
+   client can not or will not specify this information.  The client may
+   also send NIL instead of the list, indicating that it wants to send
+   no information, but would still accept a server response.
+
+   The available fields are defined in section 3.3.
+
+   Example:  C: a023 ID ("name" "sodr" "version" "19.34" "vendor"
+                 "Pink Floyd Music Limited")
+             S: * ID NIL
+             S: a023 OK ID completed
+
+3.2. ID Response
+
+   Contents:   server parameter list
+
+   In response to an ID command issued by the client, the server replies
+   with a tagged response containing information on its implementation.
+   The format is the same as the client list.
+
+
+
+
+
+
+Showalter                   Standards Track                     [Page 3]
+
+RFC 2971                   IMAP4 ID extension               October 2000
+
+
+   Example:  C: a042 ID NIL
+             S: * ID ("name" "Cyrus" "version" "1.5" "os" "sunos"
+                  "os-version" "5.5" "support-url"
+                  "mailto:cyrus-bugs+@andrew.cmu.edu")
+             S: a042 OK ID command completed
+
+   A server MUST send a tagged ID response to an ID command.  However, a
+   server MAY send NIL in place of the list.
+
+3.3. Defined Field Values
+
+   Any string may be sent as a field, but the following are defined to
+   describe certain values that might be sent.  Implementations are free
+   to send none, any, or all of these.  Strings are not case-sensitive.
+   Field strings MUST NOT be longer than 30 octets.  Value strings MUST
+   NOT be longer than 1024 octets.  Implementations MUST NOT send more
+   than 30 field-value pairs.
+
+     name            Name of the program
+     version         Version number of the program
+     os              Name of the operating system
+     os-version      Version of the operating system
+     vendor          Vendor of the client/server
+     support-url     URL to contact for support
+     address         Postal address of contact/vendor
+     date            Date program was released, specified as a date-time
+                       in IMAP4rev1
+     command         Command used to start the program
+     arguments       Arguments supplied on the command line, if any
+                       if any
+     environment     Description of environment, i.e., UNIX environment
+                       variables or Windows registry settings
+
+   Implementations MUST NOT use contact information to submit automatic
+   bug reports.  Implementations may include information from an ID
+   response in a report automatically prepared, but are prohibited from
+   sending the report without user authorization.
+
+   It is preferable to find the name and version of the underlying
+   operating system at runtime in cases where this is possible.
+
+   Information sent via an ID response may violate user privacy.  See
+   Security Considerations, section 7.
+
+   Implementations MUST NOT send the same field name more than once.
+
+
+
+
+
+
+Showalter                   Standards Track                     [Page 4]
+
+RFC 2971                   IMAP4 ID extension               October 2000
+
+
+4. Formal Syntax
+
+   This  syntax is intended to augment the grammar specified in
+   [IMAP4rev1] in order to provide for the ID command.  This
+   specification uses the augmented Backus-Naur Form (BNF) notation as
+   used in [IMAP4rev1].
+
+     command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command / id
+         ;; adds id command to command_any in [IMAP4rev1]
+
+     id ::= "ID" SPACE id_params_list
+
+     id_response ::= "ID" SPACE id_params_list
+
+     id_params_list ::= "(" #(string SPACE nstring) ")" / nil
+         ;; list of field value pairs
+
+     response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /
+         mailbox_data / message_data / capability_data / id_response)
+
+5. Use of the ID extension with Firewalls and Other Intermediaries
+
+   There exist proxies, firewalls, and other intermediary systems that
+   can intercept an IMAP session and make changes to the data exchanged
+   in the session.  Such intermediaries are not anticipated by the IMAP4
+   protocol design and are not within the scope of the IMAP4 standard.
+   However, in order for the ID command to be useful in the presence of
+   such intermediaries, those intermediaries need to take special note
+   of the ID command and response.  In particular, if an intermediary
+   changes any part of the IMAP session it must also change the ID
+   command to advertise its presence.
+
+   A firewall MAY act to block transmission of specific information
+   fields in the ID command and response that it believes reveal
+   information that could expose a security vulnerability.  However, a
+   firewall SHOULD NOT disable the extension, when present, entirely,
+   and SHOULD NOT unconditionally remove either the client or server
+   list.
+
+   Finally, it should be noted that a firewall, when handling a
+   CAPABILITY response, MUST NOT allow the names of extensions to be
+   returned to the client that the firewall has no knowledge of.
+
+
+
+
+
+
+
+
+
+Showalter                   Standards Track                     [Page 5]
+
+RFC 2971                   IMAP4 ID extension               October 2000
+
+
+6. References
+
+   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", RFC 2119, March 1997.
+
+   [IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version
+               4rev1", RFC 2060, October 1996.
+
+   [RFC-822]   Crocker, D., "Standard for the Format of ARPA Internet
+               Text Messages", STD 11, RFC 822, August 1982.
+
+7. Security Considerations
+
+   This extension has the danger of violating the privacy of users if
+   misused.  Clients and servers should notify users that they implement
+   and enable the ID command.
+
+   It is highly desirable that implementations provide a method of
+   disabling ID support, perhaps by not sending ID at all, or by sending
+   NIL as the argument to the ID command or response.
+
+   Implementors must exercise extreme care in adding fields sent as part
+   of an ID command or response.  Some fields, including a processor ID
+   number, Ethernet address, or other unique (or mostly unique)
+   identifier allow tracking of users in ways that violate user privacy
+   expectations.
+
+   Having implementation information of a given client or server may
+   make it easier for an attacker to gain unauthorized access due to
+   security holes.
+
+   Since this command includes arbitrary data and does not require the
+   user to authenticate, server implementations are cautioned to guard
+   against an attacker sending arbitrary garbage data in order to fill
+   up the ID log.  In particular, if a server naively logs each ID
+   command to disk without inspecting it, an attacker can simply fire up
+   thousands of connections and send a few kilobytes of random data.
+   Servers have to guard against this.  Methods include truncating
+   abnormally large responses; collating responses by storing only a
+   single copy, then keeping a counter of the number of times that
+   response has been seen; keeping only particularly interesting parts
+   of responses; and only logging responses of users who actually log
+   in.
+
+   Security is affected by firewalls which modify the IMAP protocol
+   stream; see section 5, Use of the ID Extension with Firewalls and
+   Other Intermediaries, for more information.
+
+
+
+
+Showalter                   Standards Track                     [Page 6]
+
+RFC 2971                   IMAP4 ID extension               October 2000
+
+
+8. Author's Address
+
+   Tim Showalter
+   Mirapoint, Inc.
+   909 Hermosa Ct.
+   Sunnyvale, CA 94095
+
+   EMail: tjs@mirapoint.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Showalter                   Standards Track                     [Page 7]
+
+RFC 2971                   IMAP4 ID extension               October 2000
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Showalter                   Standards Track                     [Page 8]
+
diff --git a/docs/rfcs/rfc3028.txt b/docs/rfcs/rfc3028.txt
new file mode 100644
index 0000000..d909a54
--- /dev/null
+++ b/docs/rfcs/rfc3028.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+Network Working Group                                       T. Showalter
+Request for Comments: 3028                               Mirapoint, Inc.
+Category: Standards Track                                   January 2001
+
+
+                    Sieve: A Mail Filtering Language
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document describes a language for filtering e-mail messages at
+   time of final delivery.  It is designed to be implementable on either
+   a mail client or mail server.  It is meant to be extensible, simple,
+   and independent of access protocol, mail architecture, and operating
+   system.  It is suitable for running on a mail server where users may
+   not be allowed to execute arbitrary programs, such as on black box
+   Internet Message Access Protocol (IMAP) servers, as it has no
+   variables, loops, or ability to shell out to external programs.
+
+Table of Contents
+
+   1.      Introduction ...........................................   3
+   1.1.     Conventions Used in This Document .....................   4
+   1.2.     Example mail messages .................................   4
+   2.      Design .................................................   5
+   2.1.     Form of the Language ..................................   5
+   2.2.     Whitespace ............................................   5
+   2.3.     Comments ..............................................   6
+   2.4.     Literal Data ..........................................   6
+   2.4.1.   Numbers ...............................................   6
+   2.4.2.   Strings ...............................................   7
+   2.4.2.1. String Lists ..........................................   7
+   2.4.2.2. Headers ...............................................   8
+   2.4.2.3. Addresses .............................................   8
+   2.4.2.4. MIME Parts ............................................   9
+   2.5.     Tests .................................................   9
+   2.5.1.   Test Lists ............................................   9
+
+
+
+Showalter                   Standards Track                     [Page 1]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   2.6.     Arguments .............................................   9
+   2.6.1.   Positional Arguments ..................................   9
+   2.6.2.   Tagged Arguments ......................................  10
+   2.6.3.   Optional Arguments ....................................  10
+   2.6.4.   Types of Arguments ....................................  10
+   2.7.     String Comparison .....................................  11
+   2.7.1.   Match Type ............................................  11
+   2.7.2.   Comparisons Across Character Sets .....................  12
+   2.7.3.   Comparators ...........................................  12
+   2.7.4.   Comparisons Against Addresses .........................  13
+   2.8.     Blocks ................................................  14
+   2.9.     Commands ..............................................  14
+   2.10.    Evaluation ............................................  15
+   2.10.1.  Action Interaction ....................................  15
+   2.10.2.  Implicit Keep .........................................  15
+   2.10.3.  Message Uniqueness in a Mailbox .......................  15
+   2.10.4.  Limits on Numbers of Actions ..........................  16
+   2.10.5.  Extensions and Optional Features ......................  16
+   2.10.6.  Errors ................................................  17
+   2.10.7.  Limits on Execution ...................................  17
+   3.      Control Commands .......................................  17
+   3.1.     Control Structure If ..................................  18
+   3.2.     Control Structure Require .............................  19
+   3.3.     Control Structure Stop ................................  19
+   4.      Action Commands ........................................  19
+   4.1.     Action reject .........................................  20
+   4.2.     Action fileinto .......................................  20
+   4.3.     Action redirect .......................................  21
+   4.4.     Action keep ...........................................  21
+   4.5.     Action discard ........................................  22
+   5.      Test Commands ..........................................  22
+   5.1.     Test address ..........................................  23
+   5.2.     Test allof ............................................  23
+   5.3.     Test anyof ............................................  24
+   5.4.     Test envelope .........................................  24
+   5.5.     Test exists ...........................................  25
+   5.6.     Test false ............................................  25
+   5.7.     Test header ...........................................  25
+   5.8.     Test not ..............................................  26
+   5.9.     Test size .............................................  26
+   5.10.    Test true .............................................  26
+   6.      Extensibility ..........................................  26
+   6.1.     Capability String .....................................  27
+   6.2.     IANA Considerations ...................................  28
+   6.2.1.   Template for Capability Registrations .................  28
+   6.2.2.   Initial Capability Registrations ......................  28
+   6.3.     Capability Transport ..................................  29
+   7.      Transmission ...........................................  29
+
+
+
+Showalter                   Standards Track                     [Page 2]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   8.      Parsing ................................................  30
+   8.1.     Lexical Tokens ........................................  30
+   8.2.     Grammar ...............................................  31
+   9.      Extended Example .......................................  32
+   10.     Security Considerations ................................  34
+   11.     Acknowledgments ........................................  34
+   12.     Author's Address .......................................  34
+   13.     References .............................................  34
+   14.     Full Copyright Statement ...............................  36
+
+1.      Introduction
+
+   This memo documents a language that can be used to create filters for
+   electronic mail.  It is not tied to any particular operating system or
+   mail architecture.  It requires the use of [IMAIL]-compliant
+   messages, but should otherwise generalize to many systems.
+
+   The language is powerful enough to be useful but limited in order to
+   allow for a safe server-side filtering system.  The intention is to
+   make it impossible for users to do anything more complex (and
+   dangerous) than write simple mail filters, along with facilitating
+   the use of GUIs for filter creation and manipulation.  The language is
+   not Turing-complete: it provides no way to write a loop or a function
+   and variables are not provided.
+
+   Scripts written in Sieve are executed during final delivery, when the
+   message is moved to the user-accessible mailbox.  In systems where
+   the MTA does final delivery, such as traditional Unix mail, it is
+   reasonable to sort when the MTA deposits mail into the user's
+   mailbox.
+
+   There are a number of reasons to use a filtering system.  Mail
+   traffic for most users has been increasing due to increased usage of
+   e-mail, the emergence of unsolicited email as a form of advertising,
+   and increased usage of mailing lists.
+
+   Experience at Carnegie Mellon has shown that if a filtering system is
+   made available to users, many will make use of it in order to file
+   messages from specific users or mailing lists.  However, many others
+   did not make use of the Andrew system's FLAMES filtering language
+   [FLAMES] due to difficulty in setting it up.
+
+   Because of the expectation that users will make use of filtering if
+   it is offered and easy to use, this language has been made simple
+   enough to allow many users to make use of it, but rich enough that it
+   can be used productively.  However, it is expected that GUI-based
+   editors will be the preferred way of editing filters for a large
+   number of users.
+
+
+
+Showalter                   Standards Track                     [Page 3]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+1.1.     Conventions Used in This Document
+
+   In the sections of this document that discuss the requirements of
+   various keywords and operators, the following conventions have been
+   adopted.
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and
+   "MAY" in this document are to be interpreted as defined in
+   [KEYWORDS].
+
+   Each section on a command (test, action, or control structure) has a
+   line labeled "Syntax:".  This line describes the syntax of the
+   command, including its name and its arguments.  Required arguments
+   are listed inside angle brackets ("<" and ">").  Optional arguments
+   are listed inside square brackets ("[" and "]").  Each argument is
+   followed by its type, so "<key: string>" represents an argument
+   called "key" that is a string.  Literal strings are represented with
+   double-quoted strings.  Alternatives are separated with slashes, and
+   parenthesis are used for grouping, similar to [ABNF].
+
+   In the "Syntax" line, there are three special pieces of syntax that
+   are frequently repeated, MATCH-TYPE, COMPARATOR, and ADDRESS-PART.
+   These are discussed in sections 2.7.1, 2.7.3, and 2.7.4,
+   respectively.
+
+   The formal grammar for these commands in section 10 and is the
+   authoritative reference on how to construct commands, but the formal
+   grammar does not specify the order, semantics, number or types of
+   arguments to commands, nor the legal command names.  The intent is to
+   allow for extension without changing the grammar.
+
+1.2.     Example mail messages
+
+   The following mail messages will be used throughout this document in
+   examples.
+
+   Message A
+   -----------------------------------------------------------
+   Date: Tue, 1 Apr 1997 09:06:31 -0800 (PST)
+   From: coyote@desert.example.org
+   To: roadrunner@acme.example.com
+   Subject: I have a present for you
+
+   Look, I'm sorry about the whole anvil thing, and I really
+   didn't mean to try and drop it on you from the top of the
+   cliff.  I want to try to make it up to you.  I've got some
+   great birdseed over here at my place--top of the line
+
+
+
+
+Showalter                   Standards Track                     [Page 4]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   stuff--and if you come by, I'll have it all wrapped up
+   for you.  I'm really sorry for all the problems I've caused
+   for you over the years, but I know we can work this out.
+   --
+   Wile E. Coyote   "Super Genius"   coyote@desert.example.org
+   -----------------------------------------------------------
+
+   Message B
+   -----------------------------------------------------------
+   From: youcouldberich!@reply-by-postal-mail.invalid
+   Sender: b1ff@de.res.example.com
+   To: rube@landru.example.edu
+   Date:  Mon, 31 Mar 1997 18:26:10 -0800
+   Subject: $$$ YOU, TOO, CAN BE A MILLIONAIRE! $$$
+
+   YOU MAY HAVE ALREADY WON TEN MILLION DOLLARS, BUT I DOUBT
+   IT!  SO JUST POST THIS TO SIX HUNDRED NEWSGROUPS!  IT WILL
+   GUARANTEE THAT YOU GET AT LEAST FIVE RESPONSES WITH MONEY!
+   MONEY! MONEY! COLD HARD CASH!  YOU WILL RECEIVE OVER
+   $20,000 IN LESS THAN TWO MONTHS!  AND IT'S LEGAL!!!!!!!!!
+   !!!!!!!!!!!!!!!!!!111111111!!!!!!!11111111111!!1  JUST
+   SEND $5 IN SMALL, UNMARKED BILLS TO THE ADDRESSES BELOW!
+   -----------------------------------------------------------
+
+2.      Design
+
+2.1.     Form of the Language
+
+   The language consists of a set of commands.  Each command consists of
+   a set of tokens delimited by whitespace.  The command identifier is
+   the first token and it is followed by zero or more argument tokens.
+   Arguments may be literal data, tags, blocks of commands, or test
+   commands.
+
+   The language is represented in UTF-8, as specified in [UTF-8].
+
+   Tokens in the ASCII range are considered case-insensitive.
+
+2.2.     Whitespace
+
+   Whitespace is used to separate tokens.  Whitespace is made up of
+   tabs, newlines (CRLF, never just CR or LF), and the space character.
+   The amount of whitespace used is not significant.
+
+
+
+
+
+
+
+
+Showalter                   Standards Track                     [Page 5]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+2.3.     Comments
+
+   Two types of comments are offered.  Comments are semantically
+   equivalent to whitespace and can be used anyplace that whitespace is
+   (with one exception in multi-line strings, as described in the
+   grammar).
+
+   Hash comments begin with a "#" character that is not contained within
+   a string and continue until the next CRLF.
+
+   Example:  if size :over 100K { # this is a comment
+                discard;
+             }
+
+   Bracketed comments begin with the token "/*" and end with "*/" outside
+   of a string.  Bracketed comments may span multiple lines. Bracketed
+   comments do not nest.
+
+   Example:  if size :over 100K { /* this is a comment
+                this is still a comment */ discard /* this is a comment
+                */ ;
+             }
+
+2.4.     Literal Data
+
+   Literal data means data that is not executed, merely evaluated "as
+   is", to be used as arguments to commands.  Literal data is limited to
+   numbers and strings.
+
+2.4.1.   Numbers
+
+   Numbers are given as ordinary decimal numbers.  However, those
+   numbers that have a tendency to be fairly large, such as message
+   sizes, MAY have a "K", "M", or "G" appended to indicate a multiple of
+   a power of two.  To be comparable with the power-of-two-based
+   versions of SI units that computers frequently use, K specifies
+   kibi-, or 1,024 (2^10) times the value of the number; M specifies
+   mebi-, or 1,048,576 (2^20) times the value of the number; and G
+   specifies tebi-, or 1,073,741,824 (2^30) times the value of the
+   number [BINARY-SI].
+
+   Implementations MUST provide 31 bits of magnitude in numbers, but MAY
+   provide more.
+
+   Only positive integers are permitted by this specification.
+
+
+
+
+
+
+Showalter                   Standards Track                     [Page 6]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+2.4.2.   Strings
+
+   Scripts involve large numbers of strings as they are used for pattern
+   matching, addresses, textual bodies, etc.  Typically, short quoted
+   strings suffice for most uses, but a more convenient form is provided
+   for longer strings such as bodies of messages.
+
+   A quoted string starts and ends with a single double quote (the <">
+   character, ASCII 34).  A backslash ("\", ASCII 92) inside of a quoted
+   string is followed by either another backslash or a double quote.
+   This two-character sequence represents a single backslash or double-
+   quote within the string, respectively.
+
+   No other characters should be escaped with a single backslash.
+
+   An undefined escape sequence (such as "\a" in a context where "a" has
+   no special meaning) is interpreted as if there were no backslash (in
+   this case, "\a" is just "a").
+
+   Non-printing characters such as tabs, CR and LF, and control
+   characters are permitted in quoted strings.  Quoted strings MAY span
+   multiple lines.  NUL (ASCII 0) is not allowed in strings.
+
+   For entering larger amounts of text, such as an email message, a
+   multi-line form is allowed.  It starts with the keyword "text:",
+   followed by a CRLF, and ends with the sequence of a CRLF, a single
+   period, and another CRLF.  In order to allow the message to contain
+   lines with a single-dot, lines are dot-stuffed.  That is, when
+   composing a message body, an extra `.' is added before each line
+   which begins with a `.'.  When the server interprets the script,
+   these extra dots are removed.  Note that a line that begins with a
+   dot followed by a non-dot character is not interpreted dot-stuffed;
+   that is, ".foo" is interpreted as ".foo".  However, because this is
+   potentially ambiguous, scripts SHOULD be properly dot-stuffed so such
+   lines do not appear.
+
+   Note that a hashed comment or whitespace may occur in between the
+   "text:" and the CRLF, but not within the string itself.  Bracketed
+   comments are not allowed here.
+
+2.4.2.1. String Lists
+
+   When matching patterns, it is frequently convenient to match against
+   groups of strings instead of single strings.  For this reason, a list
+   of strings is allowed in many tests, implying that if the test is
+   true using any one of the strings, then the test is true.
+   Implementations are encouraged to use short-circuit evaluation in
+   these cases.
+
+
+
+Showalter                   Standards Track                     [Page 7]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   For instance, the test `header :contains ["To", "Cc"]
+   ["me@example.com", "me00@landru.example.edu"]' is true if either the
+   To header or Cc header of the input message contains either of the
+   e-mail addresses "me@example.com" or "me00@landru.example.edu".
+
+   Conversely, in any case where a list of strings is appropriate, a
+   single string is allowed without being a member of a list: it is
+   equivalent to a list with a single member.  This means that the test
+   `exists "To"' is equivalent to the test `exists ["To"]'.
+
+2.4.2.2. Headers
+
+   Headers are a subset of strings.  In the Internet Message
+   Specification [IMAIL] [RFC1123], each header line is allowed to have
+   whitespace nearly anywhere in the line, including after the field
+   name and before the subsequent colon.  Extra spaces between the
+   header name and the ":" in a header field are ignored.
+
+   A header name never contains a colon.  The "From" header refers to a
+   line beginning "From:" (or "From   :", etc.).  No header will match
+   the string "From:" due to the trailing colon.
+
+   Folding of long header lines (as described in [IMAIL] 3.4.8) is
+   removed prior to interpretation of the data.  The folding syntax (the
+   CRLF that ends a line plus any leading whitespace at the beginning of
+   the next line that indicates folding) are interpreted as if they were
+   a single space.
+
+2.4.2.3. Addresses
+
+   A number of commands call for email addresses, which are also a
+   subset of strings.  When these addresses are used in outbound
+   contexts, addresses must be compliant with [IMAIL], but are further
+   constrained.  Using the symbols defined in [IMAIL], section 6.1, the
+   syntax of an address is:
+
+   sieve-address = addr-spec                ; simple address
+                 / phrase "<" addr-spec ">" ; name & addr-spec
+
+   That is, routes and group syntax are not permitted.  If multiple
+   addresses are required, use a string list.  Named groups are not used
+   here.
+
+   Implementations MUST ensure that the addresses are syntactically
+   valid, but need not ensure that they actually identify an email
+   recipient.
+
+
+
+
+
+Showalter                   Standards Track                     [Page 8]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+2.4.2.4. MIME Parts
+
+   In a few places, [MIME] body parts are represented as strings.  These
+   parts include MIME headers and the body.  This provides a way of
+   embedding typed data within a Sieve script so that, among other
+   things, character sets other than UTF-8 can be used for output
+   messages.
+
+2.5.     Tests
+
+   Tests are given as arguments to commands in order to control their
+   actions.  In this document, tests are given to if/elsif/else to
+   decide which block of code is run.
+
+   Tests MUST NOT have side effects.  That is, a test cannot affect the
+   state of the filter or message.  No tests in this specification have
+   side effects, and side effects are forbidden in extension tests as
+   well.
+
+   The rationale for this is that tests with side effects impair
+   readability and maintainability and are difficult to represent in a
+   graphic interface for generating scripts.  Side effects are confined
+   to actions where they are clearer.
+
+2.5.1.   Test Lists
+
+   Some tests ("allof" and "anyof", which implement logical "and" and
+   logical "or", respectively) may require more than a single test as an
+   argument.  The test-list syntax element provides a way of grouping
+   tests.
+
+   Example:  if anyof (not exists ["From", "Date"],
+                   header :contains "from" "fool@example.edu") {
+                discard;
+             }
+
+2.6.     Arguments
+
+   In order to specify what to do, most commands take arguments.  There
+   are three types of arguments: positional, tagged, and optional.
+
+2.6.1.   Positional Arguments
+
+   Positional arguments are given to a command which discerns their
+   meaning based on their order.  When a command takes positional
+   arguments, all positional arguments must be supplied and must be in
+   the order prescribed.
+
+
+
+
+Showalter                   Standards Track                     [Page 9]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+2.6.2.   Tagged Arguments
+
+   This document provides for tagged arguments in the style of
+   CommonLISP.  These are also similar to flags given to commands in
+   most command-line systems.
+
+   A tagged argument is an argument for a command that begins with ":"
+   followed by a tag naming the argument, such as ":contains".  This
+   argument means that zero or more of the next tokens have some
+   particular meaning depending on the argument.  These next tokens may
+   be numbers or strings but they are never blocks.
+
+   Tagged arguments are similar to positional arguments, except that
+   instead of the meaning being derived from the command, it is derived
+   from the tag.
+
+   Tagged arguments must appear before positional arguments, but they
+   may appear in any order with other tagged arguments.  For simplicity
+   of the specification, this is not expressed in the syntax definitions
+   with commands, but they still may be reordered arbitrarily provided
+   they appear before positional arguments.  Tagged arguments may be
+   mixed with optional arguments.
+
+   To simplify this specification, tagged arguments SHOULD NOT take
+   tagged arguments as arguments.
+
+2.6.3.   Optional Arguments
+
+   Optional arguments are exactly like tagged arguments except that they
+   may be left out, in which case a default value is implied.  Because
+   optional arguments tend to result in shorter scripts, they have been
+   used far more than tagged arguments.
+
+   One particularly noteworthy case is the ":comparator" argument, which
+   allows the user to specify which [ACAP] comparator will be used to
+   compare two strings, since different languages may impose different
+   orderings on UTF-8 [UTF-8] characters.
+
+2.6.4.   Types of Arguments
+
+   Abstractly, arguments may be literal data, tests, or blocks of
+   commands.  In this way, an "if" control structure is merely a command
+   that happens to take a test and a block as arguments and may execute
+   the block of code.
+
+   However, this abstraction is ambiguous from a parsing standpoint.
+   The grammar in section 9.2 presents a parsable version of this:
+   Arguments are string-lists, numbers, and tags, which may be followed
+
+
+
+Showalter                   Standards Track                    [Page 10]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   by a test or a test-list, which may be followed by a block of
+   commands.  No more than one test or test list, nor more than one
+   block of commands, may be used, and commands that end with blocks of
+   commands do not end with semicolons.
+
+2.7.     String Comparison
+
+   When matching one string against another, there are a number of ways
+   of performing the match operation.  These are accomplished with three
+   types of matches: an exact match, a substring match, and a wildcard
+   glob-style match.  These are described below.
+
+   In order to provide for matches between character sets and case
+   insensitivity, Sieve borrows ACAP's comparator registry.
+
+   However, when a string represents the name of a header, the
+   comparator is never user-specified.  Header comparisons are always
+   done with the "i;ascii-casemap" operator, i.e., case-insensitive
+   comparisons, because this is the way things are defined in the
+   message specification [IMAIL].
+
+2.7.1.   Match Type
+
+   There are three match types describing the matching used in this
+   specification:  ":is", ":contains", and ":matches".  Match type
+   arguments are supplied to those commands which allow them to specify
+   what kind of match is to be performed.
+
+   These are used as tagged arguments to tests that perform string
+   comparison.
+
+   The ":contains" match type describes a substring match.  If the value
+   argument contains the key argument as a substring, the match is true.
+   For instance, the string "frobnitzm" contains "frob" and "nit", but
+   not "fbm".  The null key ("") is contained in all values.
+
+   The ":is" match type describes an absolute match; if the contents of
+   the first string are absolutely the same as the contents of the
+   second string, they match.  Only the string "frobnitzm" is the string
+   "frobnitzm".  The null key ":is" and only ":is" the null value.
+
+   The ":matches" version specifies a wildcard match using the
+   characters "*" and "?".  "*" matches zero or more characters, and "?"
+   matches a single character.  "?" and "*" may be escaped as "\\?" and
+   "\\*" in strings to match against themselves.  The first backslash
+   escapes the second backslash; together, they escape the "*".  This is
+   awkward, but it is commonplace in several programming languages that
+   use globs and regular expressions.
+
+
+
+Showalter                   Standards Track                    [Page 11]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   In order to specify what type of match is supposed to happen,
+   commands that support matching take optional tagged arguments
+   ":matches", ":is", and ":contains".  Commands default to using ":is"
+   matching if no match type argument is supplied.  Note that these
+   modifiers may interact with comparators; in particular, some
+   comparators are not suitable for matching with ":contains" or
+   ":matches".  It is an error to use a comparator with ":contains" or
+   ":matches" that is not compatible with it.
+
+   It is an error to give more than one of these arguments to a given
+   command.
+
+   For convenience, the "MATCH-TYPE" syntax element is defined  here  as
+   follows:
+
+   Syntax:   ":is" / ":contains" / ":matches"
+
+2.7.2.   Comparisons Across Character Sets
+
+   All Sieve scripts are represented in UTF-8, but messages may involve
+   a number of character sets.  In order for comparisons to work across
+   character sets, implementations SHOULD implement the following
+   behavior:
+
+      Implementations decode header charsets to UTF-8.  Two strings are
+      considered equal if their UTF-8 representations are identical.
+      Implementations should decode charsets represented in the forms
+      specified by [MIME] for both message headers and bodies.
+      Implementations must be capable of decoding US-ASCII, ISO-8859-1,
+      the ASCII subset of ISO-8859-* character sets, and UTF-8.
+
+   If implementations fail to support the above behavior, they MUST
+   conform to the following:
+
+      No two strings can be considered equal if one contains octets
+      greater than 127.
+
+2.7.3.   Comparators
+
+   In order to allow for language-independent, case-independent matches,
+   the match type may be coupled with a comparator name.  Comparators
+   are described for [ACAP]; a registry is defined for ACAP, and this
+   specification uses that registry.
+
+   ACAP defines multiple comparator types.  Only equality types are used
+   in this specification.
+
+
+
+
+
+Showalter                   Standards Track                    [Page 12]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   All implementations MUST support the "i;octet" comparator (simply
+   compares octets) and the "i;ascii-casemap" comparator (which treats
+   uppercase and lowercase characters in the ASCII subset of UTF-8 as
+   the same).  If left unspecified, the default is "i;ascii-casemap".
+
+   Some comparators may not be usable with substring matches; that is,
+   they may only work with ":is".  It is an error to try and use a
+   comparator with ":matches" or ":contains" that is not compatible with
+   it.
+
+   A comparator is specified by the ":comparator" option with commands
+   that support matching.  This option is followed by a string providing
+   the name of the comparator to be used.  For convenience, the syntax
+   of a comparator is abbreviated to "COMPARATOR", and (repeated in
+   several tests) is as follows:
+
+   Syntax:   ":comparator" <comparator-name: string>
+
+   So in this example,
+
+   Example:  if header :contains :comparator "i;octet" "Subject"
+                "MAKE MONEY FAST" {
+                   discard;
+             }
+
+   would discard any message with subjects like "You can MAKE MONEY
+   FAST", but not "You can Make Money Fast", since the comparator used
+   is case-sensitive.
+
+   Comparators other than i;octet and i;ascii-casemap must be declared
+   with require, as they are extensions.  If a comparator declared with
+   require is not known, it is an error, and execution fails.  If the
+   comparator is not declared with require, it is also an error, even if
+   the comparator is supported.  (See 2.10.5.)
+
+   Both ":matches" and ":contains" match types are compatible with the
+   "i;octet" and "i;ascii-casemap" comparators and may be used with
+   them.
+
+   It is an error to give more than one of these arguments to a given
+   command.
+
+2.7.4.   Comparisons Against Addresses
+
+   Addresses are one of the most frequent things represented as strings.
+   These are structured, and being able to compare against the local-
+   part or the domain of an address is useful, so some tests that act
+
+
+
+
+Showalter                   Standards Track                    [Page 13]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   exclusively on addresses take an additional optional argument that
+   specifies what the test acts on.
+
+   These optional arguments are ":localpart", ":domain", and ":all",
+   which act on the local-part (left-side), the domain part (right-
+   side), and the whole address.
+
+   The kind of comparison done, such as whether or not the test done is
+   case-insensitive, is specified as a comparator argument to the test.
+
+   If an optional address-part is omitted, the default is ":all".
+
+   It is an error to give more than one of these arguments to a given
+   command.
+
+   For convenience, the "ADDRESS-PART" syntax element is defined here as
+   follows:
+
+   Syntax:   ":localpart" / ":domain" / ":all"
+
+2.8.     Blocks
+
+   Blocks are sets of commands enclosed within curly braces.  Blocks are
+   supplied to commands so that the commands can implement control
+   commands.
+
+   A control structure is a command that happens to take a test and a
+   block as one of its arguments; depending on the result of the test
+   supplied as another argument, it runs the code in the block some
+   number of times.
+
+   With the commands supplied in this memo, there are no loops.  The
+   control structures supplied--if, elsif, and else--run a block either
+   once or not at all.  So there are two arguments, the test and the
+   block.
+
+2.9.     Commands
+
+   Sieve scripts are sequences of commands.  Commands can take any of
+   the tokens above as arguments, and arguments may be either tagged or
+   positional arguments.  Not all commands take all arguments.
+
+   There are three kinds of commands: test commands, action commands,
+   and control commands.
+
+   The simplest is an action command.  An action command is an
+   identifier followed by zero or more arguments, terminated by a
+   semicolon.  Action commands do not take tests or blocks as arguments.
+
+
+
+Showalter                   Standards Track                    [Page 14]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   A control command is similar, but it takes a test as an argument, and
+   ends with a block instead of a semicolon.
+
+   A test command is used as part of a control command.  It is used to
+   specify whether or not the block of code given to the control command
+   is executed.
+
+2.10.    Evaluation
+
+2.10.1.  Action Interaction
+
+   Some actions cannot be used with other actions because the result
+   would be absurd.  These restrictions are noted throughout this memo.
+
+   Extension actions MUST state how they interact with actions defined
+   in this specification.
+
+2.10.2.  Implicit Keep
+
+   Previous experience with filtering systems suggests that cases tend
+   to be missed in scripts.  To prevent errors, Sieve has an "implicit
+   keep".
+
+   An implicit keep is a keep action (see 4.4) performed in absence of
+   any action that cancels the implicit keep.
+
+   An implicit keep is performed if a message is not written to a
+   mailbox, redirected to a new address, or explicitly thrown out.  That
+   is, if a fileinto, a keep, a redirect, or a discard is performed, an
+   implicit keep is not.
+
+   Some actions may be defined to not cancel the implicit keep.  These
+   actions may not directly affect the delivery of a message, and are
+   used for their side effects.  None of the actions specified in this
+   document meet that criteria, but extension actions will.
+
+   For instance, with any of the short messages offered above, the
+   following script produces no actions.
+
+   Example:  if size :over 500K { discard; }
+
+   As a result, the implicit keep is taken.
+
+2.10.3.  Message Uniqueness in a Mailbox
+
+   Implementations SHOULD NOT deliver a message to the same folder more
+   than once, even if a script explicitly asks for a message to be
+   written to a mailbox twice.
+
+
+
+Showalter                   Standards Track                    [Page 15]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   The test for equality of two messages is implementation-defined.
+
+   If a script asks for a message to be written to a mailbox twice, it
+   MUST NOT be treated as an error.
+
+2.10.4.  Limits on Numbers of Actions
+
+   Site policy MAY limit numbers of actions taken and MAY impose
+   restrictions on which actions can be used together.  In the event
+   that a script hits a policy limit on the number of actions taken for
+   a particular message, an error occurs.
+
+   Implementations MUST prohibit more than one reject.
+
+   Implementations MUST allow at least one keep or one fileinto.  If
+   fileinto is not implemented, implementations MUST allow at least one
+   keep.
+
+   Implementations SHOULD prohibit reject when used with other actions.
+
+2.10.5.  Extensions and Optional Features
+
+   Because of the differing capabilities of many mail systems, several
+   features of this specification are optional.  Before any of these
+   extensions can be executed, they must be declared with the "require"
+   action.
+
+   If an extension is not enabled with "require", implementations MUST
+   treat it as if they did not support it at all.
+
+   If a script does not understand an extension declared with require,
+   the script must not be used at all.  Implementations MUST NOT execute
+   scripts which require unknown capability names.
+
+   Note: The reason for this restriction is that prior experiences with
+         languages such as LISP and Tcl suggest that this is a workable
+         way of noting that a given script uses an extension.
+
+         Experience with PostScript suggests that mechanisms that allow
+         a script to work around missing extensions are not used in
+         practice.
+
+   Extensions which define actions MUST state how they interact with
+   actions discussed in the base specification.
+
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 16]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+2.10.6.  Errors
+
+   In any programming language, there are compile-time and run-time
+   errors.
+
+   Compile-time errors are ones in syntax that are detectable if a
+   syntax check is done.
+
+   Run-time errors are not detectable until the script is run.  This
+   includes transient failures like disk full conditions, but also
+   includes issues like invalid combinations of actions.
+
+   When an error occurs in a Sieve script, all processing stops.
+
+   Implementations MAY choose to do a full parse, then evaluate the
+   script, then do all actions.  Implementations might even go so far as
+   to ensure that execution is atomic (either all actions are executed
+   or none are executed).
+
+   Other implementations may choose to parse and run at the same time.
+   Such implementations are simpler, but have issues with partial
+   failure (some actions happen, others don't).
+
+   Implementations might even go so far as to ensure that scripts can
+   never execute an invalid set of actions (e.g., reject + fileinto)
+   before execution, although this could involve solving the Halting
+   Problem.
+
+   This specification allows any of these approaches.  Solving the
+   Halting Problem is considered extra credit.
+
+   When an error happens, implementations MUST notify the user that an
+   error occurred, which actions (if any) were taken, and do an implicit
+   keep.
+
+2.10.7.  Limits on Execution
+
+   Implementations may limit certain constructs.  However, this
+   specification places a lower bound on some of these limits.
+
+   Implementations MUST support fifteen levels of nested blocks.
+
+   Implementations MUST support fifteen levels of nested test lists.
+
+3.      Control Commands
+
+   Control structures are needed to allow for multiple and conditional
+   actions.
+
+
+
+Showalter                   Standards Track                    [Page 17]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+3.1.     Control Structure If
+
+   There are three pieces to if: "if", "elsif", and "else".  Each is
+   actually a separate command in terms of the grammar.  However, an
+   elsif MUST only follow an if, and an else MUST follow only either an
+   if or an elsif.  An error occurs if these conditions are not met.
+
+   Syntax:   if <test1: test> <block1: block>
+
+   Syntax:   elsif <test2: test> <block2: block>
+
+   Syntax:   else <block>
+
+   The semantics are similar to those of any of the many other
+   programming languages these control commands appear in.  When the
+   interpreter sees an "if", it evaluates the test associated with it.
+   If the test is true, it executes the block associated with it.
+
+   If the test of the "if" is false, it evaluates the test of the first
+   "elsif" (if any).  If the test of "elsif" is true, it runs the
+   elsif's block.  An elsif may be followed by an elsif, in which case,
+   the interpreter repeats this process until it runs out of elsifs.
+
+   When the interpreter runs out of elsifs, there may be an "else" case.
+   If there is, and none of the if or elsif tests were true, the
+   interpreter runs the else case.
+
+   This provides a way of performing exactly one of the blocks in the
+   chain.
+
+   In the following example, both Message A and B are dropped.
+
+   Example:  require "fileinto";
+             if header :contains "from" "coyote" {
+                discard;
+             } elsif header :contains ["subject"] ["$$$"] {
+                discard;
+             } else {
+                fileinto "INBOX";
+             }
+
+
+   When the script below is run over message A, it redirects the message
+   to  acm@example.edu;  message B, to postmaster@example.edu; any other
+   message is redirected to field@example.edu.
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 18]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   Example:  if header :contains ["From"] ["coyote"] {
+                redirect "acm@example.edu";
+             } elsif header :contains "Subject" "$$$" {
+                redirect "postmaster@example.edu";
+             } else {
+                redirect "field@example.edu";
+             }
+
+   Note that this definition prohibits the "... else if ..." sequence
+   used by C.  This is intentional, because this construct produces a
+   shift-reduce conflict.
+
+3.2.     Control Structure Require
+
+   Syntax:   require <capabilities: string-list>
+
+   The require action notes that a script makes use of a certain
+   extension.  Such a declaration is required to use the extension, as
+   discussed in section 2.10.5.  Multiple capabilities can be declared
+   with a single require.
+
+   The require command, if present, MUST be used before anything other
+   than a require can be used.  An error occurs if a require appears
+   after a command other than require.
+
+   Example:  require ["fileinto", "reject"];
+
+   Example:  require "fileinto";
+             require "vacation";
+
+3.3.     Control Structure Stop
+
+   Syntax:   stop
+
+   The "stop" action ends all processing.  If no actions have been
+   executed, then the keep action is taken.
+
+4.      Action Commands
+
+   This document supplies five actions that may be taken on a message:
+   keep, fileinto, redirect, reject, and discard.
+
+   Implementations MUST support the "keep", "discard", and "redirect"
+   actions.
+
+   Implementations SHOULD support "reject" and "fileinto".
+
+
+
+
+
+Showalter                   Standards Track                    [Page 19]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   Implementations MAY limit the number of certain actions taken (see
+   section 2.10.4).
+
+4.1.     Action reject
+
+   Syntax:   reject <reason: string>
+
+   The optional "reject" action refuses delivery of a message by sending
+   back an [MDN] to the sender.  It resends the message to the sender,
+   wrapping it in a "reject" form, noting that it was rejected by the
+   recipient.  In the following script, message A is rejected and
+   returned to the sender.
+
+   Example:  if header :contains "from" "coyote@desert.example.org" {
+                reject "I am not taking mail from you, and I don't want
+                your birdseed, either!";
+             }
+
+   A reject message MUST take the form of a failure MDN as specified  by
+   [MDN].    The  human-readable  portion  of  the  message,  the  first
+   component of the MDN, contains the human readable message  describing
+   the  error,  and  it  SHOULD  contain  additional  text  alerting the
+   original sender that mail was refused by a filter.  This part of  the
+   MDN might appear as follows:
+
+   ------------------------------------------------------------
+   Message was refused by recipient's mail filtering program.  Reason
+   given was as follows:
+
+   I am not taking mail from you, and I don't want your birdseed,
+   either!
+   ------------------------------------------------------------
+
+   The MDN action-value field as defined in the MDN specification MUST
+   be "deleted" and MUST have the MDN-sent-automatically and automatic-
+   action modes set.
+
+   Because some implementations can not or will not implement the reject
+   command, it is optional.  The capability string to be used with the
+   require command is "reject".
+
+4.2.     Action fileinto
+
+   Syntax:   fileinto <folder: string>
+
+   The "fileinto" action delivers the message into the specified folder.
+   Implementations SHOULD support fileinto, but in some environments
+   this may be impossible.
+
+
+
+Showalter                   Standards Track                    [Page 20]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   The capability string for use with the require command is "fileinto".
+
+   In the following script, message A is filed into folder
+   "INBOX.harassment".
+
+   Example:  require "fileinto";
+             if header :contains ["from"] "coyote" {
+                fileinto "INBOX.harassment";
+             }
+
+4.3.     Action redirect
+
+   Syntax:   redirect <address: string>
+
+   The "redirect" action is used to send the message to another user at
+   a supplied address, as a mail forwarding feature does.  The
+   "redirect" action makes no changes to the message body or existing
+   headers, but it may add new headers.  The "redirect" modifies the
+   envelope recipient.
+
+   The redirect command performs an MTA-style "forward"--that is, what
+   you get from a .forward file using sendmail under UNIX.  The address
+   on the SMTP envelope is replaced with the one on the redirect command
+   and the message is sent back out.  (This is not an MUA-style forward,
+   which creates a new message with a different sender and message ID,
+   wrapping the old message in a new one.)
+
+   A simple script can be used for redirecting all mail:
+
+   Example:  redirect "bart@example.edu";
+
+   Implementations SHOULD take measures to implement loop control,
+   possibly including adding headers to the message or counting received
+   headers.  If an implementation detects a loop, it causes an error.
+
+4.4.     Action keep
+
+   Syntax:   keep
+
+   The "keep" action is whatever action is taken in lieu of all other
+   actions, if no filtering happens at all; generally, this simply means
+   to file the message into the user's main mailbox.  This command
+   provides a way to execute this action without needing to know the
+   name of the user's main mailbox, providing a way to call it without
+   needing to understand the user's setup, or the underlying mail
+   system.
+
+
+
+
+
+Showalter                   Standards Track                    [Page 21]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   For instance, in an implementation where the IMAP server is running
+   scripts on behalf of the user at time of delivery, a keep command is
+   equivalent to a fileinto "INBOX".
+
+   Example:  if size :under 1M { keep; } else { discard; }
+
+   Note that the above script is identical to the one below.
+
+   Example:  if not size :under 1M { discard; }
+
+4.5.     Action discard
+
+   Syntax:   discard
+
+   Discard is used to silently throw away the message.  It does so by
+   simply canceling the implicit keep.  If discard is used with other
+   actions, the other actions still happen.  Discard is compatible with
+   all other actions.  (For instance fileinto+discard is equivalent to
+   fileinto.)
+
+   Discard MUST be silent; that is, it MUST NOT return a non-delivery
+   notification of any kind ([DSN], [MDN], or otherwise).
+
+   In the following script, any mail from "idiot@example.edu" is thrown
+   out.
+
+   Example:  if header :contains ["from"] ["idiot@example.edu"] {
+                discard;
+             }
+
+   While an important part of this language, "discard" has the potential
+   to create serious problems for users: Students who leave themselves
+   logged in to an unattended machine in a public computer lab may find
+   their script changed to just "discard".  In order to protect users in
+   this situation (along with similar situations), implementations MAY
+   keep messages destroyed by a script for an indefinite period, and MAY
+   disallow scripts that throw out all mail.
+
+5.      Test Commands
+
+   Tests are used in conditionals to decide which part(s) of the
+   conditional to execute.
+
+   Implementations MUST support these tests: "address", "allof",
+   "anyof", "exists", "false", "header", "not", "size", and "true".
+
+   Implementations SHOULD support the "envelope" test.
+
+
+
+
+Showalter                   Standards Track                    [Page 22]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+5.1.     Test address
+
+   Syntax:   address [ADDRESS-PART] [COMPARATOR] [MATCH-TYPE]
+             <header-list: string-list> <key-list: string-list>
+
+   The address test matches Internet addresses in structured headers
+   that contain addresses.  It returns true if any header contains any
+   key in the specified part of the address, as modified by the
+   comparator and the match keyword.
+
+   Like envelope and header, this test returns true if any combination
+   of the header-list and key-list arguments match.
+
+   Internet email addresses [IMAIL] have the somewhat awkward
+   characteristic that the local-part to the left of the at-sign is
+   considered case sensitive, and the domain-part to the right of the
+   at-sign is case insensitive.  The "address" command does not deal
+   with this itself, but provides the ADDRESS-PART argument for allowing
+   users to deal with it.
+
+   The address primitive never acts on the phrase part of an email
+   address, nor on comments within that address.  It also never acts on
+   group names, although it does act on the addresses within the group
+   construct.
+
+   Implementations MUST restrict the address test to headers that
+   contain addresses, but MUST include at least From, To, Cc, Bcc,
+   Sender, Resent-From, Resent-To, and SHOULD include any other header
+   that utilizes an "address-list" structured header body.
+
+   Example:  if address :is :all "from" "tim@example.com" {
+                discard;
+
+5.2.     Test allof
+
+   Syntax:   allof <tests: test-list>
+
+   The allof test performs a logical AND on the tests supplied to it.
+
+   Example:  allof (false, false)  =>   false
+             allof (false, true)   =>   false
+             allof (true,  true)   =>   true
+
+   The allof test takes as its argument a test-list.
+
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 23]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+5.3.     Test anyof
+
+   Syntax:   anyof <tests: test-list>
+
+   The anyof test performs a logical OR on the tests supplied to it.
+
+   Example:  anyof (false, false)  =>   false
+             anyof (false, true)   =>   true
+             anyof (true,  true)   =>   true
+
+5.4.     Test envelope
+
+   Syntax:   envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
+             <envelope-part: string-list> <key-list: string-list>
+
+   The "envelope" test is true if the specified part of the SMTP (or
+   equivalent) envelope matches the specified key.
+
+   If one of the envelope-part strings is (case insensitive) "from",
+   then matching occurs against the FROM address used in the SMTP MAIL
+   command.
+
+   If one of the envelope-part strings is (case insensitive) "to", then
+   matching occurs against the TO address used in the SMTP RCPT command
+   that resulted in this message getting delivered to this user.  Note
+   that only the most recent TO is available, and only the one relevant
+   to this user.
+
+   The envelope-part is a string list and may contain more than one
+   parameter, in which case all of the strings specified in the key-list
+   are matched against all parts given in the envelope-part list.
+
+   Like address and header, this test returns true if any combination of
+   the envelope-part and key-list arguments is true.
+
+   All tests against envelopes MUST drop source routes.
+
+   If the SMTP transaction involved several RCPT commands, only the data
+   from the RCPT command that caused delivery to this user is available
+   in the "to" part of the envelope.
+
+   If a protocol other than SMTP is used for message transport,
+   implementations are expected to adapt this command appropriately.
+
+   The envelope command is optional.  Implementations SHOULD support it,
+   but the necessary information may not be available in all cases.
+
+
+
+
+
+Showalter                   Standards Track                    [Page 24]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   Example:  require "envelope";
+             if envelope :all :is "from" "tim@example.com" {
+                discard;
+             }
+
+5.5.     Test exists
+
+   Syntax:   exists <header-names: string-list>
+
+   The "exists" test is true if the headers listed in the header-names
+   argument exist within the message.  All of the headers must exist or
+   the test is false.
+
+   The following example throws out mail that doesn't have a From header
+   and a Date header.
+
+   Example:  if not exists ["From","Date"] {
+                discard;
+             }
+
+5.6.     Test false
+
+   Syntax:   false
+
+   The "false" test always evaluates to false.
+
+5.7.     Test header
+
+   Syntax:   header [COMPARATOR] [MATCH-TYPE]
+             <header-names: string-list> <key-list: string-list>
+
+   The "header" test evaluates to true if any header name matches any
+   key.  The type of match is specified by the optional match argument,
+   which defaults to ":is" if not specified, as specified in section
+   2.6.
+
+   Like address and envelope, this test returns true if any combination
+   of the string-list and key-list arguments match.
+
+   If a header listed in the header-names argument exists, it contains
+   the null key ("").  However, if the named header is not present, it
+   does not contain the null key.  So if a message contained the header
+
+           X-Caffeine: C8H10N4O2
+
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 25]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   these tests on that header evaluate as follows:
+
+           header :is ["X-Caffeine"] [""]         => false
+           header :contains ["X-Caffeine"] [""]   => true
+
+5.8.     Test not
+
+   Syntax:   not <test>
+
+   The "not" test takes some other test as an argument, and yields the
+   opposite result.  "not false" evaluates to "true" and "not true"
+   evaluates to "false".
+
+5.9.     Test size
+
+   Syntax:   size <":over" / ":under"> <limit: number>
+
+   The "size" test deals with the size of a message.  It takes either a
+   tagged argument of ":over" or ":under", followed by a number
+   representing the size of the message.
+
+   If the argument is ":over", and the size of the message is greater
+   than the number provided, the test is true; otherwise, it is false.
+
+   If the argument is ":under", and the size of the message is less than
+   the number provided, the test is true; otherwise, it is false.
+
+   Exactly one of ":over" or ":under" must be specified, and anything
+   else is an error.
+
+   The size of a message is defined to be the number of octets from the
+   initial header until the last character in the message body.
+
+   Note that for a message that is exactly 4,000 octets, the message is
+   neither ":over" 4000 octets or ":under" 4000 octets.
+
+5.10.    Test true
+
+   Syntax:   true
+
+   The "true" test always evaluates to true.
+
+6.      Extensibility
+
+   New control structures, actions, and tests can be added to the
+   language.  Sites must make these features known to their users; this
+   document does not define a way to discover the list of extensions
+   supported by the server.
+
+
+
+Showalter                   Standards Track                    [Page 26]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   Any extensions to this language MUST define a capability string that
+   uniquely identifies that extension.  If a new version of an extension
+   changes the functionality of a previously defined extension, it MUST
+   use a different name.
+
+   In a situation where there is a submission protocol and an extension
+   advertisement mechanism aware of the details of this language,
+   scripts submitted can be checked against the mail server to prevent
+   use of an extension that the server does not support.
+
+   Extensions MUST state how they interact with constraints defined in
+   section 2.10, e.g., whether they cancel the implicit keep, and which
+   actions they are compatible and incompatible with.
+
+6.1.     Capability String
+
+   Capability strings are typically short strings describing what
+   capabilities are supported by the server.
+
+   Capability strings beginning with "vnd." represent vendor-defined
+   extensions.  Such extensions are not defined by Internet standards or
+   RFCs, but are still registered with IANA in order to prevent
+   conflicts.  Extensions starting with "vnd." SHOULD be followed by the
+   name of the vendor and product, such as "vnd.acme.rocket-sled".
+
+   The following capability strings are defined by this document:
+
+   envelope    The string "envelope" indicates that the implementation
+               supports the "envelope" command.
+
+   fileinto    The string "fileinto" indicates that the implementation
+               supports the "fileinto" command.
+
+   reject      The string "reject" indicates that the implementation
+               supports the "reject" command.
+
+   comparator- The string "comparator-elbonia" is provided if the
+               implementation supports the "elbonia" comparator.
+               Therefore, all implementations have at least the
+               "comparator-i;octet" and "comparator-i;ascii-casemap"
+               capabilities.  However, these comparators may be used
+               without being declared with require.
+
+
+
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 27]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+6.2.     IANA Considerations
+
+   In order to provide a standard set of extensions, a registry is
+   provided by IANA.  Capability names may be registered on a first-
+   come, first-served basis.  Extensions designed for interoperable use
+   SHOULD be defined as standards track or IESG approved experimental
+   RFCs.
+
+6.2.1.     Template for Capability Registrations
+
+   The following template is to be used for registering new Sieve
+   extensions with IANA.
+
+   To: iana@iana.org
+   Subject: Registration of new Sieve extension
+
+   Capability name:
+   Capability keyword:
+   Capability arguments:
+   Standards Track/IESG-approved experimental RFC number:
+   Person and email address to contact for further information:
+
+6.2.2.     Initial Capability Registrations
+
+   The following are to be added to the IANA registry for Sieve
+   extensions as the initial contents of the capability registry.
+
+   Capability name:        fileinto
+   Capability keyword:     fileinto
+   Capability arguments:   fileinto <folder: string>
+   Standards Track/IESG-approved experimental RFC number:
+           RFC 3028 (Sieve base spec)
+   Person and email address to contact for further information:
+           Tim Showalter
+           tjs@mirapoint.com
+
+   Capability name:        reject
+   Capability keyword:     reject
+   Capability arguments:   reject <reason: string>
+   Standards Track/IESG-approved experimental RFC number:
+           RFC 3028 (Sieve base spec)
+   Person and email address to contact for further information:
+           Tim Showalter
+           tjs@mirapoint.com
+
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 28]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   Capability name:        envelope
+   Capability keyword:     envelope
+   Capability arguments:
+           envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
+           <envelope-part: string-list> <key-list: string-list>
+   Standards Track/IESG-approved experimental RFC number:
+           RFC 3028 (Sieve base spec)
+   Person and email address to contact for further information:
+           Tim Showalter
+           tjs@mirapoint.com
+
+   Capability name:        comparator-*
+   Capability keyword:
+           comparator-* (anything starting with "comparator-")
+   Capability arguments:   (none)
+   Standards Track/IESG-approved experimental RFC number:
+           RFC 3028, Sieve, by reference of
+           RFC 2244, Application Configuration Access Protocol
+   Person and email address to contact for further information:
+           Tim Showalter
+           tjs@mirapoint.com
+
+6.3.     Capability Transport
+
+   As the range of mail systems that this document is intended to apply
+   to is quite varied, a method of advertising which capabilities an
+   implementation supports is difficult due to the wide range of
+   possible implementations.  Such a mechanism, however, should have
+   property that the implementation can advertise the complete set of
+   extensions that it supports.
+
+7.      Transmission
+
+   The MIME type for a Sieve script is "application/sieve".
+
+   The registration of this type for RFC 2048 requirements is as
+   follows:
+
+    Subject: Registration of MIME media type application/sieve
+
+    MIME media type name: application
+    MIME subtype name: sieve
+    Required parameters: none
+    Optional parameters: none
+    Encoding considerations: Most sieve scripts will be textual,
+       written in UTF-8.  When non-7bit characters are used,
+       quoted-printable is appropriate for transport systems
+       that require 7bit encoding.
+
+
+
+Showalter                   Standards Track                    [Page 29]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+    Security considerations: Discussed in section 10 of RFC 3028.
+    Interoperability considerations: Discussed in section 2.10.5
+       of RFC 3028.
+    Published specification: RFC 3028.
+    Applications which use this media type: sieve-enabled mail servers
+    Additional information:
+      Magic number(s):
+      File extension(s): .siv
+      Macintosh File Type Code(s):
+    Person & email address to contact for further information:
+       See the discussion list at ietf-mta-filters@imc.org.
+    Intended usage:
+       COMMON
+    Author/Change controller:
+       See Author information in RFC 3028.
+
+8.      Parsing
+
+   The Sieve grammar is separated into tokens and a separate grammar as
+   most programming languages are.
+
+8.1.     Lexical Tokens
+
+   Sieve scripts are encoded in UTF-8.  The following assumes a valid
+   UTF-8 encoding; special characters in Sieve scripts are all ASCII.
+
+   The following are tokens in Sieve:
+
+           - identifiers
+           - tags
+           - numbers
+           - quoted strings
+           - multi-line strings
+           - other separators
+
+   Blanks, horizontal tabs, CRLFs, and comments ("white space") are
+   ignored except as they separate tokens.  Some white space is required
+   to separate otherwise adjacent tokens and in specific places in the
+   multi-line strings.
+
+   The other separators are single individual characters, and are
+   mentioned explicitly in the grammar.
+
+   The lexical structure of sieve is defined in the following BNF (as
+   described in [ABNF]):
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 30]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   bracket-comment = "/*" *(CHAR-NOT-STAR / ("*" CHAR-NOT-SLASH)) "*/"
+           ;; No */ allowed inside a comment.
+           ;; (No * is allowed unless it is the last character,
+           ;; or unless it is followed by a character that isn't a
+           ;; slash.)
+
+   CHAR-NOT-DOT = (%x01-09 / %x0b-0c / %x0e-2d / %x2f-ff)
+           ;; no dots, no CRLFs
+
+   CHAR-NOT-CRLF = (%x01-09 / %x0b-0c / %x0e-ff)
+
+   CHAR-NOT-SLASH = (%x00-57 / %x58-ff)
+
+   CHAR-NOT-STAR = (%x00-51 / %x53-ff)
+
+   comment = bracket-comment / hash-comment
+
+   hash-comment = ( "#" *CHAR-NOT-CRLF CRLF )
+
+   identifier = (ALPHA / "_") *(ALPHA DIGIT "_")
+
+   tag = ":" identifier
+
+   number = 1*DIGIT [QUANTIFIER]
+
+   QUANTIFIER = "K" / "M" / "G"
+
+   quoted-string = DQUOTE *CHAR DQUOTE
+           ;; in general, \ CHAR inside a string maps to CHAR
+           ;; so \" maps to " and \\ maps to \
+           ;; note that newlines and other characters are all allowed
+           ;; strings
+
+   multi-line          = "text:" *(SP / HTAB) (hash-comment / CRLF)
+                         *(multi-line-literal / multi-line-dotstuff)
+                         "." CRLF
+   multi-line-literal  = [CHAR-NOT-DOT *CHAR-NOT-CRLF] CRLF
+   multi-line-dotstuff = "." 1*CHAR-NOT-CRLF CRLF
+           ;; A line containing only "." ends the multi-line.
+           ;; Remove a leading '.' if followed by another '.'.
+
+   white-space = 1*(SP / CRLF / HTAB) / comment
+
+8.2.     Grammar
+
+   The following is the grammar of Sieve after it has been lexically
+   interpreted.  No white space or comments appear below.  The start
+   symbol is "start".
+
+
+
+Showalter                   Standards Track                    [Page 31]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   argument = string-list / number / tag
+
+   arguments = *argument [test / test-list]
+
+   block = "{" commands "}"
+
+   command = identifier arguments ( ";" / block )
+
+   commands = *command
+
+   start = commands
+
+   string = quoted-string / multi-line
+
+   string-list = "[" string *("," string) "]" / string         ;; if
+   there is only a single string, the brackets are optional
+
+   test = identifier arguments
+
+   test-list = "(" test *("," test) ")"
+
+9.      Extended Example
+
+   The following is an extended example of a Sieve script.  Note that it
+   does not make use of the implicit keep.
+
+    #
+    # Example Sieve Filter
+    # Declare any optional features or extension used by the script
+    #
+    require ["fileinto", "reject"];
+
+    #
+    # Reject any large messages (note that the four leading dots get
+    # "stuffed" to three)
+    #
+    if size :over 1M
+            {
+            reject text:
+    Please do not send me large attachments.
+    Put your file on a server and send me the URL.
+    Thank you.
+    .... Fred
+    .
+    ;
+            stop;
+            }
+    #
+
+
+
+Showalter                   Standards Track                    [Page 32]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+    # Handle messages from known mailing lists
+    # Move messages from IETF filter discussion list to filter folder
+    #
+    if header :is "Sender" "owner-ietf-mta-filters@imc.org"
+            {
+            fileinto "filter";  # move to "filter" folder
+            }
+    #
+    # Keep all messages to or from people in my company
+    #
+    elsif address :domain :is ["From", "To"] "example.com"
+            {
+            keep;               # keep in "In" folder
+            }
+
+    #
+    # Try and catch unsolicited email.  If a message is not to me,
+    # or it contains a subject known to be spam, file it away.
+    #
+    elsif anyof (not address :all :contains
+                   ["To", "Cc", "Bcc"] "me@example.com",
+                 header :matches "subject"
+                   ["*make*money*fast*", "*university*dipl*mas*"])
+            {
+            # If message header does not contain my address,
+            # it's from a list.
+            fileinto "spam";   # move to "spam" folder
+            }
+    else
+            {
+            # Move all other (non-company) mail to "personal"
+            # folder.
+            fileinto "personal";
+            }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 33]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+10.     Security Considerations
+
+   Users must get their mail.  It is imperative that whatever method
+   implementations use to store the user-defined filtering scripts be
+   secure.
+
+   It is equally important that implementations sanity-check the user's
+   scripts, and not allow users to create on-demand mailbombs.  For
+   instance, an implementation that allows a user to reject or redirect
+   multiple times to a single message might also allow a user to create
+   a mailbomb triggered by mail from a specific user.  Site- or
+   implementation-defined limits on actions are useful for this.
+
+   Several commands, such as "discard", "redirect", and "fileinto" allow
+   for actions to be taken that are potentially very dangerous.
+
+   Implementations SHOULD take measures to prevent languages from
+   looping.
+
+11.     Acknowledgments
+
+   I am very thankful to Chris Newman for his support and his ABNF
+   syntax checker, to John Myers and Steve Hole for outlining the
+   requirements for the original drafts, to Larry Greenfield for nagging
+   me about the grammar and finally fixing it, to Greg Sereda for
+   repeatedly fixing and providing examples, to Ned Freed for fixing
+   everything else, to Rob Earhart for an early implementation and a
+   great deal of help, and to Randall Gellens for endless amounts of
+   proofreading.  I am grateful to Carnegie Mellon University where most
+   of the work on this document was done.  I am also indebted to all of
+   the readers of the ietf-mta-filters@imc.org mailing list.
+
+12.     Author's Address
+
+   Tim Showalter
+   Mirapoint, Inc.
+   909 Hermosa Court
+   Sunnyvale, CA 94085
+
+   EMail: tjs@mirapoint.com
+
+13.  References
+
+   [ABNF]      Crocker, D. and P. Overell, "Augmented BNF for Syntax
+               Specifications: ABNF", RFC 2234, November 1997.
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 34]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   [ACAP]      Newman, C. and J. G. Myers, "ACAP -- Application
+               Configuration Access Protocol", RFC 2244, November 1997.
+
+   [BINARY-SI] "Standard IEC 60027-2: Letter symbols to be used in
+               electrical technology - Part 2: Telecommunications and
+               electronics", January 1999.
+
+   [DSN]       Moore, K. and G. Vaudreuil, "An Extensible Message Format
+               for Delivery Status Notifications", RFC 1894, January
+               1996.
+
+   [FLAMES]    Borenstein, N, and C. Thyberg, "Power, Ease of Use, and
+               Cooperative Work in a Practical Multimedia Message
+               System", Int. J.  of Man-Machine Studies, April, 1991.
+               Reprinted in Computer-Supported Cooperative Work and
+               Groupware, Saul Greenberg, editor, Harcourt Brace
+               Jovanovich, 1991.  Reprinted in Readings in Groupware and
+               Computer-Supported Cooperative Work, Ronald Baecker,
+               editor, Morgan Kaufmann, 1993.
+
+   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [IMAP]      Crispin, M., "Internet Message Access Protocol - version
+               4rev1", RFC 2060, December 1996.
+
+   [IMAIL]     Crocker, D., "Standard for the Format of ARPA Internet
+               Text Messages", STD 11, RFC 822, August 1982.
+
+   [MIME]      Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [MDN]       Fajman, R., "An Extensible Message Format for Message
+               Disposition Notifications", RFC 2298, March 1998.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts --
+               Application and Support", STD 3, RFC 1123, November 1989.
+
+   [SMTP]      Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+               821, August 1982.
+
+   [UTF-8]     Yergeau, F., "UTF-8, a transformation format of Unicode
+               and ISO 10646", RFC 2044, October 1996.
+
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 35]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+14. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 36]
+
diff --git a/docs/rfcs/rfc3348.txt b/docs/rfcs/rfc3348.txt
new file mode 100644
index 0000000..500871c
--- /dev/null
+++ b/docs/rfcs/rfc3348.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                          M. Gahrns
+Request for Comments: 3348                                      R. Cheng
+Category: Informational                                        Microsoft
+                                                               July 2002
+
+
+             The Internet Message Action Protocol (IMAP4)
+                        Child Mailbox Extension
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   The Internet Message Action Protocol (IMAP4) CHILDREN extension
+   provides a mechanism for a client to efficiently determine if a
+   particular mailbox has children, without issuing a LIST "" * or a
+   LIST "" % for each mailbox.
+
+1. Conventions used in this document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.  If such lines are wrapped without a new "C:" or
+   "S:" label, then the wrapping is for editorial clarity and is not
+   part of the command.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC-2119].
+
+2. Introduction and Overview
+
+   Many IMAP4 [RFC-2060] clients present to the user a hierarchical view
+   of the mailboxes that a user has access to.  Rather than initially
+   presenting to the user the entire mailbox hierarchy, it is often
+   preferable to show to the user a collapsed outline list of the
+   mailbox hierarchy (particularly if there is a large number of
+   mailboxes).  The user can then expand the collapsed outline hierarchy
+   as needed.  It is common to include within the collapsed hierarchy a
+
+
+
+
+
+Gahrns, et al.               Informational                      [Page 1]
+
+RFC 3348             IMAP4 Child Mailbox Extension             July 2002
+
+
+   visual clue (such as a "+") to indicate that there are child
+   mailboxes under a particular mailbox.  When the visual clue is
+   clicked the hierarchy list is expanded to show the child mailboxes.
+
+   Several IMAP vendors implemented this proposal, and it is proposed to
+   document this behavior and functionality as an Informational RFC.
+
+   There is interest in addressing the general extensibility of the IMAP
+   LIST command through an IMAP LIST Extension draft.  Similar
+   functionality to the \HasChildren and \HasNoChildren flags could be
+   incorporated into this new LIST Extension.  It is proposed that the
+   more general LIST Extension draft proceed on the standards track with
+   this proposal being relegated to informational status only.
+
+   If the functionality of the \HasChildren and \HasNoChildren flags
+   were incorporated into a more general LIST extension, this would have
+   the advantage that a client could then have the opportunity to
+   request whether or not the server should return this information.
+   This would be an advantage over the current draft for servers where
+   this information is expensive to compute, since the server would only
+   need to compute the information when it knew that the client
+   requesting the information was able to consume it.
+
+3. Requirements
+
+   IMAP4 servers that support this extension MUST list the keyword
+   CHILDREN in their CAPABILITY response.
+
+   The CHILDREN extension defines two new attributes that MAY be
+   returned within a LIST response.
+
+   \HasChildren - The presence of this attribute indicates that the
+   mailbox has child mailboxes.
+
+   Servers SHOULD NOT return \HasChildren if child mailboxes exist, but
+   none will be displayed to the current user in a LIST response (as
+   should be the case where child mailboxes exist, but a client does not
+   have permissions to access them.)  In this case, \HasNoChildren
+   SHOULD be used.
+
+   In many cases, however, a server may not be able to efficiently
+   compute whether a user has access to all child mailboxes, or multiple
+   users may be accessing the same account and simultaneously changing
+   the mailbox hierarchy.  As such a client MUST be prepared to accept
+   the \HasChildren attribute as a hint.  That is, a mailbox MAY be
+   flagged with the \HasChildren attribute, but no child mailboxes will
+   appear in a subsequent LIST response.
+
+
+
+
+Gahrns, et al.               Informational                      [Page 2]
+
+RFC 3348             IMAP4 Child Mailbox Extension             July 2002
+
+
+   Example 3.1:
+   ============
+
+   /*** Consider a server that has the following mailbox hierarchy:
+
+   INBOX
+   ITEM_1
+      ITEM_1A
+   ITEM_2
+      TOP_SECRET
+
+   Where INBOX, ITEM_1 and ITEM_2 are top level mailboxes.  ITEM_1A is a
+   child mailbox of ITEM_1 and TOP_SECRET is a child mailbox of ITEM_2
+   that the currently logged on user does NOT have access to.
+
+   Note that in this case, the server is not able to efficiently compute
+   access rights to child mailboxes and responds with a \HasChildren
+   attribute for mailbox ITEM_2, even though ITEM_2/TOP_SECRET does not
+   appear in the list response.  ***/
+
+   C: A001 LIST "" *
+   S: * LIST (\HasNoChildren) "/" INBOX
+   S: * LIST (\HasChildren) "/" ITEM_1
+   S: * LIST (\HasNoChildren) "/" ITEM_1/ITEM_1A
+   S: * LIST (\HasChildren) "/" ITEM_2
+   S: A001 OK LIST Completed
+
+   \HasNoChildren - The presence of this attribute indicates that the
+   mailbox has NO child mailboxes that are accessible to the currently
+   authenticated user.  If a mailbox has the \Noinferiors attribute, the
+   \HasNoChildren attribute is redundant and SHOULD be omitted in the
+   LIST response.
+
+   In some instances a server that supports the CHILDREN extension MAY
+   NOT be able to determine whether a mailbox has children.  For example
+   it may have difficulty determining whether there are child mailboxes
+   when LISTing mailboxes while operating in a particular namespace.
+
+   In these cases, a server MAY exclude both the \HasChildren and
+   \HasNoChildren attributes in the LIST response.  As such, a client
+   can not make any assumptions about whether a mailbox has children
+   based upon the absence of a single attribute.
+
+   It is an error for the server to return both a \HasChildren and a
+   \HasNoChildren attribute in a LIST response.
+
+
+
+
+
+
+Gahrns, et al.               Informational                      [Page 3]
+
+RFC 3348             IMAP4 Child Mailbox Extension             July 2002
+
+
+   It is an error for the server to return both a \HasChildren and a
+   \NoInferiors attribute in a LIST response.
+
+   Note: the \HasNoChildren attribute should not be confused with the
+   IMAP4 [RFC-2060] defined attribute \Noinferiors which indicates that
+   no child mailboxes exist now and none can be created in the future.
+
+   The \HasChildren and \HasNoChildren attributes might not be returned
+   in response to a LSUB response.  Many servers maintain a simple
+   mailbox subscription list that is not updated when the underlying
+   mailbox structure is changed.  A client MUST NOT assume that
+   hierarchy information will be maintained in the subscription list.
+
+   RLIST is a command defined in [RFC-2193] that includes in a LIST
+   response mailboxes that are accessible only via referral.  That is, a
+   client must explicitly issue an RLIST command to see a list of these
+   mailboxes.  Thus in the case where a mailbox has child mailboxes that
+   are available only via referral, the mailboxes would appear as
+   \HasNoChildren in response to the LIST command, and \HasChildren in
+   response to the RLIST command.
+
+5. Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) as described in [ABNF].
+
+   Two new mailbox attributes are defined as flag_extensions to the
+   IMAP4 mailbox_list response:
+
+   HasChildren = "\HasChildren"
+
+   HasNoChildren = "\HasNoChildren"
+
+6. Security Considerations
+
+   This extension provides a client a more efficient means of
+   determining whether a particular mailbox has children.  If a mailbox
+   has children, but the currently authenticated user does not have
+   access to any of them, the server SHOULD respond with a
+   \HasNoChildren attribute.  In many cases, however, a server may not
+   be able to efficiently compute whether a user has access to all child
+   mailboxes.  If such a server responds with a \HasChildren attribute,
+   when in fact the currently authenticated user does not have access to
+   any child mailboxes, potentially more information is conveyed about
+   the mailbox than intended.  A server designed with such levels of
+   security in mind SHOULD NOT attach the \HasChildren attribute to a
+   mailbox unless the server is certain that the user has access to at
+   least one of the child mailboxes.
+
+
+
+Gahrns, et al.               Informational                      [Page 4]
+
+RFC 3348             IMAP4 Child Mailbox Extension             July 2002
+
+
+7. References
+
+   [RFC-2060] Crispin, M., "Internet Message Access Protocol - Version
+              4rev1", RFC 2060, December 1996.
+
+   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC-2234] Crocker, D. and P. Overell, Editors, "Augmented BNF for
+              Syntax Specifications: ABNF", RFC 2234, November 1997.
+
+   [RFC-2193] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, September
+              1997.
+
+8.  Acknowledgments
+
+   The authors would like to thank the participants of several IMC Mail
+   Connect events for their input when this idea was originally
+   presented and refined.
+
+9. Author's Address
+
+   Mike Gahrns
+   Microsoft
+   One Microsoft Way
+   Redmond, WA, 98052
+   Phone: (425) 936-9833
+   EMail: mikega@microsoft.com
+
+   Raymond Cheng
+   Microsoft
+   One Microsoft Way
+   Redmond, WA, 98052
+   Phone: (425) 703-4913
+   EMail: raych@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gahrns, et al.               Informational                      [Page 5]
+
+RFC 3348             IMAP4 Child Mailbox Extension             July 2002
+
+
+10. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gahrns, et al.               Informational                      [Page 6]
+
diff --git a/docs/rfcs/rfc3501.txt b/docs/rfcs/rfc3501.txt
new file mode 100644
index 0000000..5ab48e1
--- /dev/null
+++ b/docs/rfcs/rfc3501.txt
@@ -0,0 +1,6051 @@
+
+
+
+
+
+
+Network Working Group                                         M. Crispin
+Request for Comments: 3501                      University of Washington
+Obsoletes: 2060                                               March 2003
+Category: Standards Track
+
+
+            INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
+   allows a client to access and manipulate electronic mail messages on
+   a server.  IMAP4rev1 permits manipulation of mailboxes (remote
+   message folders) in a way that is functionally equivalent to local
+   folders.  IMAP4rev1 also provides the capability for an offline
+   client to resynchronize with the server.
+
+   IMAP4rev1 includes operations for creating, deleting, and renaming
+   mailboxes, checking for new messages, permanently removing messages,
+   setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching,
+   and selective fetching of message attributes, texts, and portions
+   thereof.  Messages in IMAP4rev1 are accessed by the use of numbers.
+   These numbers are either message sequence numbers or unique
+   identifiers.
+
+   IMAP4rev1 supports a single server.  A mechanism for accessing
+   configuration information to support multiple IMAP4rev1 servers is
+   discussed in RFC 2244.
+
+   IMAP4rev1 does not specify a means of posting mail; this function is
+   handled by a mail transfer protocol such as RFC 2821.
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                     [Page 1]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+Table of Contents
+
+   IMAP4rev1 Protocol Specification ................................  4
+   1.      How to Read This Document ...............................  4
+   1.1.    Organization of This Document ...........................  4
+   1.2.    Conventions Used in This Document .......................  4
+   1.3.    Special Notes to Implementors ...........................  5
+   2.      Protocol Overview .......................................  6
+   2.1.    Link Level ..............................................  6
+   2.2.    Commands and Responses ..................................  6
+   2.2.1.  Client Protocol Sender and Server Protocol Receiver .....  6
+   2.2.2.  Server Protocol Sender and Client Protocol Receiver .....  7
+   2.3.    Message Attributes ......................................  8
+   2.3.1.  Message Numbers .........................................  8
+   2.3.1.1.        Unique Identifier (UID) Message Attribute .......  8
+   2.3.1.2.        Message Sequence Number Message Attribute ....... 10
+   2.3.2.  Flags Message Attribute ................................. 11
+   2.3.3.  Internal Date Message Attribute ......................... 12
+   2.3.4.  [RFC-2822] Size Message Attribute ....................... 12
+   2.3.5.  Envelope Structure Message Attribute .................... 12
+   2.3.6.  Body Structure Message Attribute ........................ 12
+   2.4.    Message Texts ........................................... 13
+   3.      State and Flow Diagram .................................. 13
+   3.1.    Not Authenticated State ................................. 13
+   3.2.    Authenticated State ..................................... 13
+   3.3.    Selected State .......................................... 13
+   3.4.    Logout State ............................................ 14
+   4.      Data Formats ............................................ 16
+   4.1.    Atom .................................................... 16
+   4.2.    Number .................................................. 16
+   4.3.    String .................................................. 16
+   4.3.1.  8-bit and Binary Strings ................................ 17
+   4.4.    Parenthesized List ...................................... 17
+   4.5.    NIL ..................................................... 17
+   5.      Operational Considerations .............................. 18
+   5.1.    Mailbox Naming .......................................... 18
+   5.1.1.  Mailbox Hierarchy Naming ................................ 19
+   5.1.2.  Mailbox Namespace Naming Convention ..................... 19
+   5.1.3.  Mailbox International Naming Convention ................. 19
+   5.2.    Mailbox Size and Message Status Updates ................. 21
+   5.3.    Response when no Command in Progress .................... 21
+   5.4.    Autologout Timer ........................................ 22
+   5.5.    Multiple Commands in Progress ........................... 22
+   6.      Client Commands ........................................  23
+   6.1.    Client Commands - Any State ............................  24
+   6.1.1.  CAPABILITY Command .....................................  24
+   6.1.2.  NOOP Command ...........................................  25
+   6.1.3.  LOGOUT Command .........................................  26
+
+
+
+Crispin                     Standards Track                     [Page 2]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   6.2.    Client Commands - Not Authenticated State ..............  26
+   6.2.1.  STARTTLS Command .......................................  27
+   6.2.2.  AUTHENTICATE Command ...................................  28
+   6.2.3.  LOGIN Command ..........................................  30
+   6.3.    Client Commands - Authenticated State ..................  31
+   6.3.1.  SELECT Command .........................................  32
+   6.3.2.  EXAMINE Command ........................................  34
+   6.3.3.  CREATE Command .........................................  34
+   6.3.4.  DELETE Command .........................................  35
+   6.3.5.  RENAME Command .........................................  37
+   6.3.6.  SUBSCRIBE Command ......................................  39
+   6.3.7.  UNSUBSCRIBE Command ....................................  39
+   6.3.8.  LIST Command ...........................................  40
+   6.3.9.  LSUB Command ...........................................  43
+   6.3.10. STATUS Command .........................................  44
+   6.3.11. APPEND Command .........................................  46
+   6.4.    Client Commands - Selected State .......................  47
+   6.4.1.  CHECK Command ..........................................  47
+   6.4.2.  CLOSE Command ..........................................  48
+   6.4.3.  EXPUNGE Command ........................................  49
+   6.4.4.  SEARCH Command .........................................  49
+   6.4.5.  FETCH Command ..........................................  54
+   6.4.6.  STORE Command ..........................................  58
+   6.4.7.  COPY Command ...........................................  59
+   6.4.8.  UID Command ............................................  60
+   6.5.    Client Commands - Experimental/Expansion ...............  62
+   6.5.1.  X<atom> Command ........................................  62
+   7.      Server Responses .......................................  62
+   7.1.    Server Responses - Status Responses ....................  63
+   7.1.1.  OK Response ............................................  65
+   7.1.2.  NO Response ............................................  66
+   7.1.3.  BAD Response ...........................................  66
+   7.1.4.  PREAUTH Response .......................................  67
+   7.1.5.  BYE Response ...........................................  67
+   7.2.    Server Responses - Server and Mailbox Status ...........  68
+   7.2.1.  CAPABILITY Response ....................................  68
+   7.2.2.  LIST Response ..........................................  69
+   7.2.3.  LSUB Response ..........................................  70
+   7.2.4   STATUS Response ........................................  70
+   7.2.5.  SEARCH Response ........................................  71
+   7.2.6.  FLAGS Response .........................................  71
+   7.3.    Server Responses - Mailbox Size ........................  71
+   7.3.1.  EXISTS Response ........................................  71
+   7.3.2.  RECENT Response ........................................  72
+   7.4.    Server Responses - Message Status ......................  72
+   7.4.1.  EXPUNGE Response .......................................  72
+   7.4.2.  FETCH Response .........................................  73
+   7.5.    Server Responses - Command Continuation Request ........  79
+
+
+
+Crispin                     Standards Track                     [Page 3]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   8.      Sample IMAP4rev1 connection ............................  80
+   9.      Formal Syntax ..........................................  81
+   10.     Author's Note ..........................................  92
+   11.     Security Considerations ................................  92
+   11.1.   STARTTLS Security Considerations .......................  92
+   11.2.   Other Security Considerations ..........................  93
+   12.     IANA Considerations ....................................  94
+   Appendices .....................................................  95
+   A.      References .............................................  95
+   B.      Changes from RFC 2060 ..................................  97
+   C.      Key Word Index ......................................... 103
+   Author's Address ............................................... 107
+   Full Copyright Statement ....................................... 108
+
+IMAP4rev1 Protocol Specification
+
+1.      How to Read This Document
+
+1.1.    Organization of This Document
+
+   This document is written from the point of view of the implementor of
+   an IMAP4rev1 client or server.  Beyond the protocol overview in
+   section 2, it is not optimized for someone trying to understand the
+   operation of the protocol.  The material in sections 3 through 5
+   provides the general context and definitions with which IMAP4rev1
+   operates.
+
+   Sections 6, 7, and 9 describe the IMAP commands, responses, and
+   syntax, respectively.  The relationships among these are such that it
+   is almost impossible to understand any of them separately.  In
+   particular, do not attempt to deduce command syntax from the command
+   section alone; instead refer to the Formal Syntax section.
+
+1.2.    Conventions Used in This Document
+
+   "Conventions" are basic principles or procedures.  Document
+   conventions are noted in this section.
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
+   be interpreted as described in [KEYWORDS].
+
+   The word "can" (not "may") is used to refer to a possible
+   circumstance or situation, as opposed to an optional facility of the
+   protocol.
+
+
+
+Crispin                     Standards Track                     [Page 4]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   "User" is used to refer to a human user, whereas "client" refers to
+   the software being run by the user.
+
+   "Connection" refers to the entire sequence of client/server
+   interaction from the initial establishment of the network connection
+   until its termination.
+
+   "Session" refers to the sequence of client/server interaction from
+   the time that a mailbox is selected (SELECT or EXAMINE command) until
+   the time that selection ends (SELECT or EXAMINE of another mailbox,
+   CLOSE command, or connection termination).
+
+   Characters are 7-bit US-ASCII unless otherwise specified.  Other
+   character sets are indicated using a "CHARSET", as described in
+   [MIME-IMT] and defined in [CHARSET].  CHARSETs have important
+   additional semantics in addition to defining character set; refer to
+   these documents for more detail.
+
+   There are several protocol conventions in IMAP.  These refer to
+   aspects of the specification which are not strictly part of the IMAP
+   protocol, but reflect generally-accepted practice.  Implementations
+   need to be aware of these conventions, and avoid conflicts whether or
+   not they implement the convention.  For example, "&" may not be used
+   as a hierarchy delimiter since it conflicts with the Mailbox
+   International Naming Convention, and other uses of "&" in mailbox
+   names are impacted as well.
+
+1.3.    Special Notes to Implementors
+
+   Implementors of the IMAP protocol are strongly encouraged to read the
+   IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in
+   conjunction with this document, to help understand the intricacies of
+   this protocol and how best to build an interoperable product.
+
+   IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
+   unpublished IMAP2bis protocols.  IMAP4rev1 is largely compatible with
+   the IMAP4 protocol described in RFC 1730; the exception being in
+   certain facilities added in RFC 1730 that proved problematic and were
+   subsequently removed.  In the course of the evolution of IMAP4rev1,
+   some aspects in the earlier protocols have become obsolete.  Obsolete
+   commands, responses, and data formats which an IMAP4rev1
+   implementation can encounter when used with an earlier implementation
+   are described in [IMAP-OBSOLETE].
+
+   Other compatibility issues with IMAP2bis, the most common variant of
+   the earlier protocol, are discussed in [IMAP-COMPAT].  A full
+   discussion of compatibility issues with rare (and presumed extinct)
+
+
+
+
+Crispin                     Standards Track                     [Page 5]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
+   primarily of historical interest.
+
+   IMAP was originally developed for the older [RFC-822] standard, and
+   as a consequence several fetch items in IMAP incorporate "RFC822" in
+   their name.  With the exception of RFC822.SIZE, there are more modern
+   replacements; for example, the modern version of RFC822.HEADER is
+   BODY.PEEK[HEADER].  In all cases, "RFC822" should be interpreted as a
+   reference to the updated [RFC-2822] standard.
+
+2.      Protocol Overview
+
+2.1.    Link Level
+
+   The IMAP4rev1 protocol assumes a reliable data stream such as that
+   provided by TCP.  When TCP is used, an IMAP4rev1 server listens on
+   port 143.
+
+2.2.    Commands and Responses
+
+   An IMAP4rev1 connection consists of the establishment of a
+   client/server network connection, an initial greeting from the
+   server, and client/server interactions.  These client/server
+   interactions consist of a client command, server data, and a server
+   completion result response.
+
+   All interactions transmitted by client and server are in the form of
+   lines, that is, strings that end with a CRLF.  The protocol receiver
+   of an IMAP4rev1 client or server is either reading a line, or is
+   reading a sequence of octets with a known count followed by a line.
+
+2.2.1.  Client Protocol Sender and Server Protocol Receiver
+
+   The client command begins an operation.  Each client command is
+   prefixed with an identifier (typically a short alphanumeric string,
+   e.g., A0001, A0002, etc.) called a "tag".  A different tag is
+   generated by the client for each command.
+
+   Clients MUST follow the syntax outlined in this specification
+   strictly.  It is a syntax error to send a command with missing or
+   extraneous spaces or arguments.
+
+   There are two cases in which a line from the client does not
+   represent a complete command.  In one case, a command argument is
+   quoted with an octet count (see the description of literal in String
+   under Data Formats); in the other case, the command arguments require
+   server feedback (see the AUTHENTICATE command).  In either case, the
+
+
+
+
+Crispin                     Standards Track                     [Page 6]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   server sends a command continuation request response if it is ready
+   for the octets (if appropriate) and the remainder of the command.
+   This response is prefixed with the token "+".
+
+        Note: If instead, the server detected an error in the
+        command, it sends a BAD completion response with a tag
+        matching the command (as described below) to reject the
+        command and prevent the client from sending any more of the
+        command.
+
+        It is also possible for the server to send a completion
+        response for some other command (if multiple commands are
+        in progress), or untagged data.  In either case, the
+        command continuation request is still pending; the client
+        takes the appropriate action for the response, and reads
+        another response from the server.  In all cases, the client
+        MUST send a complete command (including receiving all
+        command continuation request responses and command
+        continuations for the command) before initiating a new
+        command.
+
+   The protocol receiver of an IMAP4rev1 server reads a command line
+   from the client, parses the command and its arguments, and transmits
+   server data and a server command completion result response.
+
+2.2.2.  Server Protocol Sender and Client Protocol Receiver
+
+   Data transmitted by the server to the client and status responses
+   that do not indicate command completion are prefixed with the token
+   "*", and are called untagged responses.
+
+   Server data MAY be sent as a result of a client command, or MAY be
+   sent unilaterally by the server.  There is no syntactic difference
+   between server data that resulted from a specific command and server
+   data that were sent unilaterally.
+
+   The server completion result response indicates the success or
+   failure of the operation.  It is tagged with the same tag as the
+   client command which began the operation.  Thus, if more than one
+   command is in progress, the tag in a server completion response
+   identifies the command to which the response applies.  There are
+   three possible server completion responses: OK (indicating success),
+   NO (indicating failure), or BAD (indicating a protocol error such as
+   unrecognized command or command syntax error).
+
+   Servers SHOULD enforce the syntax outlined in this specification
+   strictly.  Any client command with a protocol syntax error, including
+   (but not limited to) missing or extraneous spaces or arguments,
+
+
+
+Crispin                     Standards Track                     [Page 7]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   SHOULD be rejected, and the client given a BAD server completion
+   response.
+
+   The protocol receiver of an IMAP4rev1 client reads a response line
+   from the server.  It then takes action on the response based upon the
+   first token of the response, which can be a tag, a "*", or a "+".
+
+   A client MUST be prepared to accept any server response at all times.
+   This includes server data that was not requested.  Server data SHOULD
+   be recorded, so that the client can reference its recorded copy
+   rather than sending a command to the server to request the data.  In
+   the case of certain server data, the data MUST be recorded.
+
+   This topic is discussed in greater detail in the Server Responses
+   section.
+
+2.3.    Message Attributes
+
+   In addition to message text, each message has several attributes
+   associated with it.  These attributes can be retrieved individually
+   or in conjunction with other attributes or message texts.
+
+2.3.1.  Message Numbers
+
+   Messages in IMAP4rev1 are accessed by one of two numbers; the unique
+   identifier or the message sequence number.
+
+
+2.3.1.1.        Unique Identifier (UID) Message Attribute
+
+   A 32-bit value assigned to each message, which when used with the
+   unique identifier validity value (see below) forms a 64-bit value
+   that MUST NOT refer to any other message in the mailbox or any
+   subsequent mailbox with the same name forever.  Unique identifiers
+   are assigned in a strictly ascending fashion in the mailbox; as each
+   message is added to the mailbox it is assigned a higher UID than the
+   message(s) which were added previously.  Unlike message sequence
+   numbers, unique identifiers are not necessarily contiguous.
+
+   The unique identifier of a message MUST NOT change during the
+   session, and SHOULD NOT change between sessions.  Any change of
+   unique identifiers between sessions MUST be detectable using the
+   UIDVALIDITY mechanism discussed below.  Persistent unique identifiers
+   are required for a client to resynchronize its state from a previous
+   session with the server (e.g., disconnected or offline access
+   clients); this is discussed further in [IMAP-DISC].
+
+
+
+
+
+Crispin                     Standards Track                     [Page 8]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   Associated with every mailbox are two values which aid in unique
+   identifier handling: the next unique identifier value and the unique
+   identifier validity value.
+
+   The next unique identifier value is the predicted value that will be
+   assigned to a new message in the mailbox.  Unless the unique
+   identifier validity also changes (see below), the next unique
+   identifier value MUST have the following two characteristics.  First,
+   the next unique identifier value MUST NOT change unless new messages
+   are added to the mailbox; and second, the next unique identifier
+   value MUST change whenever new messages are added to the mailbox,
+   even if those new messages are subsequently expunged.
+
+        Note: The next unique identifier value is intended to
+        provide a means for a client to determine whether any
+        messages have been delivered to the mailbox since the
+        previous time it checked this value.  It is not intended to
+        provide any guarantee that any message will have this
+        unique identifier.  A client can only assume, at the time
+        that it obtains the next unique identifier value, that
+        messages arriving after that time will have a UID greater
+        than or equal to that value.
+
+   The unique identifier validity value is sent in a UIDVALIDITY
+   response code in an OK untagged response at mailbox selection time.
+   If unique identifiers from an earlier session fail to persist in this
+   session, the unique identifier validity value MUST be greater than
+   the one used in the earlier session.
+
+        Note: Ideally, unique identifiers SHOULD persist at all
+        times.  Although this specification recognizes that failure
+        to persist can be unavoidable in certain server
+        environments, it STRONGLY ENCOURAGES message store
+        implementation techniques that avoid this problem.  For
+        example:
+
+         1) Unique identifiers MUST be strictly ascending in the
+            mailbox at all times.  If the physical message store is
+            re-ordered by a non-IMAP agent, this requires that the
+            unique identifiers in the mailbox be regenerated, since
+            the former unique identifiers are no longer strictly
+            ascending as a result of the re-ordering.
+
+         2) If the message store has no mechanism to store unique
+            identifiers, it must regenerate unique identifiers at
+            each session, and each session must have a unique
+            UIDVALIDITY value.
+
+
+
+
+Crispin                     Standards Track                     [Page 9]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+         3) If the mailbox is deleted and a new mailbox with the
+            same name is created at a later date, the server must
+            either keep track of unique identifiers from the
+            previous instance of the mailbox, or it must assign a
+            new UIDVALIDITY value to the new instance of the
+            mailbox.  A good UIDVALIDITY value to use in this case
+            is a 32-bit representation of the creation date/time of
+            the mailbox.  It is alright to use a constant such as
+            1, but only if it guaranteed that unique identifiers
+            will never be reused, even in the case of a mailbox
+            being deleted (or renamed) and a new mailbox by the
+            same name created at some future time.
+
+         4) The combination of mailbox name, UIDVALIDITY, and UID
+            must refer to a single immutable message on that server
+            forever.  In particular, the internal date, [RFC-2822]
+            size, envelope, body structure, and message texts
+            (RFC822, RFC822.HEADER, RFC822.TEXT, and all BODY[...]
+            fetch data items) must never change.  This does not
+            include message numbers, nor does it include attributes
+            that can be set by a STORE command (e.g., FLAGS).
+
+
+2.3.1.2.        Message Sequence Number Message Attribute
+
+   A relative position from 1 to the number of messages in the mailbox.
+   This position MUST be ordered by ascending unique identifier.  As
+   each new message is added, it is assigned a message sequence number
+   that is 1 higher than the number of messages in the mailbox before
+   that new message was added.
+
+   Message sequence numbers can be reassigned during the session.  For
+   example, when a message is permanently removed (expunged) from the
+   mailbox, the message sequence number for all subsequent messages is
+   decremented.  The number of messages in the mailbox is also
+   decremented.  Similarly, a new message can be assigned a message
+   sequence number that was once held by some other message prior to an
+   expunge.
+
+   In addition to accessing messages by relative position in the
+   mailbox, message sequence numbers can be used in mathematical
+   calculations.  For example, if an untagged "11 EXISTS" is received,
+   and previously an untagged "8 EXISTS" was received, three new
+   messages have arrived with message sequence numbers of 9, 10, and 11.
+   Another example, if message 287 in a 523 message mailbox has UID
+   12345, there are exactly 286 messages which have lesser UIDs and 236
+   messages which have greater UIDs.
+
+
+
+
+Crispin                     Standards Track                    [Page 10]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+2.3.2.  Flags Message Attribute
+
+   A list of zero or more named tokens associated with the message.  A
+   flag is set by its addition to this list, and is cleared by its
+   removal.  There are two types of flags in IMAP4rev1.  A flag of
+   either type can be permanent or session-only.
+
+   A system flag is a flag name that is pre-defined in this
+   specification.  All system flags begin with "\".  Certain system
+   flags (\Deleted and \Seen) have special semantics described
+   elsewhere.  The currently-defined system flags are:
+
+        \Seen
+           Message has been read
+
+        \Answered
+           Message has been answered
+
+        \Flagged
+           Message is "flagged" for urgent/special attention
+
+        \Deleted
+           Message is "deleted" for removal by later EXPUNGE
+
+        \Draft
+           Message has not completed composition (marked as a draft).
+
+        \Recent
+           Message is "recently" arrived in this mailbox.  This session
+           is the first session to have been notified about this
+           message; if the session is read-write, subsequent sessions
+           will not see \Recent set for this message.  This flag can not
+           be altered by the client.
+
+           If it is not possible to determine whether or not this
+           session is the first session to be notified about a message,
+           then that message SHOULD be considered recent.
+
+           If multiple connections have the same mailbox selected
+           simultaneously, it is undefined which of these connections
+           will see newly-arrived messages with \Recent set and which
+           will see it without \Recent set.
+
+   A keyword is defined by the server implementation.  Keywords do not
+   begin with "\".  Servers MAY permit the client to define new keywords
+   in the mailbox (see the description of the PERMANENTFLAGS response
+   code for more information).
+
+
+
+
+Crispin                     Standards Track                    [Page 11]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   A flag can be permanent or session-only on a per-flag basis.
+   Permanent flags are those which the client can add or remove from the
+   message flags permanently; that is, concurrent and subsequent
+   sessions will see any change in permanent flags.  Changes to session
+   flags are valid only in that session.
+
+        Note: The \Recent system flag is a special case of a
+        session flag.  \Recent can not be used as an argument in a
+        STORE or APPEND command, and thus can not be changed at
+        all.
+
+2.3.3.  Internal Date Message Attribute
+
+   The internal date and time of the message on the server.  This
+   is not the date and time in the [RFC-2822] header, but rather a
+   date and time which reflects when the message was received.  In
+   the case of messages delivered via [SMTP], this SHOULD be the
+   date and time of final delivery of the message as defined by
+   [SMTP].  In the case of messages delivered by the IMAP4rev1 COPY
+   command, this SHOULD be the internal date and time of the source
+   message.  In the case of messages delivered by the IMAP4rev1
+   APPEND command, this SHOULD be the date and time as specified in
+   the APPEND command description.  All other cases are
+   implementation defined.
+
+2.3.4.  [RFC-2822] Size Message Attribute
+
+   The number of octets in the message, as expressed in [RFC-2822]
+   format.
+
+2.3.5.  Envelope Structure Message Attribute
+
+   A parsed representation of the [RFC-2822] header of the message.
+   Note that the IMAP Envelope structure is not the same as an
+   [SMTP] envelope.
+
+2.3.6.  Body Structure Message Attribute
+
+   A parsed representation of the [MIME-IMB] body structure
+   information of the message.
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 12]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+2.4.    Message Texts
+
+   In addition to being able to fetch the full [RFC-2822] text of a
+   message, IMAP4rev1 permits the fetching of portions of the full
+   message text.  Specifically, it is possible to fetch the
+   [RFC-2822] message header, [RFC-2822] message body, a [MIME-IMB]
+   body part, or a [MIME-IMB] header.
+
+3.      State and Flow Diagram
+
+   Once the connection between client and server is established, an
+   IMAP4rev1 connection is in one of four states.  The initial
+   state is identified in the server greeting.  Most commands are
+   only valid in certain states.  It is a protocol error for the
+   client to attempt a command while the connection is in an
+   inappropriate state, and the server will respond with a BAD or
+   NO (depending upon server implementation) command completion
+   result.
+
+3.1.    Not Authenticated State
+
+   In the not authenticated state, the client MUST supply
+   authentication credentials before most commands will be
+   permitted.  This state is entered when a connection starts
+   unless the connection has been pre-authenticated.
+
+3.2.    Authenticated State
+
+   In the authenticated state, the client is authenticated and MUST
+   select a mailbox to access before commands that affect messages
+   will be permitted.  This state is entered when a
+   pre-authenticated connection starts, when acceptable
+   authentication credentials have been provided, after an error in
+   selecting a mailbox, or after a successful CLOSE command.
+
+3.3.    Selected State
+
+   In a selected state, a mailbox has been selected to access.
+   This state is entered when a mailbox has been successfully
+   selected.
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 13]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+3.4.    Logout State
+
+   In the logout state, the connection is being terminated.  This
+   state can be entered as a result of a client request (via the
+   LOGOUT command) or by unilateral action on the part of either
+   the client or server.
+
+   If the client requests the logout state, the server MUST send an
+   untagged BYE response and a tagged OK response to the LOGOUT
+   command before the server closes the connection; and the client
+   MUST read the tagged OK response to the LOGOUT command before
+   the client closes the connection.
+
+   A server MUST NOT unilaterally close the connection without
+   sending an untagged BYE response that contains the reason for
+   having done so.  A client SHOULD NOT unilaterally close the
+   connection, and instead SHOULD issue a LOGOUT command.  If the
+   server detects that the client has unilaterally closed the
+   connection, the server MAY omit the untagged BYE response and
+   simply close its connection.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 14]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+                   +----------------------+
+                   |connection established|
+                   +----------------------+
+                              ||
+                              \/
+            +--------------------------------------+
+            |          server greeting             |
+            +--------------------------------------+
+                      || (1)       || (2)        || (3)
+                      \/           ||            ||
+            +-----------------+    ||            ||
+            |Not Authenticated|    ||            ||
+            +-----------------+    ||            ||
+             || (7)   || (4)       ||            ||
+             ||       \/           \/            ||
+             ||     +----------------+           ||
+             ||     | Authenticated  |<=++       ||
+             ||     +----------------+  ||       ||
+             ||       || (7)   || (5)   || (6)   ||
+             ||       ||       \/       ||       ||
+             ||       ||    +--------+  ||       ||
+             ||       ||    |Selected|==++       ||
+             ||       ||    +--------+           ||
+             ||       ||       || (7)            ||
+             \/       \/       \/                \/
+            +--------------------------------------+
+            |               Logout                 |
+            +--------------------------------------+
+                              ||
+                              \/
+                +-------------------------------+
+                |both sides close the connection|
+                +-------------------------------+
+
+         (1) connection without pre-authentication (OK greeting)
+         (2) pre-authenticated connection (PREAUTH greeting)
+         (3) rejected connection (BYE greeting)
+         (4) successful LOGIN or AUTHENTICATE command
+         (5) successful SELECT or EXAMINE command
+         (6) CLOSE command, or failed SELECT or EXAMINE command
+         (7) LOGOUT command, server shutdown, or connection closed
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 15]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+4.      Data Formats
+
+   IMAP4rev1 uses textual commands and responses.  Data in
+   IMAP4rev1 can be in one of several forms: atom, number, string,
+   parenthesized list, or NIL.  Note that a particular data item
+   may take more than one form; for example, a data item defined as
+   using "astring" syntax may be either an atom or a string.
+
+4.1.    Atom
+
+   An atom consists of one or more non-special characters.
+
+4.2.    Number
+
+   A number consists of one or more digit characters, and
+   represents a numeric value.
+
+4.3.    String
+
+   A string is in one of two forms: either literal or quoted
+   string.  The literal form is the general form of string.  The
+   quoted string form is an alternative that avoids the overhead of
+   processing a literal at the cost of limitations of characters
+   which may be used.
+
+   A literal is a sequence of zero or more octets (including CR and
+   LF), prefix-quoted with an octet count in the form of an open
+   brace ("{"), the number of octets, close brace ("}"), and CRLF.
+   In the case of literals transmitted from server to client, the
+   CRLF is immediately followed by the octet data.  In the case of
+   literals transmitted from client to server, the client MUST wait
+   to receive a command continuation request (described later in
+   this document) before sending the octet data (and the remainder
+   of the command).
+
+   A quoted string is a sequence of zero or more 7-bit characters,
+   excluding CR and LF, with double quote (<">) characters at each
+   end.
+
+   The empty string is represented as either "" (a quoted string
+   with zero characters between double quotes) or as {0} followed
+   by CRLF (a literal with an octet count of 0).
+
+     Note: Even if the octet count is 0, a client transmitting a
+     literal MUST wait to receive a command continuation request.
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 16]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+4.3.1.  8-bit and Binary Strings
+
+   8-bit textual and binary mail is supported through the use of a
+   [MIME-IMB] content transfer encoding.  IMAP4rev1 implementations MAY
+   transmit 8-bit or multi-octet characters in literals, but SHOULD do
+   so only when the [CHARSET] is identified.
+
+   Although a BINARY body encoding is defined, unencoded binary strings
+   are not permitted.  A "binary string" is any string with NUL
+   characters.  Implementations MUST encode binary data into a textual
+   form, such as BASE64, before transmitting the data.  A string with an
+   excessive amount of CTL characters MAY also be considered to be
+   binary.
+
+4.4.    Parenthesized List
+
+   Data structures are represented as a "parenthesized list"; a sequence
+   of data items, delimited by space, and bounded at each end by
+   parentheses.  A parenthesized list can contain other parenthesized
+   lists, using multiple levels of parentheses to indicate nesting.
+
+   The empty list is represented as () -- a parenthesized list with no
+   members.
+
+4.5.    NIL
+
+   The special form "NIL" represents the non-existence of a particular
+   data item that is represented as a string or parenthesized list, as
+   distinct from the empty string "" or the empty parenthesized list ().
+
+        Note: NIL is never used for any data item which takes the
+        form of an atom.  For example, a mailbox name of "NIL" is a
+        mailbox named NIL as opposed to a non-existent mailbox
+        name.  This is because mailbox uses "astring" syntax which
+        is an atom or a string.  Conversely, an addr-name of NIL is
+        a non-existent personal name, because addr-name uses
+        "nstring" syntax which is NIL or a string, but never an
+        atom.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 17]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+5.      Operational Considerations
+
+   The following rules are listed here to ensure that all IMAP4rev1
+   implementations interoperate properly.
+
+5.1.    Mailbox Naming
+
+   Mailbox names are 7-bit.  Client implementations MUST NOT attempt to
+   create 8-bit mailbox names, and SHOULD interpret any 8-bit mailbox
+   names returned by LIST or LSUB as UTF-8.  Server implementations
+   SHOULD prohibit the creation of 8-bit mailbox names, and SHOULD NOT
+   return 8-bit mailbox names in LIST or LSUB.  See section 5.1.3 for
+   more information on how to represent non-ASCII mailbox names.
+
+        Note: 8-bit mailbox names were undefined in earlier
+        versions of this protocol.  Some sites used a local 8-bit
+        character set to represent non-ASCII mailbox names.  Such
+        usage is not interoperable, and is now formally deprecated.
+
+   The case-insensitive mailbox name INBOX is a special name reserved to
+   mean "the primary mailbox for this user on this server".  The
+   interpretation of all other names is implementation-dependent.
+
+   In particular, this specification takes no position on case
+   sensitivity in non-INBOX mailbox names.  Some server implementations
+   are fully case-sensitive; others preserve case of a newly-created
+   name but otherwise are case-insensitive; and yet others coerce names
+   to a particular case.  Client implementations MUST interact with any
+   of these.  If a server implementation interprets non-INBOX mailbox
+   names as case-insensitive, it MUST treat names using the
+   international naming convention specially as described in section
+   5.1.3.
+
+   There are certain client considerations when creating a new mailbox
+   name:
+
+   1)    Any character which is one of the atom-specials (see the Formal
+         Syntax) will require that the mailbox name be represented as a
+         quoted string or literal.
+
+   2)    CTL and other non-graphic characters are difficult to represent
+         in a user interface and are best avoided.
+
+   3)    Although the list-wildcard characters ("%" and "*") are valid
+         in a mailbox name, it is difficult to use such mailbox names
+         with the LIST and LSUB commands due to the conflict with
+         wildcard interpretation.
+
+
+
+
+Crispin                     Standards Track                    [Page 18]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   4)    Usually, a character (determined by the server implementation)
+         is reserved to delimit levels of hierarchy.
+
+   5)    Two characters, "#" and "&", have meanings by convention, and
+         should be avoided except when used in that convention.
+
+5.1.1.  Mailbox Hierarchy Naming
+
+   If it is desired to export hierarchical mailbox names, mailbox names
+   MUST be left-to-right hierarchical using a single character to
+   separate levels of hierarchy.  The same hierarchy separator character
+   is used for all levels of hierarchy within a single name.
+
+5.1.2.  Mailbox Namespace Naming Convention
+
+   By convention, the first hierarchical element of any mailbox name
+   which begins with "#" identifies the "namespace" of the remainder of
+   the name.  This makes it possible to disambiguate between different
+   types of mailbox stores, each of which have their own namespaces.
+
+        For example, implementations which offer access to USENET
+        newsgroups MAY use the "#news" namespace to partition the
+        USENET newsgroup namespace from that of other mailboxes.
+        Thus, the comp.mail.misc newsgroup would have a mailbox
+        name of "#news.comp.mail.misc", and the name
+        "comp.mail.misc" can refer to a different object (e.g., a
+        user's private mailbox).
+
+5.1.3.  Mailbox International Naming Convention
+
+   By convention, international mailbox names in IMAP4rev1 are specified
+   using a modified version of the UTF-7 encoding described in [UTF-7].
+   Modified UTF-7 may also be usable in servers that implement an
+   earlier version of this protocol.
+
+   In modified UTF-7, printable US-ASCII characters, except for "&",
+   represent themselves; that is, characters with octet values 0x20-0x25
+   and 0x27-0x7e.  The character "&" (0x26) is represented by the
+   two-octet sequence "&-".
+
+   All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
+   represented in modified BASE64, with a further modification from
+   [UTF-7] that "," is used instead of "/".  Modified BASE64 MUST NOT be
+   used to represent any printing US-ASCII character which can represent
+   itself.
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 19]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   "&" is used to shift to modified BASE64 and "-" to shift back to
+   US-ASCII.  There is no implicit shift from BASE64 to US-ASCII, and
+   null shifts ("-&" while in BASE64; note that "&-" while in US-ASCII
+   means "&") are not permitted.  However, all names start in US-ASCII,
+   and MUST end in US-ASCII; that is, a name that ends with a non-ASCII
+   ISO-10646 character MUST end with a "-").
+
+   The purpose of these modifications is to correct the following
+   problems with UTF-7:
+
+      1) UTF-7 uses the "+" character for shifting; this conflicts with
+         the common use of "+" in mailbox names, in particular USENET
+         newsgroup names.
+
+      2) UTF-7's encoding is BASE64 which uses the "/" character; this
+         conflicts with the use of "/" as a popular hierarchy delimiter.
+
+      3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with
+         the use of "\" as a popular hierarchy delimiter.
+
+      4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with
+         the use of "~" in some servers as a home directory indicator.
+
+      5) UTF-7 permits multiple alternate forms to represent the same
+         string; in particular, printable US-ASCII characters can be
+         represented in encoded form.
+
+      Although modified UTF-7 is a convention, it establishes certain
+      requirements on server handling of any mailbox name with an
+      embedded "&" character.  In particular, server implementations
+      MUST preserve the exact form of the modified BASE64 portion of a
+      modified UTF-7 name and treat that text as case-sensitive, even if
+      names are otherwise case-insensitive or case-folded.
+
+      Server implementations SHOULD verify that any mailbox name with an
+      embedded "&" character, used as an argument to CREATE, is: in the
+      correctly modified UTF-7 syntax, has no superfluous shifts, and
+      has no encoding in modified BASE64 of any printing US-ASCII
+      character which can represent itself.  However, client
+      implementations MUST NOT depend upon the server doing this, and
+      SHOULD NOT attempt to create a mailbox name with an embedded "&"
+      character unless it complies with the modified UTF-7 syntax.
+
+      Server implementations which export a mail store that does not
+      follow the modified UTF-7 convention MUST convert to modified
+      UTF-7 any mailbox name that contains either non-ASCII characters
+      or the "&" character.
+
+
+
+
+Crispin                     Standards Track                    [Page 20]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+           For example, here is a mailbox name which mixes English,
+           Chinese, and Japanese text:
+           ~peter/mail/&U,BTFw-/&ZeVnLIqe-
+
+           For example, the string "&Jjo!" is not a valid mailbox
+           name because it does not contain a shift to US-ASCII
+           before the "!".  The correct form is "&Jjo-!".  The
+           string "&U,BTFw-&ZeVnLIqe-" is not permitted because it
+           contains a superfluous shift.  The correct form is
+           "&U,BTF2XlZyyKng-".
+
+5.2.    Mailbox Size and Message Status Updates
+
+   At any time, a server can send data that the client did not request.
+   Sometimes, such behavior is REQUIRED.  For example, agents other than
+   the server MAY add messages to the mailbox (e.g., new message
+   delivery), change the flags of the messages in the mailbox (e.g.,
+   simultaneous access to the same mailbox by multiple agents), or even
+   remove messages from the mailbox.  A server MUST send mailbox size
+   updates automatically if a mailbox size change is observed during the
+   processing of a command.  A server SHOULD send message flag updates
+   automatically, without requiring the client to request such updates
+   explicitly.
+
+   Special rules exist for server notification of a client about the
+   removal of messages to prevent synchronization errors; see the
+   description of the EXPUNGE response for more detail.  In particular,
+   it is NOT permitted to send an EXISTS response that would reduce the
+   number of messages in the mailbox; only the EXPUNGE response can do
+   this.
+
+   Regardless of what implementation decisions a client makes on
+   remembering data from the server, a client implementation MUST record
+   mailbox size updates.  It MUST NOT assume that any command after the
+   initial mailbox selection will return the size of the mailbox.
+
+5.3.    Response when no Command in Progress
+
+   Server implementations are permitted to send an untagged response
+   (except for EXPUNGE) while there is no command in progress.  Server
+   implementations that send such responses MUST deal with flow control
+   considerations.  Specifically, they MUST either (1) verify that the
+   size of the data does not exceed the underlying transport's available
+   window size, or (2) use non-blocking writes.
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 21]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+5.4.    Autologout Timer
+
+   If a server has an inactivity autologout timer, the duration of that
+   timer MUST be at least 30 minutes.  The receipt of ANY command from
+   the client during that interval SHOULD suffice to reset the
+   autologout timer.
+
+5.5.    Multiple Commands in Progress
+
+   The client MAY send another command without waiting for the
+   completion result response of a command, subject to ambiguity rules
+   (see below) and flow control constraints on the underlying data
+   stream.  Similarly, a server MAY begin processing another command
+   before processing the current command to completion, subject to
+   ambiguity rules.  However, any command continuation request responses
+   and command continuations MUST be negotiated before any subsequent
+   command is initiated.
+
+   The exception is if an ambiguity would result because of a command
+   that would affect the results of other commands.  Clients MUST NOT
+   send multiple commands without waiting if an ambiguity would result.
+   If the server detects a possible ambiguity, it MUST execute commands
+   to completion in the order given by the client.
+
+   The most obvious example of ambiguity is when a command would affect
+   the results of another command, e.g., a FETCH of a message's flags
+   and a STORE of that same message's flags.
+
+   A non-obvious ambiguity occurs with commands that permit an untagged
+   EXPUNGE response (commands other than FETCH, STORE, and SEARCH),
+   since an untagged EXPUNGE response can invalidate sequence numbers in
+   a subsequent command.  This is not a problem for FETCH, STORE, or
+   SEARCH commands because servers are prohibited from sending EXPUNGE
+   responses while any of those commands are in progress.  Therefore, if
+   the client sends any command other than FETCH, STORE, or SEARCH, it
+   MUST wait for the completion result response before sending a command
+   with message sequence numbers.
+
+        Note: UID FETCH, UID STORE, and UID SEARCH are different
+        commands from FETCH, STORE, and SEARCH.  If the client
+        sends a UID command, it must wait for a completion result
+        response before sending a command with message sequence
+        numbers.
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 22]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   For example, the following non-waiting command sequences are invalid:
+
+      FETCH + NOOP + STORE
+      STORE + COPY + FETCH
+      COPY + COPY
+      CHECK + FETCH
+
+   The following are examples of valid non-waiting command sequences:
+
+      FETCH + STORE + SEARCH + CHECK
+      STORE + COPY + EXPUNGE
+
+      UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting
+      command sequence, depending upon whether or not the second UID
+      SEARCH contains message sequence numbers.
+
+6.      Client Commands
+
+   IMAP4rev1 commands are described in this section.  Commands are
+   organized by the state in which the command is permitted.  Commands
+   which are permitted in multiple states are listed in the minimum
+   permitted state (for example, commands valid in authenticated and
+   selected state are listed in the authenticated state commands).
+
+   Command arguments, identified by "Arguments:" in the command
+   descriptions below, are described by function, not by syntax.  The
+   precise syntax of command arguments is described in the Formal Syntax
+   section.
+
+   Some commands cause specific server responses to be returned; these
+   are identified by "Responses:" in the command descriptions below.
+   See the response descriptions in the Responses section for
+   information on these responses, and the Formal Syntax section for the
+   precise syntax of these responses.  It is possible for server data to
+   be transmitted as a result of any command.  Thus, commands that do
+   not specifically require server data specify "no specific responses
+   for this command" instead of "none".
+
+   The "Result:" in the command description refers to the possible
+   tagged status responses to a command, and any special interpretation
+   of these status responses.
+
+   The state of a connection is only changed by successful commands
+   which are documented as changing state.  A rejected command (BAD
+   response) never changes the state of the connection or of the
+   selected mailbox.  A failed command (NO response) generally does not
+   change the state of the connection or of the selected mailbox; the
+   exception being the SELECT and EXAMINE commands.
+
+
+
+Crispin                     Standards Track                    [Page 23]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+6.1.    Client Commands - Any State
+
+   The following commands are valid in any state: CAPABILITY, NOOP, and
+   LOGOUT.
+
+6.1.1.  CAPABILITY Command
+
+   Arguments:  none
+
+   Responses:  REQUIRED untagged response: CAPABILITY
+
+   Result:     OK - capability completed
+               BAD - command unknown or arguments invalid
+
+      The CAPABILITY command requests a listing of capabilities that the
+      server supports.  The server MUST send a single untagged
+      CAPABILITY response with "IMAP4rev1" as one of the listed
+      capabilities before the (tagged) OK response.
+
+      A capability name which begins with "AUTH=" indicates that the
+      server supports that particular authentication mechanism.  All
+      such names are, by definition, part of this specification.  For
+      example, the authorization capability for an experimental
+      "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not
+      "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP".
+
+      Other capability names refer to extensions, revisions, or
+      amendments to this specification.  See the documentation of the
+      CAPABILITY response for additional information.  No capabilities,
+      beyond the base IMAP4rev1 set defined in this specification, are
+      enabled without explicit client action to invoke the capability.
+
+      Client and server implementations MUST implement the STARTTLS,
+      LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
+      capabilities.  See the Security Considerations section for
+      important information.
+
+      See the section entitled "Client Commands -
+      Experimental/Expansion" for information about the form of site or
+      implementation-specific capabilities.
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 24]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   Example:    C: abcd CAPABILITY
+               S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
+               LOGINDISABLED
+               S: abcd OK CAPABILITY completed
+               C: efgh STARTTLS
+               S: efgh OK STARTLS completed
+               <TLS negotiation, further commands are under [TLS] layer>
+               C: ijkl CAPABILITY
+               S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN
+               S: ijkl OK CAPABILITY completed
+
+
+6.1.2.  NOOP Command
+
+   Arguments:  none
+
+   Responses:  no specific responses for this command (but see below)
+
+   Result:     OK - noop completed
+               BAD - command unknown or arguments invalid
+
+      The NOOP command always succeeds.  It does nothing.
+
+      Since any command can return a status update as untagged data, the
+      NOOP command can be used as a periodic poll for new messages or
+      message status updates during a period of inactivity (this is the
+      preferred method to do this).  The NOOP command can also be used
+      to reset any inactivity autologout timer on the server.
+
+   Example:    C: a002 NOOP
+               S: a002 OK NOOP completed
+                  . . .
+               C: a047 NOOP
+               S: * 22 EXPUNGE
+               S: * 23 EXISTS
+               S: * 3 RECENT
+               S: * 14 FETCH (FLAGS (\Seen \Deleted))
+               S: a047 OK NOOP completed
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 25]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+6.1.3.  LOGOUT Command
+
+   Arguments:  none
+
+   Responses:  REQUIRED untagged response: BYE
+
+   Result:     OK - logout completed
+               BAD - command unknown or arguments invalid
+
+      The LOGOUT command informs the server that the client is done with
+      the connection.  The server MUST send a BYE untagged response
+      before the (tagged) OK response, and then close the network
+      connection.
+
+   Example:    C: A023 LOGOUT
+               S: * BYE IMAP4rev1 Server logging out
+               S: A023 OK LOGOUT completed
+               (Server and client then close the connection)
+
+6.2.    Client Commands - Not Authenticated State
+
+   In the not authenticated state, the AUTHENTICATE or LOGIN command
+   establishes authentication and enters the authenticated state.  The
+   AUTHENTICATE command provides a general mechanism for a variety of
+   authentication techniques, privacy protection, and integrity
+   checking; whereas the LOGIN command uses a traditional user name and
+   plaintext password pair and has no means of establishing privacy
+   protection or integrity checking.
+
+   The STARTTLS command is an alternate form of establishing session
+   privacy protection and integrity checking, but does not establish
+   authentication or enter the authenticated state.
+
+   Server implementations MAY allow access to certain mailboxes without
+   establishing authentication.  This can be done by means of the
+   ANONYMOUS [SASL] authenticator described in [ANONYMOUS].  An older
+   convention is a LOGIN command using the userid "anonymous"; in this
+   case, a password is required although the server may choose to accept
+   any password.  The restrictions placed on anonymous users are
+   implementation-dependent.
+
+   Once authenticated (including as anonymous), it is not possible to
+   re-enter not authenticated state.
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 26]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+   the following commands are valid in the not authenticated state:
+   STARTTLS, AUTHENTICATE and LOGIN.  See the Security Considerations
+   section for important information about these commands.
+
+6.2.1.  STARTTLS Command
+
+   Arguments:  none
+
+   Responses:  no specific response for this command
+
+   Result:     OK - starttls completed, begin TLS negotiation
+               BAD - command unknown or arguments invalid
+
+      A [TLS] negotiation begins immediately after the CRLF at the end
+      of the tagged OK response from the server.  Once a client issues a
+      STARTTLS command, it MUST NOT issue further commands until a
+      server response is seen and the [TLS] negotiation is complete.
+
+      The server remains in the non-authenticated state, even if client
+      credentials are supplied during the [TLS] negotiation.  This does
+      not preclude an authentication mechanism such as EXTERNAL (defined
+      in [SASL]) from using client identity determined by the [TLS]
+      negotiation.
+
+      Once [TLS] has been started, the client MUST discard cached
+      information about server capabilities and SHOULD re-issue the
+      CAPABILITY command.  This is necessary to protect against man-in-
+      the-middle attacks which alter the capabilities list prior to
+      STARTTLS.  The server MAY advertise different capabilities after
+      STARTTLS.
+
+   Example:    C: a001 CAPABILITY
+               S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
+               S: a001 OK CAPABILITY completed
+               C: a002 STARTTLS
+               S: a002 OK Begin TLS negotiation now
+               <TLS negotiation, further commands are under [TLS] layer>
+               C: a003 CAPABILITY
+               S: * CAPABILITY IMAP4rev1 AUTH=PLAIN
+               S: a003 OK CAPABILITY completed
+               C: a004 LOGIN joe password
+               S: a004 OK LOGIN completed
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 27]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+6.2.2.  AUTHENTICATE Command
+
+   Arguments:  authentication mechanism name
+
+   Responses:  continuation data can be requested
+
+   Result:     OK - authenticate completed, now in authenticated state
+               NO - authenticate failure: unsupported authentication
+                    mechanism, credentials rejected
+               BAD - command unknown or arguments invalid,
+                    authentication exchange cancelled
+
+      The AUTHENTICATE command indicates a [SASL] authentication
+      mechanism to the server.  If the server supports the requested
+      authentication mechanism, it performs an authentication protocol
+      exchange to authenticate and identify the client.  It MAY also
+      negotiate an OPTIONAL security layer for subsequent protocol
+      interactions.  If the requested authentication mechanism is not
+      supported, the server SHOULD reject the AUTHENTICATE command by
+      sending a tagged NO response.
+
+      The AUTHENTICATE command does not support the optional "initial
+      response" feature of [SASL].  Section 5.1 of [SASL] specifies how
+      to handle an authentication mechanism which uses an initial
+      response.
+
+      The service name specified by this protocol's profile of [SASL] is
+      "imap".
+
+      The authentication protocol exchange consists of a series of
+      server challenges and client responses that are specific to the
+      authentication mechanism.  A server challenge consists of a
+      command continuation request response with the "+" token followed
+      by a BASE64 encoded string.  The client response consists of a
+      single line consisting of a BASE64 encoded string.  If the client
+      wishes to cancel an authentication exchange, it issues a line
+      consisting of a single "*".  If the server receives such a
+      response, it MUST reject the AUTHENTICATE command by sending a
+      tagged BAD response.
+
+      If a security layer is negotiated through the [SASL]
+      authentication exchange, it takes effect immediately following the
+      CRLF that concludes the authentication exchange for the client,
+      and the CRLF of the tagged OK response for the server.
+
+      While client and server implementations MUST implement the
+      AUTHENTICATE command itself, it is not required to implement any
+      authentication mechanisms other than the PLAIN mechanism described
+
+
+
+Crispin                     Standards Track                    [Page 28]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      in [IMAP-TLS].  Also, an authentication mechanism is not required
+      to support any security layers.
+
+           Note: a server implementation MUST implement a
+           configuration in which it does NOT permit any plaintext
+           password mechanisms, unless either the STARTTLS command
+           has been negotiated or some other mechanism that
+           protects the session from password snooping has been
+           provided.  Server sites SHOULD NOT use any configuration
+           which permits a plaintext password mechanism without
+           such a protection mechanism against password snooping.
+           Client and server implementations SHOULD implement
+           additional [SASL] mechanisms that do not use plaintext
+           passwords, such the GSSAPI mechanism described in [SASL]
+           and/or the [DIGEST-MD5] mechanism.
+
+      Servers and clients can support multiple authentication
+      mechanisms.  The server SHOULD list its supported authentication
+      mechanisms in the response to the CAPABILITY command so that the
+      client knows which authentication mechanisms to use.
+
+      A server MAY include a CAPABILITY response code in the tagged OK
+      response of a successful AUTHENTICATE command in order to send
+      capabilities automatically.  It is unnecessary for a client to
+      send a separate CAPABILITY command if it recognizes these
+      automatic capabilities.  This should only be done if a security
+      layer was not negotiated by the AUTHENTICATE command, because the
+      tagged OK response as part of an AUTHENTICATE command is not
+      protected by encryption/integrity checking.  [SASL] requires the
+      client to re-issue a CAPABILITY command in this case.
+
+      If an AUTHENTICATE command fails with a NO response, the client
+      MAY try another authentication mechanism by issuing another
+      AUTHENTICATE command.  It MAY also attempt to authenticate by
+      using the LOGIN command (see section 6.2.3 for more detail).  In
+      other words, the client MAY request authentication types in
+      decreasing order of preference, with the LOGIN command as a last
+      resort.
+
+      The authorization identity passed from the client to the server
+      during the authentication exchange is interpreted by the server as
+      the user name whose privileges the client is requesting.
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 29]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   Example:    S: * OK IMAP4rev1 Server
+               C: A001 AUTHENTICATE GSSAPI
+               S: +
+               C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw
+                  MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0
+                  b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW
+                  Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA
+                  cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX
+                  AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y
+                  C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb
+                  I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi
+                  vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL
+                  pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n
+                  FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE
+                  NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx
+                  O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB
+                  vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg==
+               S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC
+                  AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0
+                  uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg==
+               C:
+               S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe
+                  ceP2CWY0SR0fAQAgAAQEBAQ=
+               C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP
+                  wkhbfa2QteAQAgAG1yYwE=
+               S: A001 OK GSSAPI authentication successful
+
+        Note: The line breaks within server challenges and client
+        responses are for editorial clarity and are not in real
+        authenticators.
+
+
+6.2.3.  LOGIN Command
+
+   Arguments:  user name
+               password
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - login completed, now in authenticated state
+               NO - login failure: user name or password rejected
+               BAD - command unknown or arguments invalid
+
+      The LOGIN command identifies the client to the server and carries
+      the plaintext password authenticating this user.
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 30]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      A server MAY include a CAPABILITY response code in the tagged OK
+      response to a successful LOGIN command in order to send
+      capabilities automatically.  It is unnecessary for a client to
+      send a separate CAPABILITY command if it recognizes these
+      automatic capabilities.
+
+   Example:    C: a001 LOGIN SMITH SESAME
+               S: a001 OK LOGIN completed
+
+        Note: Use of the LOGIN command over an insecure network
+        (such as the Internet) is a security risk, because anyone
+        monitoring network traffic can obtain plaintext passwords.
+        The LOGIN command SHOULD NOT be used except as a last
+        resort, and it is recommended that client implementations
+        have a means to disable any automatic use of the LOGIN
+        command.
+
+        Unless either the STARTTLS command has been negotiated or
+        some other mechanism that protects the session from
+        password snooping has been provided, a server
+        implementation MUST implement a configuration in which it
+        advertises the LOGINDISABLED capability and does NOT permit
+        the LOGIN command.  Server sites SHOULD NOT use any
+        configuration which permits the LOGIN command without such
+        a protection mechanism against password snooping.  A client
+        implementation MUST NOT send a LOGIN command if the
+        LOGINDISABLED capability is advertised.
+
+6.3.    Client Commands - Authenticated State
+
+   In the authenticated state, commands that manipulate mailboxes as
+   atomic entities are permitted.  Of these commands, the SELECT and
+   EXAMINE commands will select a mailbox for access and enter the
+   selected state.
+
+   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+   the following commands are valid in the authenticated state: SELECT,
+   EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
+   STATUS, and APPEND.
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 31]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+6.3.1.  SELECT Command
+
+   Arguments:  mailbox name
+
+   Responses:  REQUIRED untagged responses: FLAGS, EXISTS, RECENT
+               REQUIRED OK untagged responses:  UNSEEN,  PERMANENTFLAGS,
+               UIDNEXT, UIDVALIDITY
+
+   Result:     OK - select completed, now in selected state
+               NO - select failure, now in authenticated state: no
+                    such mailbox, can't access mailbox
+               BAD - command unknown or arguments invalid
+
+      The SELECT command selects a mailbox so that messages in the
+      mailbox can be accessed.  Before returning an OK to the client,
+      the server MUST send the following untagged data to the client.
+      Note that earlier versions of this protocol only required the
+      FLAGS, EXISTS, and RECENT untagged data; consequently, client
+      implementations SHOULD implement default behavior for missing data
+      as discussed with the individual item.
+
+         FLAGS       Defined flags in the mailbox.  See the description
+                     of the FLAGS response for more detail.
+
+         <n> EXISTS  The number of messages in the mailbox.  See the
+                     description of the EXISTS response for more detail.
+
+         <n> RECENT  The number of messages with the \Recent flag set.
+                     See the description of the RECENT response for more
+                     detail.
+
+         OK [UNSEEN <n>]
+                     The message sequence number of the first unseen
+                     message in the mailbox.  If this is missing, the
+                     client can not make any assumptions about the first
+                     unseen message in the mailbox, and needs to issue a
+                     SEARCH command if it wants to find it.
+
+         OK [PERMANENTFLAGS (<list of flags>)]
+                     A list of message flags that the client can change
+                     permanently.  If this is missing, the client should
+                     assume that all flags can be changed permanently.
+
+         OK [UIDNEXT <n>]
+                     The next unique identifier value.  Refer to section
+                     2.3.1.1 for more information.  If this is missing,
+                     the client can not make any assumptions about the
+                     next unique identifier value.
+
+
+
+Crispin                     Standards Track                    [Page 32]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+         OK [UIDVALIDITY <n>]
+                     The unique identifier validity value.  Refer to
+                     section 2.3.1.1 for more information.  If this is
+                     missing, the server does not support unique
+                     identifiers.
+
+      Only one mailbox can be selected at a time in a connection;
+      simultaneous access to multiple mailboxes requires multiple
+      connections.  The SELECT command automatically deselects any
+      currently selected mailbox before attempting the new selection.
+      Consequently, if a mailbox is selected and a SELECT command that
+      fails is attempted, no mailbox is selected.
+
+      If the client is permitted to modify the mailbox, the server
+      SHOULD prefix the text of the tagged OK response with the
+      "[READ-WRITE]" response code.
+
+      If the client is not permitted to modify the mailbox but is
+      permitted read access, the mailbox is selected as read-only, and
+      the server MUST prefix the text of the tagged OK response to
+      SELECT with the "[READ-ONLY]" response code.  Read-only access
+      through SELECT differs from the EXAMINE command in that certain
+      read-only mailboxes MAY permit the change of permanent state on a
+      per-user (as opposed to global) basis.  Netnews messages marked in
+      a server-based .newsrc file are an example of such per-user
+      permanent state that can be modified with read-only mailboxes.
+
+   Example:    C: A142 SELECT INBOX
+               S: * 172 EXISTS
+               S: * 1 RECENT
+               S: * OK [UNSEEN 12] Message 12 is first unseen
+               S: * OK [UIDVALIDITY 3857529045] UIDs valid
+               S: * OK [UIDNEXT 4392] Predicted next UID
+               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+               S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
+               S: A142 OK [READ-WRITE] SELECT completed
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 33]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+6.3.2.  EXAMINE Command
+
+   Arguments:  mailbox name
+
+   Responses:  REQUIRED untagged responses: FLAGS, EXISTS, RECENT
+               REQUIRED OK untagged responses:  UNSEEN,  PERMANENTFLAGS,
+               UIDNEXT, UIDVALIDITY
+
+   Result:     OK - examine completed, now in selected state
+               NO - examine failure, now in authenticated state: no
+                    such mailbox, can't access mailbox
+               BAD - command unknown or arguments invalid
+
+      The EXAMINE command is identical to SELECT and returns the same
+      output; however, the selected mailbox is identified as read-only.
+      No changes to the permanent state of the mailbox, including
+      per-user state, are permitted; in particular, EXAMINE MUST NOT
+      cause messages to lose the \Recent flag.
+
+      The text of the tagged OK response to the EXAMINE command MUST
+      begin with the "[READ-ONLY]" response code.
+
+   Example:    C: A932 EXAMINE blurdybloop
+               S: * 17 EXISTS
+               S: * 2 RECENT
+               S: * OK [UNSEEN 8] Message 8 is first unseen
+               S: * OK [UIDVALIDITY 3857529045] UIDs valid
+               S: * OK [UIDNEXT 4392] Predicted next UID
+               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+               S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
+               S: A932 OK [READ-ONLY] EXAMINE completed
+
+
+6.3.3.  CREATE Command
+
+   Arguments:  mailbox name
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - create completed
+               NO - create failure: can't create mailbox with that name
+               BAD - command unknown or arguments invalid
+
+      The CREATE command creates a mailbox with the given name.  An OK
+      response is returned only if a new mailbox with that name has been
+      created.  It is an error to attempt to create INBOX or a mailbox
+      with a name that refers to an extant mailbox.  Any error in
+      creation will return a tagged NO response.
+
+
+
+Crispin                     Standards Track                    [Page 34]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      If the mailbox name is suffixed with the server's hierarchy
+      separator character (as returned from the server by a LIST
+      command), this is a declaration that the client intends to create
+      mailbox names under this name in the hierarchy.  Server
+      implementations that do not require this declaration MUST ignore
+      the declaration.  In any case, the name created is without the
+      trailing hierarchy delimiter.
+
+      If the server's hierarchy separator character appears elsewhere in
+      the name, the server SHOULD create any superior hierarchical names
+      that are needed for the CREATE command to be successfully
+      completed.  In other words, an attempt to create "foo/bar/zap" on
+      a server in which "/" is the hierarchy separator character SHOULD
+      create foo/ and foo/bar/ if they do not already exist.
+
+      If a new mailbox is created with the same name as a mailbox which
+      was deleted, its unique identifiers MUST be greater than any
+      unique identifiers used in the previous incarnation of the mailbox
+      UNLESS the new incarnation has a different unique identifier
+      validity value.  See the description of the UID command for more
+      detail.
+
+   Example:    C: A003 CREATE owatagusiam/
+               S: A003 OK CREATE completed
+               C: A004 CREATE owatagusiam/blurdybloop
+               S: A004 OK CREATE completed
+
+        Note: The interpretation of this example depends on whether
+        "/" was returned as the hierarchy separator from LIST.  If
+        "/" is the hierarchy separator, a new level of hierarchy
+        named "owatagusiam" with a member called "blurdybloop" is
+        created.  Otherwise, two mailboxes at the same hierarchy
+        level are created.
+
+
+6.3.4.  DELETE Command
+
+   Arguments:  mailbox name
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - delete completed
+               NO - delete failure: can't delete mailbox with that name
+               BAD - command unknown or arguments invalid
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 35]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      The DELETE command permanently removes the mailbox with the given
+      name.  A tagged OK response is returned only if the mailbox has
+      been deleted.  It is an error to attempt to delete INBOX or a
+      mailbox name that does not exist.
+
+      The DELETE command MUST NOT remove inferior hierarchical names.
+      For example, if a mailbox "foo" has an inferior "foo.bar"
+      (assuming "." is the hierarchy delimiter character), removing
+      "foo" MUST NOT remove "foo.bar".  It is an error to attempt to
+      delete a name that has inferior hierarchical names and also has
+      the \Noselect mailbox name attribute (see the description of the
+      LIST response for more details).
+
+      It is permitted to delete a name that has inferior hierarchical
+      names and does not have the \Noselect mailbox name attribute.  In
+      this case, all messages in that mailbox are removed, and the name
+      will acquire the \Noselect mailbox name attribute.
+
+      The value of the highest-used unique identifier of the deleted
+      mailbox MUST be preserved so that a new mailbox created with the
+      same name will not reuse the identifiers of the former
+      incarnation, UNLESS the new incarnation has a different unique
+      identifier validity value.  See the description of the UID command
+      for more detail.
+
+   Examples:   C: A682 LIST "" *
+               S: * LIST () "/" blurdybloop
+               S: * LIST (\Noselect) "/" foo
+               S: * LIST () "/" foo/bar
+               S: A682 OK LIST completed
+               C: A683 DELETE blurdybloop
+               S: A683 OK DELETE completed
+               C: A684 DELETE foo
+               S: A684 NO Name "foo" has inferior hierarchical names
+               C: A685 DELETE foo/bar
+               S: A685 OK DELETE Completed
+               C: A686 LIST "" *
+               S: * LIST (\Noselect) "/" foo
+               S: A686 OK LIST completed
+               C: A687 DELETE foo
+               S: A687 OK DELETE Completed
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 36]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+               C: A82 LIST "" *
+               S: * LIST () "." blurdybloop
+               S: * LIST () "." foo
+               S: * LIST () "." foo.bar
+               S: A82 OK LIST completed
+               C: A83 DELETE blurdybloop
+               S: A83 OK DELETE completed
+               C: A84 DELETE foo
+               S: A84 OK DELETE Completed
+               C: A85 LIST "" *
+               S: * LIST () "." foo.bar
+               S: A85 OK LIST completed
+               C: A86 LIST "" %
+               S: * LIST (\Noselect) "." foo
+               S: A86 OK LIST completed
+
+
+6.3.5.  RENAME Command
+
+   Arguments:  existing mailbox name
+               new mailbox name
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - rename completed
+               NO - rename failure: can't rename mailbox with that name,
+                    can't rename to mailbox with that name
+               BAD - command unknown or arguments invalid
+
+      The RENAME command changes the name of a mailbox.  A tagged OK
+      response is returned only if the mailbox has been renamed.  It is
+      an error to attempt to rename from a mailbox name that does not
+      exist or to a mailbox name that already exists.  Any error in
+      renaming will return a tagged NO response.
+
+      If the name has inferior hierarchical names, then the inferior
+      hierarchical names MUST also be renamed.  For example, a rename of
+      "foo" to "zap" will rename "foo/bar" (assuming "/" is the
+      hierarchy delimiter character) to "zap/bar".
+
+      If the server's hierarchy separator character appears in the name,
+      the server SHOULD create any superior hierarchical names that are
+      needed for the RENAME command to complete successfully.  In other
+      words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a
+      server in which "/" is the hierarchy separator character SHOULD
+      create baz/ and baz/rag/ if they do not already exist.
+
+
+
+
+
+Crispin                     Standards Track                    [Page 37]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      The value of the highest-used unique identifier of the old mailbox
+      name MUST be preserved so that a new mailbox created with the same
+      name will not reuse the identifiers of the former incarnation,
+      UNLESS the new incarnation has a different unique identifier
+      validity value.  See the description of the UID command for more
+      detail.
+
+      Renaming INBOX is permitted, and has special behavior.  It moves
+      all messages in INBOX to a new mailbox with the given name,
+      leaving INBOX empty.  If the server implementation supports
+      inferior hierarchical names of INBOX, these are unaffected by a
+      rename of INBOX.
+
+   Examples:   C: A682 LIST "" *
+               S: * LIST () "/" blurdybloop
+               S: * LIST (\Noselect) "/" foo
+               S: * LIST () "/" foo/bar
+               S: A682 OK LIST completed
+               C: A683 RENAME blurdybloop sarasoop
+               S: A683 OK RENAME completed
+               C: A684 RENAME foo zowie
+               S: A684 OK RENAME Completed
+               C: A685 LIST "" *
+               S: * LIST () "/" sarasoop
+               S: * LIST (\Noselect) "/" zowie
+               S: * LIST () "/" zowie/bar
+               S: A685 OK LIST completed
+
+               C: Z432 LIST "" *
+               S: * LIST () "." INBOX
+               S: * LIST () "." INBOX.bar
+               S: Z432 OK LIST completed
+               C: Z433 RENAME INBOX old-mail
+               S: Z433 OK RENAME completed
+               C: Z434 LIST "" *
+               S: * LIST () "." INBOX
+               S: * LIST () "." INBOX.bar
+               S: * LIST () "." old-mail
+               S: Z434 OK LIST completed
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 38]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+6.3.6.  SUBSCRIBE Command
+
+   Arguments:  mailbox
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - subscribe completed
+               NO - subscribe failure: can't subscribe to that name
+               BAD - command unknown or arguments invalid
+
+      The SUBSCRIBE command adds the specified mailbox name to the
+      server's set of "active" or "subscribed" mailboxes as returned by
+      the LSUB command.  This command returns a tagged OK response only
+      if the subscription is successful.
+
+      A server MAY validate the mailbox argument to SUBSCRIBE to verify
+      that it exists.  However, it MUST NOT unilaterally remove an
+      existing mailbox name from the subscription list even if a mailbox
+      by that name no longer exists.
+
+           Note: This requirement is because a server site can
+           choose to routinely remove a mailbox with a well-known
+           name (e.g., "system-alerts") after its contents expire,
+           with the intention of recreating it when new contents
+           are appropriate.
+
+
+   Example:    C: A002 SUBSCRIBE #news.comp.mail.mime
+               S: A002 OK SUBSCRIBE completed
+
+
+6.3.7.  UNSUBSCRIBE Command
+
+   Arguments:  mailbox name
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - unsubscribe completed
+               NO - unsubscribe failure: can't unsubscribe that name
+               BAD - command unknown or arguments invalid
+
+      The UNSUBSCRIBE command removes the specified mailbox name from
+      the server's set of "active" or "subscribed" mailboxes as returned
+      by the LSUB command.  This command returns a tagged OK response
+      only if the unsubscription is successful.
+
+   Example:    C: A002 UNSUBSCRIBE #news.comp.mail.mime
+               S: A002 OK UNSUBSCRIBE completed
+
+
+
+Crispin                     Standards Track                    [Page 39]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+6.3.8.  LIST Command
+
+   Arguments:  reference name
+               mailbox name with possible wildcards
+
+   Responses:  untagged responses: LIST
+
+   Result:     OK - list completed
+               NO - list failure: can't list that reference or name
+               BAD - command unknown or arguments invalid
+
+      The LIST command returns a subset of names from the complete set
+      of all names available to the client.  Zero or more untagged LIST
+      replies are returned, containing the name attributes, hierarchy
+      delimiter, and name; see the description of the LIST reply for
+      more detail.
+
+      The LIST command SHOULD return its data quickly, without undue
+      delay.  For example, it SHOULD NOT go to excess trouble to
+      calculate the \Marked or \Unmarked status or perform other
+      processing; if each name requires 1 second of processing, then a
+      list of 1200 names would take 20 minutes!
+
+      An empty ("" string) reference name argument indicates that the
+      mailbox name is interpreted as by SELECT.  The returned mailbox
+      names MUST match the supplied mailbox name pattern.  A non-empty
+      reference name argument is the name of a mailbox or a level of
+      mailbox hierarchy, and indicates the context in which the mailbox
+      name is interpreted.
+
+      An empty ("" string) mailbox name argument is a special request to
+      return the hierarchy delimiter and the root name of the name given
+      in the reference.  The value returned as the root MAY be the empty
+      string if the reference is non-rooted or is an empty string.  In
+      all cases, a hierarchy delimiter (or NIL if there is no hierarchy)
+      is returned.  This permits a client to get the hierarchy delimiter
+      (or find out that the mailbox names are flat) even when no
+      mailboxes by that name currently exist.
+
+      The reference and mailbox name arguments are interpreted into a
+      canonical form that represents an unambiguous left-to-right
+      hierarchy.  The returned mailbox names will be in the interpreted
+      form.
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 40]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+           Note: The interpretation of the reference argument is
+           implementation-defined.  It depends upon whether the
+           server implementation has a concept of the "current
+           working directory" and leading "break out characters",
+           which override the current working directory.
+
+           For example, on a server which exports a UNIX or NT
+           filesystem, the reference argument contains the current
+           working directory, and the mailbox name argument would
+           contain the name as interpreted in the current working
+           directory.
+
+           If a server implementation has no concept of break out
+           characters, the canonical form is normally the reference
+           name appended with the mailbox name.  Note that if the
+           server implements the namespace convention (section
+           5.1.2), "#" is a break out character and must be treated
+           as such.
+
+           If the reference argument is not a level of mailbox
+           hierarchy (that is, it is a \NoInferiors name), and/or
+           the reference argument does not end with the hierarchy
+           delimiter, it is implementation-dependent how this is
+           interpreted.  For example, a reference of "foo/bar" and
+           mailbox name of "rag/baz" could be interpreted as
+           "foo/bar/rag/baz", "foo/barrag/baz", or "foo/rag/baz".
+           A client SHOULD NOT use such a reference argument except
+           at the explicit request of the user.  A hierarchical
+           browser MUST NOT make any assumptions about server
+           interpretation of the reference unless the reference is
+           a level of mailbox hierarchy AND ends with the hierarchy
+           delimiter.
+
+      Any part of the reference argument that is included in the
+      interpreted form SHOULD prefix the interpreted form.  It SHOULD
+      also be in the same form as the reference name argument.  This
+      rule permits the client to determine if the returned mailbox name
+      is in the context of the reference argument, or if something about
+      the mailbox argument overrode the reference argument.  Without
+      this rule, the client would have to have knowledge of the server's
+      naming semantics including what characters are "breakouts" that
+      override a naming context.
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 41]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+           For example, here are some examples of how references
+           and mailbox names might be interpreted on a UNIX-based
+           server:
+
+               Reference     Mailbox Name  Interpretation
+               ------------  ------------  --------------
+               ~smith/Mail/  foo.*         ~smith/Mail/foo.*
+               archive/      %             archive/%
+               #news.        comp.mail.*   #news.comp.mail.*
+               ~smith/Mail/  /usr/doc/foo  /usr/doc/foo
+               archive/      ~fred/Mail/*  ~fred/Mail/*
+
+           The first three examples demonstrate interpretations in
+           the context of the reference argument.  Note that
+           "~smith/Mail" SHOULD NOT be transformed into something
+           like "/u2/users/smith/Mail", or it would be impossible
+           for the client to determine that the interpretation was
+           in the context of the reference.
+
+      The character "*" is a wildcard, and matches zero or more
+      characters at this position.  The character "%" is similar to "*",
+      but it does not match a hierarchy delimiter.  If the "%" wildcard
+      is the last character of a mailbox name argument, matching levels
+      of hierarchy are also returned.  If these levels of hierarchy are
+      not also selectable mailboxes, they are returned with the
+      \Noselect mailbox name attribute (see the description of the LIST
+      response for more details).
+
+      Server implementations are permitted to "hide" otherwise
+      accessible mailboxes from the wildcard characters, by preventing
+      certain characters or names from matching a wildcard in certain
+      situations.  For example, a UNIX-based server might restrict the
+      interpretation of "*" so that an initial "/" character does not
+      match.
+
+      The special name INBOX is included in the output from LIST, if
+      INBOX is supported by this server for this user and if the
+      uppercase string "INBOX" matches the interpreted reference and
+      mailbox name arguments with wildcards as described above.  The
+      criteria for omitting INBOX is whether SELECT INBOX will return
+      failure; it is not relevant whether the user's real INBOX resides
+      on this or some other server.
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 42]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   Example:    C: A101 LIST "" ""
+               S: * LIST (\Noselect) "/" ""
+               S: A101 OK LIST Completed
+               C: A102 LIST #news.comp.mail.misc ""
+               S: * LIST (\Noselect) "." #news.
+               S: A102 OK LIST Completed
+               C: A103 LIST /usr/staff/jones ""
+               S: * LIST (\Noselect) "/" /
+               S: A103 OK LIST Completed
+               C: A202 LIST ~/Mail/ %
+               S: * LIST (\Noselect) "/" ~/Mail/foo
+               S: * LIST () "/" ~/Mail/meetings
+               S: A202 OK LIST completed
+
+
+6.3.9.  LSUB Command
+
+   Arguments:  reference name
+               mailbox name with possible wildcards
+
+   Responses:  untagged responses: LSUB
+
+   Result:     OK - lsub completed
+               NO - lsub failure: can't list that reference or name
+               BAD - command unknown or arguments invalid
+
+      The LSUB command returns a subset of names from the set of names
+      that the user has declared as being "active" or "subscribed".
+      Zero or more untagged LSUB replies are returned.  The arguments to
+      LSUB are in the same form as those for LIST.
+
+      The returned untagged LSUB response MAY contain different mailbox
+      flags from a LIST untagged response.  If this should happen, the
+      flags in the untagged LIST are considered more authoritative.
+
+      A special situation occurs when using LSUB with the % wildcard.
+      Consider what happens if "foo/bar" (with a hierarchy delimiter of
+      "/") is subscribed but "foo" is not.  A "%" wildcard to LSUB must
+      return foo, not foo/bar, in the LSUB response, and it MUST be
+      flagged with the \Noselect attribute.
+
+      The server MUST NOT unilaterally remove an existing mailbox name
+      from the subscription list even if a mailbox by that name no
+      longer exists.
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 43]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   Example:    C: A002 LSUB "#news." "comp.mail.*"
+               S: * LSUB () "." #news.comp.mail.mime
+               S: * LSUB () "." #news.comp.mail.misc
+               S: A002 OK LSUB completed
+               C: A003 LSUB "#news." "comp.%"
+               S: * LSUB (\NoSelect) "." #news.comp.mail
+               S: A003 OK LSUB completed
+
+
+6.3.10. STATUS Command
+
+   Arguments:  mailbox name
+               status data item names
+
+   Responses:  untagged responses: STATUS
+
+   Result:     OK - status completed
+               NO - status failure: no status for that name
+               BAD - command unknown or arguments invalid
+
+      The STATUS command requests the status of the indicated mailbox.
+      It does not change the currently selected mailbox, nor does it
+      affect the state of any messages in the queried mailbox (in
+      particular, STATUS MUST NOT cause messages to lose the \Recent
+      flag).
+
+      The STATUS command provides an alternative to opening a second
+      IMAP4rev1 connection and doing an EXAMINE command on a mailbox to
+      query that mailbox's status without deselecting the current
+      mailbox in the first IMAP4rev1 connection.
+
+      Unlike the LIST command, the STATUS command is not guaranteed to
+      be fast in its response.  Under certain circumstances, it can be
+      quite slow.  In some implementations, the server is obliged to
+      open the mailbox read-only internally to obtain certain status
+      information.  Also unlike the LIST command, the STATUS command
+      does not accept wildcards.
+
+           Note: The STATUS command is intended to access the
+           status of mailboxes other than the currently selected
+           mailbox.  Because the STATUS command can cause the
+           mailbox to be opened internally, and because this
+           information is available by other means on the selected
+           mailbox, the STATUS command SHOULD NOT be used on the
+           currently selected mailbox.
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 44]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+           The STATUS command MUST NOT be used as a "check for new
+           messages in the selected mailbox" operation (refer to
+           sections 7, 7.3.1, and 7.3.2 for more information about
+           the proper method for new message checking).
+
+           Because the STATUS command is not guaranteed to be fast
+           in its results, clients SHOULD NOT expect to be able to
+           issue many consecutive STATUS commands and obtain
+           reasonable performance.
+
+      The currently defined status data items that can be requested are:
+
+      MESSAGES
+         The number of messages in the mailbox.
+
+      RECENT
+         The number of messages with the \Recent flag set.
+
+      UIDNEXT
+         The next unique identifier value of the mailbox.  Refer to
+         section 2.3.1.1 for more information.
+
+      UIDVALIDITY
+         The unique identifier validity value of the mailbox.  Refer to
+         section 2.3.1.1 for more information.
+
+      UNSEEN
+         The number of messages which do not have the \Seen flag set.
+
+
+   Example:    C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
+               S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
+               S: A042 OK STATUS completed
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 45]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+6.3.11. APPEND Command
+
+   Arguments:  mailbox name
+               OPTIONAL flag parenthesized list
+               OPTIONAL date/time string
+               message literal
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - append completed
+               NO - append error: can't append to that mailbox, error
+                    in flags or date/time or message text
+               BAD - command unknown or arguments invalid
+
+      The APPEND command appends the literal argument as a new message
+      to the end of the specified destination mailbox.  This argument
+      SHOULD be in the format of an [RFC-2822] message.  8-bit
+      characters are permitted in the message.  A server implementation
+      that is unable to preserve 8-bit data properly MUST be able to
+      reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB]
+      content transfer encoding.
+
+           Note: There MAY be exceptions, e.g., draft messages, in
+           which required [RFC-2822] header lines are omitted in
+           the message literal argument to APPEND.  The full
+           implications of doing so MUST be understood and
+           carefully weighed.
+
+      If a flag parenthesized list is specified, the flags SHOULD be set
+      in the resulting message; otherwise, the flag list of the
+      resulting message is set to empty by default.  In either case, the
+      Recent flag is also set.
+
+      If a date-time is specified, the internal date SHOULD be set in
+      the resulting message; otherwise, the internal date of the
+      resulting message is set to the current date and time by default.
+
+      If the append is unsuccessful for any reason, the mailbox MUST be
+      restored to its state before the APPEND attempt; no partial
+      appending is permitted.
+
+      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 send the response code "[TRYCREATE]" as the prefix of
+      the text of the tagged NO response.  This gives a hint to the
+      client that it can attempt a CREATE command and retry the APPEND
+      if the CREATE is successful.
+
+
+
+Crispin                     Standards Track                    [Page 46]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      If the mailbox is currently selected, the normal new message
+      actions SHOULD occur.  Specifically, the server SHOULD notify the
+      client immediately via an untagged EXISTS response.  If the server
+      does not do so, the client MAY issue a NOOP command (or failing
+      that, a CHECK command) after one or more APPEND commands.
+
+   Example:    C: A003 APPEND saved-messages (\Seen) {310}
+               S: + Ready for literal data
+               C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
+               C: From: Fred Foobar <foobar@Blurdybloop.COM>
+               C: Subject: afternoon meeting
+               C: To: mooch@owatagu.siam.edu
+               C: Message-Id: <B27397-0100000@Blurdybloop.COM>
+               C: MIME-Version: 1.0
+               C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+               C:
+               C: Hello Joe, do you think we can meet at 3:30 tomorrow?
+               C:
+               S: A003 OK APPEND completed
+
+        Note: The APPEND command is not used for message delivery,
+        because it does not provide a mechanism to transfer [SMTP]
+        envelope information.
+
+6.4.    Client Commands - Selected State
+
+   In the selected state, commands that manipulate messages in a mailbox
+   are permitted.
+
+   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+   and the authenticated state commands (SELECT, EXAMINE, CREATE,
+   DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and
+   APPEND), the following commands are valid in the selected state:
+   CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID.
+
+6.4.1.  CHECK Command
+
+   Arguments:  none
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - check completed
+               BAD - command unknown or arguments invalid
+
+      The CHECK command requests a checkpoint of the currently selected
+      mailbox.  A checkpoint refers to any implementation-dependent
+      housekeeping associated with the mailbox (e.g., resolving the
+      server's in-memory state of the mailbox with the state on its
+
+
+
+Crispin                     Standards Track                    [Page 47]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      disk) that is not normally executed as part of each command.  A
+      checkpoint MAY take a non-instantaneous amount of real time to
+      complete.  If a server implementation has no such housekeeping
+      considerations, CHECK is equivalent to NOOP.
+
+      There is no guarantee that an EXISTS untagged response will happen
+      as a result of CHECK.  NOOP, not CHECK, SHOULD be used for new
+      message polling.
+
+   Example:    C: FXXZ CHECK
+               S: FXXZ OK CHECK Completed
+
+
+6.4.2.  CLOSE Command
+
+   Arguments:  none
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - close completed, now in authenticated state
+               BAD - command unknown or arguments invalid
+
+      The CLOSE command permanently removes all messages that have the
+      \Deleted flag set from the currently selected mailbox, and returns
+      to the authenticated state from the selected state.  No untagged
+      EXPUNGE responses are sent.
+
+      No messages are removed, and no error is given, if the mailbox is
+      selected by an EXAMINE command or is otherwise selected read-only.
+
+      Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT
+      command MAY be issued without previously issuing a CLOSE command.
+      The SELECT, EXAMINE, and LOGOUT commands implicitly close the
+      currently selected mailbox without doing an expunge.  However,
+      when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
+      sequence is considerably faster than an EXPUNGE-LOGOUT or
+      EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
+      client would probably ignore) are sent.
+
+   Example:    C: A341 CLOSE
+               S: A341 OK CLOSE completed
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 48]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+6.4.3.  EXPUNGE Command
+
+   Arguments:  none
+
+   Responses:  untagged responses: EXPUNGE
+
+   Result:     OK - expunge completed
+               NO - expunge failure: can't expunge (e.g., permission
+                    denied)
+               BAD - command unknown or arguments invalid
+
+      The EXPUNGE command permanently removes all messages that have the
+      \Deleted flag set from the currently selected mailbox.  Before
+      returning an OK to the client, an untagged EXPUNGE response is
+      sent for each message that is removed.
+
+   Example:    C: A202 EXPUNGE
+               S: * 3 EXPUNGE
+               S: * 3 EXPUNGE
+               S: * 5 EXPUNGE
+               S: * 8 EXPUNGE
+               S: A202 OK EXPUNGE completed
+
+        Note: In this example, messages 3, 4, 7, and 11 had the
+        \Deleted flag set.  See the description of the EXPUNGE
+        response for further explanation.
+
+
+6.4.4.  SEARCH Command
+
+   Arguments:  OPTIONAL [CHARSET] specification
+               searching criteria (one or more)
+
+   Responses:  REQUIRED untagged response: SEARCH
+
+   Result:     OK - search completed
+               NO - search error: can't search that [CHARSET] or
+                    criteria
+               BAD - command unknown or arguments invalid
+
+      The SEARCH command searches the mailbox for messages that match
+      the given searching criteria.  Searching criteria consist of one
+      or more search keys.  The untagged SEARCH response from the server
+      contains a listing of message sequence numbers corresponding to
+      those messages that match the searching criteria.
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 49]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      When multiple keys are specified, the result is the intersection
+      (AND function) of all the messages that match those keys.  For
+      example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers
+      to all deleted messages from Smith that were placed in the mailbox
+      since February 1, 1994.  A search key can also be a parenthesized
+      list of one or more search keys (e.g., for use with the OR and NOT
+      keys).
+
+      Server implementations MAY exclude [MIME-IMB] body parts with
+      terminal content media types other than TEXT and MESSAGE from
+      consideration in SEARCH matching.
+
+      The OPTIONAL [CHARSET] specification consists of the word
+      "CHARSET" followed by a registered [CHARSET].  It indicates the
+      [CHARSET] of the strings that appear in the search criteria.
+      [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
+      [RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing
+      text in a [CHARSET] other than US-ASCII.  US-ASCII MUST be
+      supported; other [CHARSET]s MAY be supported.
+
+      If the server does not support the specified [CHARSET], it MUST
+      return a tagged NO response (not a BAD).  This response SHOULD
+      contain the BADCHARSET response code, which MAY list the
+      [CHARSET]s supported by the server.
+
+      In all search keys that use strings, a message matches the key if
+      the string is a substring of the field.  The matching is
+      case-insensitive.
+
+      The defined search keys are as follows.  Refer to the Formal
+      Syntax section for the precise syntactic definitions of the
+      arguments.
+
+      <sequence set>
+         Messages with message sequence numbers corresponding to the
+         specified message sequence number set.
+
+      ALL
+         All messages in the mailbox; the default initial key for
+         ANDing.
+
+      ANSWERED
+         Messages with the \Answered flag set.
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 50]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      BCC <string>
+         Messages that contain the specified string in the envelope
+         structure's BCC field.
+
+      BEFORE <date>
+         Messages whose internal date (disregarding time and timezone)
+         is earlier than the specified date.
+
+      BODY <string>
+         Messages that contain the specified string in the body of the
+         message.
+
+      CC <string>
+         Messages that contain the specified string in the envelope
+         structure's CC field.
+
+      DELETED
+         Messages with the \Deleted flag set.
+
+      DRAFT
+         Messages with the \Draft flag set.
+
+      FLAGGED
+         Messages with the \Flagged flag set.
+
+      FROM <string>
+         Messages that contain the specified string in the envelope
+         structure's FROM field.
+
+      HEADER <field-name> <string>
+         Messages that have a header with the specified field-name (as
+         defined in [RFC-2822]) and that contains the specified string
+         in the text of the header (what comes after the colon).  If the
+         string to search is zero-length, this matches all messages that
+         have a header line with the specified field-name regardless of
+         the contents.
+
+      KEYWORD <flag>
+         Messages with the specified keyword flag set.
+
+      LARGER <n>
+         Messages with an [RFC-2822] size larger than the specified
+         number of octets.
+
+      NEW
+         Messages that have the \Recent flag set but not the \Seen flag.
+         This is functionally equivalent to "(RECENT UNSEEN)".
+
+
+
+
+Crispin                     Standards Track                    [Page 51]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      NOT <search-key>
+         Messages that do not match the specified search key.
+
+      OLD
+         Messages that do not have the \Recent flag set.  This is
+         functionally equivalent to "NOT RECENT" (as opposed to "NOT
+         NEW").
+
+      ON <date>
+         Messages whose internal date (disregarding time and timezone)
+         is within the specified date.
+
+      OR <search-key1> <search-key2>
+         Messages that match either search key.
+
+      RECENT
+         Messages that have the \Recent flag set.
+
+      SEEN
+         Messages that have the \Seen flag set.
+
+      SENTBEFORE <date>
+         Messages whose [RFC-2822] Date: header (disregarding time and
+         timezone) is earlier than the specified date.
+
+      SENTON <date>
+         Messages whose [RFC-2822] Date: header (disregarding time and
+         timezone) is within the specified date.
+
+      SENTSINCE <date>
+         Messages whose [RFC-2822] Date: header (disregarding time and
+         timezone) is within or later than the specified date.
+
+      SINCE <date>
+         Messages whose internal date (disregarding time and timezone)
+         is within or later than the specified date.
+
+      SMALLER <n>
+         Messages with an [RFC-2822] size smaller than the specified
+         number of octets.
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 52]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      SUBJECT <string>
+         Messages that contain the specified string in the envelope
+         structure's SUBJECT field.
+
+      TEXT <string>
+         Messages that contain the specified string in the header or
+         body of the message.
+
+      TO <string>
+         Messages that contain the specified string in the envelope
+         structure's TO field.
+
+      UID <sequence set>
+         Messages with unique identifiers corresponding to the specified
+         unique identifier set.  Sequence set ranges are permitted.
+
+      UNANSWERED
+         Messages that do not have the \Answered flag set.
+
+      UNDELETED
+         Messages that do not have the \Deleted flag set.
+
+      UNDRAFT
+         Messages that do not have the \Draft flag set.
+
+      UNFLAGGED
+         Messages that do not have the \Flagged flag set.
+
+      UNKEYWORD <flag>
+         Messages that do not have the specified keyword flag set.
+
+      UNSEEN
+         Messages that do not have the \Seen flag set.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 53]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   Example:    C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
+               S: * SEARCH 2 84 882
+               S: A282 OK SEARCH completed
+               C: A283 SEARCH TEXT "string not in mailbox"
+               S: * SEARCH
+               S: A283 OK SEARCH completed
+               C: A284 SEARCH CHARSET UTF-8 TEXT {6}
+               C: XXXXXX
+               S: * SEARCH 43
+               S: A284 OK SEARCH completed
+
+        Note: Since this document is restricted to 7-bit ASCII
+        text, it is not possible to show actual UTF-8 data.  The
+        "XXXXXX" is a placeholder for what would be 6 octets of
+        8-bit data in an actual transaction.
+
+
+6.4.5.  FETCH Command
+
+   Arguments:  sequence set
+               message data item names or macro
+
+   Responses:  untagged responses: FETCH
+
+   Result:     OK - fetch completed
+               NO - fetch error: can't fetch that data
+               BAD - command unknown or arguments invalid
+
+      The FETCH command retrieves data associated with a message in the
+      mailbox.  The data items to be fetched can be either a single atom
+      or a parenthesized list.
+
+      Most data items, identified in the formal syntax under the
+      msg-att-static rule, are static and MUST NOT change for any
+      particular message.  Other data items, identified in the formal
+      syntax under the msg-att-dynamic rule, MAY change, either as a
+      result of a STORE command or due to external events.
+
+           For example, if a client receives an ENVELOPE for a
+           message when it already knows the envelope, it can
+           safely ignore the newly transmitted envelope.
+
+      There are three macros which specify commonly-used sets of data
+      items, and can be used instead of data items.  A macro must be
+      used by itself, and not in conjunction with other macros or data
+      items.
+
+
+
+
+
+Crispin                     Standards Track                    [Page 54]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      ALL
+         Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
+
+      FAST
+         Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE)
+
+      FULL
+         Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE
+         BODY)
+
+      The currently defined data items that can be fetched are:
+
+      BODY
+         Non-extensible form of BODYSTRUCTURE.
+
+      BODY[<section>]<<partial>>
+         The text of a particular body section.  The section
+         specification is a set of zero or more part specifiers
+         delimited by periods.  A part specifier is either a part number
+         or one of the following: HEADER, HEADER.FIELDS,
+         HEADER.FIELDS.NOT, MIME, and TEXT.  An empty section
+         specification refers to the entire message, including the
+         header.
+
+         Every message has at least one part number.  Non-[MIME-IMB]
+         messages, and non-multipart [MIME-IMB] messages with no
+         encapsulated message, only have a part 1.
+
+         Multipart messages are assigned consecutive part numbers, as
+         they occur in the message.  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.
+
+         A part of type MESSAGE/RFC822 also has nested part numbers,
+         referring to parts of the MESSAGE part's body.
+
+         The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part
+         specifiers can be the sole part specifier or can be prefixed by
+         one or more numeric part specifiers, provided that the numeric
+         part specifier refers to a part of type MESSAGE/RFC822.  The
+         MIME part specifier MUST be prefixed by one or more numeric
+         part specifiers.
+
+         The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part
+         specifiers refer to the [RFC-2822] header of the message or of
+         an encapsulated [MIME-IMT] MESSAGE/RFC822 message.
+         HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of
+         field-name (as defined in [RFC-2822]) names, and return a
+
+
+
+Crispin                     Standards Track                    [Page 55]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+         subset of the header.  The subset returned by HEADER.FIELDS
+         contains only those header fields with a field-name that
+         matches one of the names in the list; similarly, the subset
+         returned by HEADER.FIELDS.NOT contains only the header fields
+         with a non-matching field-name.  The field-matching is
+         case-insensitive but otherwise exact.  Subsetting does not
+         exclude the [RFC-2822] delimiting blank line between the header
+         and the body; the blank line is included in all header fetches,
+         except in the case of a message which has no body and no blank
+         line.
+
+         The MIME part specifier refers to the [MIME-IMB] header for
+         this part.
+
+         The TEXT part specifier refers to the text body of the message,
+         omitting the [RFC-2822] header.
+
+            Here is an example of a complex message with some of its
+            part specifiers:
+
+       HEADER     ([RFC-2822] header of the message)
+       TEXT       ([RFC-2822] text body of the message) MULTIPART/MIXED
+       1          TEXT/PLAIN
+       2          APPLICATION/OCTET-STREAM
+       3          MESSAGE/RFC822
+       3.HEADER   ([RFC-2822] header of the message)
+       3.TEXT     ([RFC-2822] text body of the message) MULTIPART/MIXED
+       3.1        TEXT/PLAIN
+       3.2        APPLICATION/OCTET-STREAM
+       4          MULTIPART/MIXED
+       4.1        IMAGE/GIF
+       4.1.MIME   ([MIME-IMB] header for the IMAGE/GIF)
+       4.2        MESSAGE/RFC822
+       4.2.HEADER ([RFC-2822] header of the message)
+       4.2.TEXT   ([RFC-2822] text body of the message) MULTIPART/MIXED
+       4.2.1      TEXT/PLAIN
+       4.2.2      MULTIPART/ALTERNATIVE
+       4.2.2.1    TEXT/PLAIN
+       4.2.2.2    TEXT/RICHTEXT
+
+
+         It is possible to fetch a substring of the designated text.
+         This is done by appending an open angle bracket ("<"), the
+         octet position of the first desired octet, a period, the
+         maximum number of octets desired, and a close angle bracket
+         (">") to the part specifier.  If the starting octet is beyond
+         the end of the text, an empty string is returned.
+
+
+
+
+Crispin                     Standards Track                    [Page 56]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+         Any partial fetch that attempts to read beyond the end of the
+         text is truncated as appropriate.  A partial fetch that starts
+         at octet 0 is returned as a partial fetch, even if this
+         truncation happened.
+
+            Note: This means that BODY[]<0.2048> of a 1500-octet message
+            will return BODY[]<0> with a literal of size 1500, not
+            BODY[].
+
+            Note: A substring fetch of a HEADER.FIELDS or
+            HEADER.FIELDS.NOT part specifier is calculated after
+            subsetting the header.
+
+         The \Seen flag is implicitly set; if this causes the flags to
+         change, they SHOULD be included as part of the FETCH responses.
+
+      BODY.PEEK[<section>]<<partial>>
+         An alternate form of BODY[<section>] that does not implicitly
+         set the \Seen flag.
+
+      BODYSTRUCTURE
+         The [MIME-IMB] body structure of the message.  This is computed
+         by the server by parsing the [MIME-IMB] header fields in the
+         [RFC-2822] header and [MIME-IMB] headers.
+
+      ENVELOPE
+         The envelope structure of the message.  This is computed by the
+         server by parsing the [RFC-2822] header into the component
+         parts, defaulting various fields as necessary.
+
+      FLAGS
+         The flags that are set for this message.
+
+      INTERNALDATE
+         The internal date of the message.
+
+      RFC822
+         Functionally equivalent to BODY[], differing in the syntax of
+         the resulting untagged FETCH data (RFC822 is returned).
+
+      RFC822.HEADER
+         Functionally equivalent to BODY.PEEK[HEADER], differing in the
+         syntax of the resulting untagged FETCH data (RFC822.HEADER is
+         returned).
+
+      RFC822.SIZE
+         The [RFC-2822] size of the message.
+
+
+
+
+Crispin                     Standards Track                    [Page 57]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      RFC822.TEXT
+         Functionally equivalent to BODY[TEXT], differing in the syntax
+         of the resulting untagged FETCH data (RFC822.TEXT is returned).
+
+      UID
+         The unique identifier for the message.
+
+
+   Example:    C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
+               S: * 2 FETCH ....
+               S: * 3 FETCH ....
+               S: * 4 FETCH ....
+               S: A654 OK FETCH completed
+
+
+6.4.6.  STORE Command
+
+   Arguments:  sequence set
+               message data item name
+               value for message data item
+
+   Responses:  untagged responses: FETCH
+
+   Result:     OK - store completed
+               NO - store error: can't store that data
+               BAD - command unknown or arguments invalid
+
+      The STORE command alters data associated with a message in the
+      mailbox.  Normally, STORE will return the updated value of the
+      data with an untagged FETCH response.  A suffix of ".SILENT" in
+      the data item name prevents the untagged FETCH, and the server
+      SHOULD assume that the client has determined the updated value
+      itself or does not care about the updated value.
+
+           Note: Regardless of whether or not the ".SILENT" suffix
+           was used, the server SHOULD send an untagged FETCH
+           response if a change to a message's flags from an
+           external source is observed.  The intent is that the
+           status of the flags is determinate without a race
+           condition.
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 58]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      The currently defined data items that can be stored are:
+
+      FLAGS <flag list>
+         Replace the flags for the message (other than \Recent) with the
+         argument.  The new value of the flags is returned as if a FETCH
+         of those flags was done.
+
+      FLAGS.SILENT <flag list>
+         Equivalent to FLAGS, but without returning a new value.
+
+      +FLAGS <flag list>
+         Add the argument to the flags for the message.  The new value
+         of the flags is returned as if a FETCH of those flags was done.
+
+      +FLAGS.SILENT <flag list>
+         Equivalent to +FLAGS, but without returning a new value.
+
+      -FLAGS <flag list>
+         Remove the argument from the flags for the message.  The new
+         value of the flags is returned as if a FETCH of those flags was
+         done.
+
+      -FLAGS.SILENT <flag list>
+         Equivalent to -FLAGS, but without returning a new value.
+
+
+   Example:    C: A003 STORE 2:4 +FLAGS (\Deleted)
+               S: * 2 FETCH (FLAGS (\Deleted \Seen))
+               S: * 3 FETCH (FLAGS (\Deleted))
+               S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen))
+               S: A003 OK STORE completed
+
+
+6.4.7.  COPY Command
+
+   Arguments:  sequence set
+               mailbox name
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - copy completed
+               NO - copy error: can't copy those messages or to that
+                    name
+               BAD - command unknown or arguments invalid
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 59]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      The COPY command copies the specified message(s) to the end of the
+      specified destination mailbox.  The flags and internal date of the
+      message(s) SHOULD be preserved, and the Recent flag SHOULD be set,
+      in the copy.
+
+      If the destination mailbox does not exist, a server 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 send the response code "[TRYCREATE]" as the prefix of
+      the text of the tagged NO response.  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, server
+      implementations MUST restore the destination mailbox to its state
+      before the COPY attempt.
+
+   Example:    C: A003 COPY 2:4 MEETING
+               S: A003 OK COPY completed
+
+
+6.4.8.  UID Command
+
+   Arguments:  command name
+               command arguments
+
+   Responses:  untagged responses: FETCH, SEARCH
+
+   Result:     OK - UID command completed
+               NO - UID command error
+               BAD - command unknown or arguments invalid
+
+      The UID command has two forms.  In the first form, it takes as its
+      arguments a COPY, FETCH, or STORE command with arguments
+      appropriate for the associated command.  However, the numbers in
+      the sequence set argument are unique identifiers instead of
+      message sequence numbers.  Sequence set ranges are permitted, but
+      there is no guarantee that unique identifiers will be contiguous.
+
+      A non-existent unique identifier is ignored without any error
+      message generated.  Thus, it is possible for a UID FETCH command
+      to return an OK without any data or a UID COPY or UID STORE to
+      return an OK without performing any operations.
+
+      In the second form, the UID command takes a SEARCH command with
+      SEARCH command arguments.  The interpretation of the arguments is
+      the same as with SEARCH; however, the numbers returned in a SEARCH
+      response for a UID SEARCH command are unique identifiers instead
+
+
+
+Crispin                     Standards Track                    [Page 60]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      of message sequence numbers.  For example, the command UID SEARCH
+      1:100 UID 443:557 returns the unique identifiers corresponding to
+      the intersection of two sequence sets, the message sequence number
+      range 1:100 and the UID range 443:557.
+
+           Note: in the above example, the UID range 443:557
+           appears.  The same comment about a non-existent unique
+           identifier being ignored without any error message also
+           applies here.  Hence, even if neither UID 443 or 557
+           exist, this range is valid and would include an existing
+           UID 495.
+
+           Also note that a UID range of 559:* always includes the
+           UID of the last message in the mailbox, even if 559 is
+           higher than any assigned UID value.  This is because the
+           contents of a range are independent of the order of the
+           range endpoints.  Thus, any UID range with * as one of
+           the endpoints indicates at least one message (the
+           message with the highest numbered UID), unless the
+           mailbox is empty.
+
+      The number after the "*" in an untagged FETCH response is always a
+      message sequence number, not a unique identifier, even for a UID
+      command response.  However, server implementations MUST implicitly
+      include the UID message data item as part of any FETCH response
+      caused by a UID command, regardless of whether a UID was specified
+      as a message data item to the FETCH.
+
+
+      Note: The rule about including the UID message data item as part
+      of a FETCH response primarily applies to the UID FETCH and UID
+      STORE commands, including a UID FETCH command that does not
+      include UID as a message data item.  Although it is unlikely that
+      the other UID commands will cause an untagged FETCH, this rule
+      applies to these commands as well.
+
+   Example:    C: A999 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: A999 OK UID FETCH completed
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 61]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+6.5.    Client Commands - Experimental/Expansion
+
+
+6.5.1.  X<atom> Command
+
+   Arguments:  implementation defined
+
+   Responses:  implementation defined
+
+   Result:     OK - command completed
+               NO - failure
+               BAD - command unknown or arguments invalid
+
+      Any command prefixed with an X is an experimental command.
+      Commands which are not part of this specification, a standard or
+      standards-track revision of this specification, or an
+      IESG-approved experimental protocol, MUST use the X prefix.
+
+      Any added untagged responses issued by an experimental command
+      MUST also be prefixed with an X.  Server implementations MUST NOT
+      send any such untagged responses, unless the client requested it
+      by issuing the associated experimental command.
+
+   Example:    C: a441 CAPABILITY
+               S: * CAPABILITY IMAP4rev1 XPIG-LATIN
+               S: a441 OK CAPABILITY completed
+               C: A442 XPIG-LATIN
+               S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
+               S: A442 OK XPIG-LATIN ompleted-cay
+
+7.      Server Responses
+
+   Server responses are in three forms: status responses, server data,
+   and command continuation request.  The information contained in a
+   server response, identified by "Contents:" in the response
+   descriptions below, is described by function, not by syntax.  The
+   precise syntax of server responses is described in the Formal Syntax
+   section.
+
+   The client MUST be prepared to accept any response at all times.
+
+   Status responses can be tagged or untagged.  Tagged status responses
+   indicate the completion result (OK, NO, or BAD status) of a client
+   command, and have a tag matching the command.
+
+   Some status responses, and all server data, are untagged.  An
+   untagged response is indicated by the token "*" instead of a tag.
+   Untagged status responses indicate server greeting, or server status
+
+
+
+Crispin                     Standards Track                    [Page 62]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   that does not indicate the completion of a command (for example, an
+   impending system shutdown alert).  For historical reasons, untagged
+   server data responses are also called "unsolicited data", although
+   strictly speaking, only unilateral server data is truly
+   "unsolicited".
+
+   Certain server data MUST be recorded by the client when it is
+   received; this is noted in the description of that data.  Such data
+   conveys critical information which affects the interpretation of all
+   subsequent commands and responses (e.g., updates reflecting the
+   creation or destruction of messages).
+
+   Other server data SHOULD be recorded for later reference; if the
+   client does not need to record the data, or if recording the data has
+   no obvious purpose (e.g., a SEARCH response when no SEARCH command is
+   in progress), the data SHOULD be ignored.
+
+   An example of unilateral untagged server data occurs when the IMAP
+   connection is in the selected state.  In the selected state, the
+   server checks the mailbox for new messages as part of command
+   execution.  Normally, this is part of the execution of every command;
+   hence, a NOOP command suffices to check for new messages.  If new
+   messages are found, the server sends untagged EXISTS and RECENT
+   responses reflecting the new size of the mailbox.  Server
+   implementations that offer multiple simultaneous access to the same
+   mailbox SHOULD also send appropriate unilateral untagged FETCH and
+   EXPUNGE responses if another agent changes the state of any message
+   flags or expunges any messages.
+
+   Command continuation request responses use the token "+" instead of a
+   tag.  These responses are sent by the server to indicate acceptance
+   of an incomplete client command and readiness for the remainder of
+   the command.
+
+7.1.    Server Responses - Status Responses
+
+   Status responses are OK, NO, BAD, PREAUTH and BYE.  OK, NO, and BAD
+   can be tagged or untagged.  PREAUTH and BYE are always untagged.
+
+   Status responses MAY include an OPTIONAL "response code".  A response
+   code consists of data inside square brackets in the form of an atom,
+   possibly followed by a space and arguments.  The response code
+   contains additional information or status codes for client software
+   beyond the OK/NO/BAD condition, and are defined when there is a
+   specific action that a client can take based upon the additional
+   information.
+
+
+
+
+
+Crispin                     Standards Track                    [Page 63]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   The currently defined response codes are:
+
+      ALERT
+
+         The human-readable text contains a special alert that MUST be
+         presented to the user in a fashion that calls the user's
+         attention to the message.
+
+      BADCHARSET
+
+         Optionally followed by a parenthesized list of charsets.  A
+         SEARCH failed because the given charset is not supported by
+         this implementation.  If the optional list of charsets is
+         given, this lists the charsets that are supported by this
+         implementation.
+
+      CAPABILITY
+
+         Followed by a list of capabilities.  This can appear in the
+         initial OK or PREAUTH response to transmit an initial
+         capabilities list.  This makes it unnecessary for a client to
+         send a separate CAPABILITY command if it recognizes this
+         response.
+
+      PARSE
+
+         The human-readable text represents an error in parsing the
+         [RFC-2822] header or [MIME-IMB] headers of a message in the
+         mailbox.
+
+      PERMANENTFLAGS
+
+         Followed by a parenthesized list of flags, indicates which of
+         the known flags the client can change permanently.  Any flags
+         that are in the FLAGS untagged response, but not the
+         PERMANENTFLAGS list, can not be set permanently.  If the client
+         attempts to STORE a flag that is not in the PERMANENTFLAGS
+         list, the server will either ignore the change or store the
+         state change for the remainder of the current session only.
+         The PERMANENTFLAGS list can also include the special flag \*,
+         which indicates that it is possible to create new keywords by
+         attempting to store those flags in the mailbox.
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 64]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      READ-ONLY
+
+         The mailbox is selected read-only, or its access while selected
+         has changed from read-write to read-only.
+
+      READ-WRITE
+
+         The mailbox is selected read-write, or its access while
+         selected has changed from read-only to read-write.
+
+      TRYCREATE
+
+         An APPEND or COPY attempt is failing because the target mailbox
+         does not exist (as opposed to some other reason).  This is a
+         hint to the client that the operation can succeed if the
+         mailbox is first created by the CREATE command.
+
+      UIDNEXT
+
+         Followed by a decimal number, indicates the next unique
+         identifier value.  Refer to section 2.3.1.1 for more
+         information.
+
+      UIDVALIDITY
+
+         Followed by a decimal number, indicates the unique identifier
+         validity value.  Refer to section 2.3.1.1 for more information.
+
+      UNSEEN
+
+         Followed by a decimal number, indicates the number of the first
+         message without the \Seen flag set.
+
+      Additional response codes defined by particular client or server
+      implementations SHOULD be prefixed with an "X" until they are
+      added to a revision of this protocol.  Client implementations
+      SHOULD ignore response codes that they do not recognize.
+
+7.1.1.  OK Response
+
+   Contents:   OPTIONAL response code
+               human-readable text
+
+      The OK response indicates an information message from the server.
+      When tagged, it indicates successful completion of the associated
+      command.  The human-readable text MAY be presented to the user as
+      an information message.  The untagged form indicates an
+
+
+
+
+Crispin                     Standards Track                    [Page 65]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      information-only message; the nature of the information MAY be
+      indicated by a response code.
+
+      The untagged form is also used as one of three possible greetings
+      at connection startup.  It indicates that the connection is not
+      yet authenticated and that a LOGIN command is needed.
+
+   Example:    S: * OK IMAP4rev1 server ready
+               C: A001 LOGIN fred blurdybloop
+               S: * OK [ALERT] System shutdown in 10 minutes
+               S: A001 OK LOGIN Completed
+
+
+7.1.2.  NO Response
+
+   Contents:   OPTIONAL response code
+               human-readable text
+
+      The NO response indicates an operational error message from the
+      server.  When tagged, it indicates unsuccessful completion of the
+      associated command.  The untagged form indicates a warning; the
+      command can still complete successfully.  The human-readable text
+      describes the condition.
+
+   Example:    C: A222 COPY 1:2 owatagusiam
+               S: * NO Disk is 98% full, please delete unnecessary data
+               S: A222 OK COPY completed
+               C: A223 COPY 3:200 blurdybloop
+               S: * NO Disk is 98% full, please delete unnecessary data
+               S: * NO Disk is 99% full, please delete unnecessary data
+               S: A223 NO COPY failed: disk is full
+
+
+7.1.3.  BAD Response
+
+   Contents:   OPTIONAL response code
+               human-readable text
+
+      The BAD response indicates an error message from the server.  When
+      tagged, it reports a protocol-level error in the client's command;
+      the tag indicates the command that caused the error.  The untagged
+      form indicates a protocol-level error for which the associated
+      command can not be determined; it can also indicate an internal
+      server failure.  The human-readable text describes the condition.
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 66]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   Example:    C: ...very long command line...
+               S: * BAD Command line too long
+               C: ...empty line...
+               S: * BAD Empty command line
+               C: A443 EXPUNGE
+               S: * BAD Disk crash, attempting salvage to a new disk!
+               S: * OK Salvage successful, no data lost
+               S: A443 OK Expunge completed
+
+
+7.1.4.  PREAUTH Response
+
+   Contents:   OPTIONAL response code
+               human-readable text
+
+      The PREAUTH response is always untagged, and is one of three
+      possible greetings at connection startup.  It indicates that the
+      connection has already been authenticated by external means; thus
+      no LOGIN command is needed.
+
+   Example:    S: * PREAUTH IMAP4rev1 server logged in as Smith
+
+
+7.1.5.  BYE Response
+
+   Contents:   OPTIONAL response code
+               human-readable text
+
+      The BYE response is always untagged, and indicates that the server
+      is about to close the connection.  The human-readable text MAY be
+      displayed to the user in a status report by the client.  The BYE
+      response is sent under one of four conditions:
+
+         1) as part of a normal logout sequence.  The server will close
+            the connection after sending the tagged OK response to the
+            LOGOUT command.
+
+         2) as a panic shutdown announcement.  The server closes the
+            connection immediately.
+
+         3) as an announcement of an inactivity autologout.  The server
+            closes the connection immediately.
+
+         4) as one of three possible greetings at connection startup,
+            indicating that the server is not willing to accept a
+            connection from this client.  The server closes the
+            connection immediately.
+
+
+
+
+Crispin                     Standards Track                    [Page 67]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      The difference between a BYE that occurs as part of a normal
+      LOGOUT sequence (the first case) and a BYE that occurs because of
+      a failure (the other three cases) is that the connection closes
+      immediately in the failure case.  In all cases the client SHOULD
+      continue to read response data from the server until the
+      connection is closed; this will ensure that any pending untagged
+      or completion responses are read and processed.
+
+   Example:    S: * BYE Autologout; idle for too long
+
+7.2.    Server Responses - Server and Mailbox Status
+
+   These responses are always untagged.  This is how server and mailbox
+   status data are transmitted from the server to the client.  Many of
+   these responses typically result from a command with the same name.
+
+7.2.1.  CAPABILITY Response
+
+   Contents:   capability listing
+
+      The CAPABILITY response occurs as a result of a CAPABILITY
+      command.  The capability listing contains a space-separated
+      listing of capability names that the server supports.  The
+      capability listing MUST include the atom "IMAP4rev1".
+
+      In addition, client and server implementations MUST implement the
+      STARTTLS, LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
+      capabilities.  See the Security Considerations section for
+      important information.
+
+      A capability name which begins with "AUTH=" indicates that the
+      server supports that particular authentication mechanism.
+
+      The LOGINDISABLED capability indicates that the LOGIN command is
+      disabled, and that the server will respond with a tagged NO
+      response to any attempt to use the LOGIN command even if the user
+      name and password are valid.  An IMAP client MUST NOT issue the
+      LOGIN command if the server advertises the LOGINDISABLED
+      capability.
+
+      Other capability names indicate that the server supports an
+      extension, revision, or amendment to the IMAP4rev1 protocol.
+      Server responses MUST conform to this document until the client
+      issues a command that uses the associated capability.
+
+      Capability names MUST either begin with "X" or be standard or
+      standards-track IMAP4rev1 extensions, revisions, or amendments
+      registered with IANA.  A server MUST NOT offer unregistered or
+
+
+
+Crispin                     Standards Track                    [Page 68]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      non-standard capability names, unless such names are prefixed with
+      an "X".
+
+      Client implementations SHOULD NOT require any capability name
+      other than "IMAP4rev1", and MUST ignore any unknown capability
+      names.
+
+      A server MAY send capabilities automatically, by using the
+      CAPABILITY response code in the initial PREAUTH or OK responses,
+      and by sending an updated CAPABILITY response code in the tagged
+      OK response as part of a successful authentication.  It is
+      unnecessary for a client to send a separate CAPABILITY command if
+      it recognizes these automatic capabilities.
+
+   Example:    S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN
+
+
+7.2.2.  LIST Response
+
+   Contents:   name attributes
+               hierarchy delimiter
+               name
+
+      The LIST response occurs as a result of a LIST command.  It
+      returns a single name that matches the LIST specification.  There
+      can be multiple LIST responses for a single LIST command.
+
+      Four name attributes are defined:
+
+      \Noinferiors
+         It is not possible for any child levels of hierarchy to exist
+         under this name; no child levels exist now and none can be
+         created in the future.
+
+      \Noselect
+         It is not possible to use this name as a selectable mailbox.
+
+      \Marked
+         The mailbox has been marked "interesting" by the server; the
+         mailbox probably contains messages that have been added since
+         the last time the mailbox was selected.
+
+      \Unmarked
+         The mailbox does not contain any additional messages since the
+         last time the mailbox was selected.
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 69]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      If it is not feasible for the server to determine whether or not
+      the mailbox is "interesting", or if the name is a \Noselect name,
+      the server SHOULD NOT send either \Marked or \Unmarked.
+
+      The hierarchy delimiter is a character used to delimit levels of
+      hierarchy in a mailbox name.  A client can use it to create child
+      mailboxes, and to search higher or lower levels of naming
+      hierarchy.  All children of a top-level hierarchy node MUST use
+      the same separator character.  A NIL hierarchy delimiter means
+      that no hierarchy exists; the name is a "flat" name.
+
+      The name represents an unambiguous left-to-right hierarchy, and
+      MUST be valid for use as a reference in LIST and LSUB commands.
+      Unless \Noselect is indicated, the name MUST also be valid as an
+      argument for commands, such as SELECT, that accept mailbox names.
+
+   Example:    S: * LIST (\Noselect) "/" ~/Mail/foo
+
+
+7.2.3.  LSUB Response
+
+   Contents:   name attributes
+               hierarchy delimiter
+               name
+
+      The LSUB response occurs as a result of an LSUB command.  It
+      returns a single name that matches the LSUB specification.  There
+      can be multiple LSUB responses for a single LSUB command.  The
+      data is identical in format to the LIST response.
+
+   Example:    S: * LSUB () "." #news.comp.mail.misc
+
+
+7.2.4   STATUS Response
+
+   Contents:   name
+               status parenthesized list
+
+      The STATUS response occurs as a result of an STATUS command.  It
+      returns the mailbox name that matches the STATUS specification and
+      the requested mailbox status information.
+
+   Example:    S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 70]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+7.2.5.  SEARCH Response
+
+   Contents:   zero or more numbers
+
+      The SEARCH response occurs as a result of a SEARCH or UID SEARCH
+      command.  The number(s) refer to those messages that match the
+      search criteria.  For SEARCH, these are message sequence numbers;
+      for UID SEARCH, these are unique identifiers.  Each number is
+      delimited by a space.
+
+   Example:    S: * SEARCH 2 3 6
+
+
+7.2.6.  FLAGS Response
+
+   Contents:   flag parenthesized list
+
+      The FLAGS response occurs as a result of a SELECT or EXAMINE
+      command.  The flag parenthesized list identifies the flags (at a
+      minimum, the system-defined flags) that are applicable for this
+      mailbox.  Flags other than the system flags can also exist,
+      depending on server implementation.
+
+      The update from the FLAGS response MUST be recorded by the client.
+
+   Example:    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+
+
+7.3.    Server Responses - Mailbox Size
+
+   These responses are always untagged.  This is how changes in the size
+   of the mailbox are transmitted from the server to the client.
+   Immediately following the "*" token is a number that represents a
+   message count.
+
+7.3.1.  EXISTS Response
+
+   Contents:   none
+
+      The EXISTS response reports the number of messages in the mailbox.
+      This response occurs as a result of a SELECT or EXAMINE command,
+      and if the size of the mailbox changes (e.g., new messages).
+
+      The update from the EXISTS response MUST be recorded by the
+      client.
+
+   Example:    S: * 23 EXISTS
+
+
+
+
+Crispin                     Standards Track                    [Page 71]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+7.3.2.  RECENT Response
+
+   Contents:   none
+
+      The RECENT response reports the number of messages with the
+      \Recent flag set.  This response occurs as a result of a SELECT or
+      EXAMINE command, and if the size of the mailbox changes (e.g., new
+      messages).
+
+           Note: It is not guaranteed that the message sequence
+           numbers of recent messages will be a contiguous range of
+           the highest n messages in the mailbox (where n is the
+           value reported by the RECENT response).  Examples of
+           situations in which this is not the case are: multiple
+           clients having the same mailbox open (the first session
+           to be notified will see it as recent, others will
+           probably see it as non-recent), and when the mailbox is
+           re-ordered by a non-IMAP agent.
+
+           The only reliable way to identify recent messages is to
+           look at message flags to see which have the \Recent flag
+           set, or to do a SEARCH RECENT.
+
+      The update from the RECENT response MUST be recorded by the
+      client.
+
+   Example:    S: * 5 RECENT
+
+
+7.4.    Server Responses - Message Status
+
+   These responses are always untagged.  This is how message data are
+   transmitted from the server to the client, often as a result of a
+   command with the same name.  Immediately following the "*" token is a
+   number that represents a message sequence number.
+
+7.4.1.  EXPUNGE Response
+
+   Contents:   none
+
+      The EXPUNGE response reports that the specified message sequence
+      number has been permanently removed from the mailbox.  The message
+      sequence number for each successive message in the mailbox is
+      immediately decremented by 1, and this decrement is reflected in
+      message sequence numbers in subsequent responses (including other
+      untagged EXPUNGE responses).
+
+
+
+
+
+Crispin                     Standards Track                    [Page 72]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      The EXPUNGE response also decrements the number of messages in the
+      mailbox; it is not necessary to send an EXISTS response with the
+      new value.
+
+      As a result of the immediate decrement rule, message sequence
+      numbers that appear in a set of successive EXPUNGE responses
+      depend upon whether the messages are removed starting from lower
+      numbers to higher numbers, or from higher numbers to lower
+      numbers.  For example, if the last 5 messages in a 9-message
+      mailbox are expunged, a "lower to higher" server will send five
+      untagged EXPUNGE responses for message sequence number 5, whereas
+      a "higher to lower server" will send successive untagged EXPUNGE
+      responses for message sequence numbers 9, 8, 7, 6, and 5.
+
+      An EXPUNGE response MUST NOT be sent when no command is in
+      progress, nor while responding to a FETCH, STORE, or SEARCH
+      command.  This rule is necessary to prevent a loss of
+      synchronization of message sequence numbers between client and
+      server.  A command is not "in progress" until the complete command
+      has been received; in particular, a command is not "in progress"
+      during the negotiation of command continuation.
+
+           Note: UID FETCH, UID STORE, and UID SEARCH are different
+           commands from FETCH, STORE, and SEARCH.  An EXPUNGE
+           response MAY be sent during a UID command.
+
+      The update from the EXPUNGE response MUST be recorded by the
+      client.
+
+   Example:    S: * 44 EXPUNGE
+
+
+7.4.2.  FETCH Response
+
+   Contents:   message data
+
+      The FETCH response returns data about a message to the client.
+      The data are pairs of data item names and their values in
+      parentheses.  This response occurs as the result of a FETCH or
+      STORE command, as well as by unilateral server decision (e.g.,
+      flag updates).
+
+      The current data items are:
+
+      BODY
+         A form of BODYSTRUCTURE without extension data.
+
+
+
+
+
+Crispin                     Standards Track                    [Page 73]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      BODY[<section>]<<origin octet>>
+         A string expressing the body contents of the specified section.
+         The string SHOULD be interpreted by the client according to the
+         content transfer encoding, body type, and subtype.
+
+         If the origin octet is specified, this string is a substring of
+         the entire body contents, starting at that origin octet.  This
+         means that BODY[]<0> MAY be truncated, but BODY[] is NEVER
+         truncated.
+
+            Note: The origin octet facility MUST NOT be used by a server
+            in a FETCH response unless the client specifically requested
+            it by means of a FETCH of a BODY[<section>]<<partial>> data
+            item.
+
+         8-bit textual data is permitted if a [CHARSET] identifier is
+         part of the body parameter parenthesized list for this section.
+         Note that headers (part specifiers HEADER or MIME, or the
+         header portion of a MESSAGE/RFC822 part), MUST be 7-bit; 8-bit
+         characters are not permitted in headers.  Note also that the
+         [RFC-2822] delimiting blank line between the header and the
+         body is not affected by header line subsetting; the blank line
+         is always included as part of header data, except in the case
+         of a message which has no body and no blank line.
+
+         Non-textual data such as binary data MUST be transfer encoded
+         into a textual form, such as BASE64, prior to being sent to the
+         client.  To derive the original binary data, the client MUST
+         decode the transfer encoded string.
+
+      BODYSTRUCTURE
+         A parenthesized list that describes the [MIME-IMB] body
+         structure of a message.  This is computed by the server by
+         parsing the [MIME-IMB] header fields, defaulting various fields
+         as necessary.
+
+         For example, a simple text message of 48 lines and 2279 octets
+         can have a body structure of: ("TEXT" "PLAIN" ("CHARSET"
+         "US-ASCII") NIL NIL "7BIT" 2279 48)
+
+         Multiple parts are indicated by parenthesis nesting.  Instead
+         of a body type as the first element of the parenthesized list,
+         there is a sequence of one or more nested body structures.  The
+         second element of the parenthesized list is the multipart
+         subtype (mixed, digest, parallel, alternative, etc.).
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 74]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+         For example, a two part message consisting of a text and a
+         BASE64-encoded text attachment can have a body structure of:
+         (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152
+         23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff")
+         "<960723163407.20117h@cac.washington.edu>" "Compiler diff"
+         "BASE64" 4554 73) "MIXED")
+
+         Extension data follows the multipart subtype.  Extension data
+         is never returned with the BODY fetch, but can be returned with
+         a BODYSTRUCTURE fetch.  Extension data, if present, MUST be in
+         the defined order.  The extension data of a multipart body part
+         are in the following order:
+
+         body parameter parenthesized list
+            A parenthesized 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-IMB].
+
+         body disposition
+            A parenthesized list, consisting of a disposition type
+            string, followed by a parenthesized list of disposition
+            attribute/value pairs as defined in [DISPOSITION].
+
+         body language
+            A string or parenthesized list giving the body language
+            value as defined in [LANGUAGE-TAGS].
+
+         body location
+            A string list giving the body content URI as defined in
+            [LOCATION].
+
+         Any following extension data are not yet defined in this
+         version of the protocol.  Such extension data can consist of
+         zero or more NILs, strings, numbers, or potentially nested
+         parenthesized lists of such data.  Client implementations that
+         do a BODYSTRUCTURE fetch MUST be prepared to accept such
+         extension data.  Server implementations MUST NOT send such
+         extension data until it has been defined by a revision of this
+         protocol.
+
+         The basic fields of a non-multipart body part are in the
+         following order:
+
+         body type
+            A string giving the content media type name as defined in
+            [MIME-IMB].
+
+
+
+
+
+Crispin                     Standards Track                    [Page 75]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+         body subtype
+            A string giving the content subtype name as defined in
+            [MIME-IMB].
+
+         body parameter parenthesized list
+            A parenthesized 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-IMB].
+
+         body id
+            A string giving the content id as defined in [MIME-IMB].
+
+         body description
+            A string giving the content description as defined in
+            [MIME-IMB].
+
+         body encoding
+            A string giving the content transfer encoding as defined in
+            [MIME-IMB].
+
+         body size
+            A number giving the size of the body in octets.  Note that
+            this size is the size in its transfer encoding and not the
+            resulting size after any decoding.
+
+         A body type of type MESSAGE and subtype RFC822 contains,
+         immediately after the basic fields, the envelope structure,
+         body structure, and size in text lines of the encapsulated
+         message.
+
+         A body type of type TEXT contains, immediately after the basic
+         fields, the size of the body in text lines.  Note that this
+         size is the size in its content transfer encoding and not the
+         resulting size after any decoding.
+
+         Extension data follows the basic fields and the type-specific
+         fields listed above.  Extension data is never returned with the
+         BODY fetch, but can be returned with a BODYSTRUCTURE fetch.
+         Extension data, if present, MUST be in the defined order.
+
+         The extension data of a non-multipart body part are in the
+         following order:
+
+         body MD5
+            A string giving the body MD5 value as defined in [MD5].
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 76]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+         body disposition
+            A parenthesized list with the same content and function as
+            the body disposition for a multipart body part.
+
+         body language
+            A string or parenthesized list giving the body language
+            value as defined in [LANGUAGE-TAGS].
+
+         body location
+            A string list giving the body content URI as defined in
+            [LOCATION].
+
+         Any following extension data are not yet defined in this
+         version of the protocol, and would be as described above under
+         multipart extension data.
+
+      ENVELOPE
+         A parenthesized list that describes the envelope structure of a
+         message.  This is computed by the server by parsing the
+         [RFC-2822] header into the component parts, defaulting various
+         fields as necessary.
+
+         The fields of the envelope structure 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 parenthesized lists of address
+         structures.
+
+         An address structure is a parenthesized list that describes an
+         electronic mail address.  The fields of an address structure
+         are in the following order: personal name, [SMTP]
+         at-domain-list (source route), mailbox name, and host name.
+
+         [RFC-2822] group syntax is indicated by a special form of
+         address structure in which the host name field is NIL.  If the
+         mailbox name field is also NIL, this is an end of group marker
+         (semi-colon in RFC 822 syntax).  If the mailbox name field is
+         non-NIL, this is a start of group marker, and the mailbox name
+         field holds the group name phrase.
+
+         If the Date, Subject, In-Reply-To, and Message-ID header lines
+         are absent in the [RFC-2822] header, the corresponding member
+         of the envelope is NIL; if these header lines are present but
+         empty the corresponding member of the envelope is the empty
+         string.
+
+
+
+
+
+Crispin                     Standards Track                    [Page 77]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+            Note: some servers may return a NIL envelope member in the
+            "present but empty" case.  Clients SHOULD treat NIL and
+            empty string as identical.
+
+            Note: [RFC-2822] requires that all messages have a valid
+            Date header.  Therefore, the date member in the envelope can
+            not be NIL or the empty string.
+
+            Note: [RFC-2822] requires that the In-Reply-To and
+            Message-ID headers, if present, have non-empty content.
+            Therefore, the in-reply-to and message-id members in the
+            envelope can not be the empty string.
+
+         If the From, To, cc, and bcc header lines are absent in the
+         [RFC-2822] header, or are present but empty, the corresponding
+         member of the envelope is NIL.
+
+         If the Sender or Reply-To lines are absent in the [RFC-2822]
+         header, or are present but empty, the server sets the
+         corresponding member of the envelope to be the same value as
+         the from member (the client is not expected to know to do
+         this).
+
+            Note: [RFC-2822] requires that all messages have a valid
+            From header.  Therefore, the from, sender, and reply-to
+            members in the envelope can not be NIL.
+
+      FLAGS
+         A parenthesized list of flags that are set for this message.
+
+      INTERNALDATE
+         A string representing the internal date of the message.
+
+      RFC822
+         Equivalent to BODY[].
+
+      RFC822.HEADER
+         Equivalent to BODY[HEADER].  Note that this did not result in
+         \Seen being set, because RFC822.HEADER response data occurs as
+         a result of a FETCH of RFC822.HEADER.  BODY[HEADER] response
+         data occurs as a result of a FETCH of BODY[HEADER] (which sets
+         \Seen) or BODY.PEEK[HEADER] (which does not set \Seen).
+
+      RFC822.SIZE
+         A number expressing the [RFC-2822] size of the message.
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 78]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+      RFC822.TEXT
+         Equivalent to BODY[TEXT].
+
+      UID
+         A number expressing the unique identifier of the message.
+
+
+   Example:    S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
+
+
+7.5.    Server Responses - Command Continuation Request
+
+   The command continuation request response is indicated by a "+" token
+   instead of a tag.  This form of response indicates that the server is
+   ready to accept the continuation of a command from the client.  The
+   remainder of this response is a line of text.
+
+   This response is used in the AUTHENTICATE command to transmit server
+   data to the client, and request additional client data.  This
+   response is also used if an argument to any command is a literal.
+
+   The client is not permitted to send the octets of the literal unless
+   the server indicates that it is expected.  This permits the server to
+   process commands and reject errors on a line-by-line basis.  The
+   remainder of the command, including the CRLF that terminates a
+   command, follows the octets of the literal.  If there are any
+   additional command arguments, the literal octets are followed by a
+   space and those arguments.
+
+   Example:    C: A001 LOGIN {11}
+               S: + Ready for additional command text
+               C: FRED FOOBAR {7}
+               S: + Ready for additional command text
+               C: fat man
+               S: A001 OK LOGIN completed
+               C: A044 BLURDYBLOOP {102856}
+               S: A044 BAD No such command as "BLURDYBLOOP"
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 79]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+8.      Sample IMAP4rev1 connection
+
+   The following is a transcript of an IMAP4rev1 connection.  A long
+   line in this sample is broken for editorial clarity.
+
+S:   * OK IMAP4rev1 Service Ready
+C:   a001 login mrc secret
+S:   a001 OK LOGIN completed
+C:   a002 select inbox
+S:   * 18 EXISTS
+S:   * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+S:   * 2 RECENT
+S:   * OK [UNSEEN 17] Message 17 is the first unseen message
+S:   * OK [UIDVALIDITY 3857529045] UIDs valid
+S:   a002 OK [READ-WRITE] SELECT completed
+C:   a003 fetch 12 full
+S:   * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
+      RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
+      "IMAP4rev1 WG mtg summary and minutes"
+      (("Terry Gray" NIL "gray" "cac.washington.edu"))
+      (("Terry Gray" NIL "gray" "cac.washington.edu"))
+      (("Terry Gray" NIL "gray" "cac.washington.edu"))
+      ((NIL NIL "imap" "cac.washington.edu"))
+      ((NIL NIL "minutes" "CNRI.Reston.VA.US")
+      ("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
+      "<B27397-0100000@cac.washington.edu>")
+       BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028
+       92))
+S:    a003 OK FETCH completed
+C:    a004 fetch 12 body[header]
+S:    * 12 FETCH (BODY[HEADER] {342}
+S:    Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
+S:    From: Terry Gray <gray@cac.washington.edu>
+S:    Subject: IMAP4rev1 WG mtg summary and minutes
+S:    To: imap@cac.washington.edu
+S:    cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>
+S:    Message-Id: <B27397-0100000@cac.washington.edu>
+S:    MIME-Version: 1.0
+S:    Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+S:
+S:    )
+S:    a004 OK FETCH completed
+C:    a005 store 12 +flags \deleted
+S:    * 12 FETCH (FLAGS (\Seen \Deleted))
+S:    a005 OK +FLAGS completed
+C:    a006 logout
+S:    * BYE IMAP4rev1 server terminating connection
+S:    a006 OK LOGOUT completed
+
+
+
+Crispin                     Standards Track                    [Page 80]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+9.      Formal Syntax
+
+   The following syntax specification uses the Augmented Backus-Naur
+   Form (ABNF) notation as specified in [ABNF].
+
+   In the case of alternative or optional rules in which a later rule
+   overlaps an earlier rule, the rule which is listed earlier MUST take
+   priority.  For example, "\Seen" when parsed as a flag is the \Seen
+   flag name and not a flag-extension, even though "\Seen" can be parsed
+   as a flag-extension.  Some, but not all, instances of this rule are
+   noted below.
+
+        Note: [ABNF] rules MUST be followed strictly; in
+        particular:
+
+        (1) Except as noted otherwise, all alphabetic characters
+        are case-insensitive.  The use of upper or lower case
+        characters to define token strings is for editorial clarity
+        only.  Implementations MUST accept these strings in a
+        case-insensitive fashion.
+
+        (2) In all cases, SP refers to exactly one space.  It is
+        NOT permitted to substitute TAB, insert additional spaces,
+        or otherwise treat SP as being equivalent to LWSP.
+
+        (3) The ASCII NUL character, %x00, MUST NOT be used at any
+        time.
+
+address         = "(" addr-name SP addr-adl SP addr-mailbox SP
+                  addr-host ")"
+
+addr-adl        = nstring
+                    ; Holds route from [RFC-2822] route-addr if
+                    ; non-NIL
+
+addr-host       = nstring
+                    ; NIL indicates [RFC-2822] group syntax.
+                    ; Otherwise, holds [RFC-2822] domain name
+
+addr-mailbox    = nstring
+                    ; NIL indicates end of [RFC-2822] group; if
+                    ; non-NIL and addr-host is NIL, holds
+                    ; [RFC-2822] group name.
+                    ; Otherwise, holds [RFC-2822] local-part
+                    ; after removing [RFC-2822] quoting
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 81]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+addr-name       = nstring
+                    ; If non-NIL, holds phrase from [RFC-2822]
+                    ; mailbox after removing [RFC-2822] quoting
+
+append          = "APPEND" SP mailbox [SP flag-list] [SP date-time] SP
+                  literal
+
+astring         = 1*ASTRING-CHAR / string
+
+ASTRING-CHAR   = ATOM-CHAR / resp-specials
+
+atom            = 1*ATOM-CHAR
+
+ATOM-CHAR       = <any CHAR except atom-specials>
+
+atom-specials   = "(" / ")" / "{" / SP / CTL / list-wildcards /
+                  quoted-specials / resp-specials
+
+authenticate    = "AUTHENTICATE" SP auth-type *(CRLF base64)
+
+auth-type       = atom
+                    ; Defined by [SASL]
+
+base64          = *(4base64-char) [base64-terminal]
+
+base64-char     = ALPHA / DIGIT / "+" / "/"
+                    ; Case-sensitive
+
+base64-terminal = (2base64-char "==") / (3base64-char "=")
+
+body            = "(" (body-type-1part / body-type-mpart) ")"
+
+body-extension  = nstring / number /
+                   "(" body-extension *(SP body-extension) ")"
+                    ; Future expansion.  Client implementations
+                    ; MUST accept body-extension fields.  Server
+                    ; implementations MUST NOT generate
+                    ; body-extension fields except as defined by
+                    ; future standard or standards-track
+                    ; revisions of this specification.
+
+body-ext-1part  = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang
+                  [SP body-fld-loc *(SP body-extension)]]]
+                    ; MUST NOT be returned on non-extensible
+                    ; "BODY" fetch
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 82]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+body-ext-mpart  = body-fld-param [SP body-fld-dsp [SP body-fld-lang
+                  [SP body-fld-loc *(SP body-extension)]]]
+                    ; MUST NOT be returned on non-extensible
+                    ; "BODY" fetch
+
+body-fields     = body-fld-param SP body-fld-id SP body-fld-desc SP
+                  body-fld-enc SP body-fld-octets
+
+body-fld-desc   = nstring
+
+body-fld-dsp    = "(" string SP body-fld-param ")" / nil
+
+body-fld-enc    = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
+                  "QUOTED-PRINTABLE") DQUOTE) / string
+
+body-fld-id     = nstring
+
+body-fld-lang   = nstring / "(" string *(SP string) ")"
+
+body-fld-loc    = nstring
+
+body-fld-lines  = number
+
+body-fld-md5    = nstring
+
+body-fld-octets = number
+
+body-fld-param  = "(" string SP string *(SP string SP string) ")" / nil
+
+body-type-1part = (body-type-basic / body-type-msg / body-type-text)
+                  [SP body-ext-1part]
+
+body-type-basic = media-basic SP body-fields
+                    ; MESSAGE subtype MUST NOT be "RFC822"
+
+body-type-mpart = 1*body SP media-subtype
+                  [SP body-ext-mpart]
+
+body-type-msg   = media-message SP body-fields SP envelope
+                  SP body SP body-fld-lines
+
+body-type-text  = media-text SP body-fields SP body-fld-lines
+
+capability      = ("AUTH=" auth-type) / atom
+                    ; New capabilities MUST begin with "X" or be
+                    ; registered with IANA as standard or
+                    ; standards-track
+
+
+
+
+Crispin                     Standards Track                    [Page 83]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev1"
+                  *(SP capability)
+                    ; Servers MUST implement the STARTTLS, AUTH=PLAIN,
+                    ; and LOGINDISABLED capabilities
+                    ; Servers which offer RFC 1730 compatibility MUST
+                    ; list "IMAP4" as the first capability.
+
+CHAR8           = %x01-ff
+                    ; any OCTET except NUL, %x00
+
+command         = tag SP (command-any / command-auth / command-nonauth /
+                  command-select) CRLF
+                    ; Modal based on state
+
+command-any     = "CAPABILITY" / "LOGOUT" / "NOOP" / x-command
+                    ; Valid in all states
+
+command-auth    = append / create / delete / examine / list / lsub /
+                  rename / select / status / subscribe / unsubscribe
+                    ; Valid only in Authenticated or Selected state
+
+command-nonauth = login / authenticate / "STARTTLS"
+                    ; Valid only when in Not Authenticated state
+
+command-select  = "CHECK" / "CLOSE" / "EXPUNGE" / copy / fetch / store /
+                  uid / search
+                    ; Valid only when in Selected state
+
+continue-req    = "+" SP (resp-text / base64) CRLF
+
+copy            = "COPY" SP sequence-set SP mailbox
+
+create          = "CREATE" SP mailbox
+                    ; Use of INBOX gives a NO error
+
+date            = date-text / DQUOTE date-text DQUOTE
+
+date-day        = 1*2DIGIT
+                    ; Day of month
+
+date-day-fixed  = (SP DIGIT) / 2DIGIT
+                    ; Fixed-format version of date-day
+
+date-month      = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
+                  "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
+
+date-text       = date-day "-" date-month "-" date-year
+
+
+
+
+Crispin                     Standards Track                    [Page 84]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+date-year       = 4DIGIT
+
+date-time       = DQUOTE date-day-fixed "-" date-month "-" date-year
+                  SP time SP zone DQUOTE
+
+delete          = "DELETE" SP mailbox
+                    ; Use of INBOX gives a NO error
+
+digit-nz        = %x31-39
+                    ; 1-9
+
+envelope        = "(" env-date SP env-subject SP env-from SP
+                  env-sender SP env-reply-to SP env-to SP env-cc SP
+                  env-bcc SP env-in-reply-to SP env-message-id ")"
+
+env-bcc         = "(" 1*address ")" / nil
+
+env-cc          = "(" 1*address ")" / nil
+
+env-date        = nstring
+
+env-from        = "(" 1*address ")" / nil
+
+env-in-reply-to = nstring
+
+env-message-id  = nstring
+
+env-reply-to    = "(" 1*address ")" / nil
+
+env-sender      = "(" 1*address ")" / nil
+
+env-subject     = nstring
+
+env-to          = "(" 1*address ")" / nil
+
+examine         = "EXAMINE" SP mailbox
+
+fetch           = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" /
+                  fetch-att / "(" fetch-att *(SP fetch-att) ")")
+
+fetch-att       = "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
+                  "RFC822" [".HEADER" / ".SIZE" / ".TEXT"] /
+                  "BODY" ["STRUCTURE"] / "UID" /
+                  "BODY" section ["<" number "." nz-number ">"] /
+                  "BODY.PEEK" section ["<" number "." nz-number ">"]
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 85]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+flag            = "\Answered" / "\Flagged" / "\Deleted" /
+                  "\Seen" / "\Draft" / flag-keyword / flag-extension
+                    ; Does not include "\Recent"
+
+flag-extension  = "\" atom
+                    ; Future expansion.  Client implementations
+                    ; MUST accept flag-extension flags.  Server
+                    ; implementations MUST NOT generate
+                    ; flag-extension flags except as defined by
+                    ; future standard or standards-track
+                    ; revisions of this specification.
+
+flag-fetch      = flag / "\Recent"
+
+flag-keyword    = atom
+
+flag-list       = "(" [flag *(SP flag)] ")"
+
+flag-perm       = flag / "\*"
+
+greeting        = "*" SP (resp-cond-auth / resp-cond-bye) CRLF
+
+header-fld-name = astring
+
+header-list     = "(" header-fld-name *(SP header-fld-name) ")"
+
+list            = "LIST" SP mailbox SP list-mailbox
+
+list-mailbox    = 1*list-char / string
+
+list-char       = ATOM-CHAR / list-wildcards / resp-specials
+
+list-wildcards  = "%" / "*"
+
+literal         = "{" number "}" CRLF *CHAR8
+                    ; Number represents the number of CHAR8s
+
+login           = "LOGIN" SP userid SP password
+
+lsub            = "LSUB" SP mailbox SP list-mailbox
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 86]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+mailbox         = "INBOX" / astring
+                    ; INBOX is case-insensitive.  All case variants of
+                    ; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX
+                    ; not as an astring.  An astring which consists of
+                    ; the case-insensitive sequence "I" "N" "B" "O" "X"
+                    ; is considered to be INBOX and not an astring.
+                    ;  Refer to section 5.1 for further
+                    ; semantic details of mailbox names.
+
+mailbox-data    =  "FLAGS" SP flag-list / "LIST" SP mailbox-list /
+                   "LSUB" SP mailbox-list / "SEARCH" *(SP nz-number) /
+                   "STATUS" SP mailbox SP "(" [status-att-list] ")" /
+                   number SP "EXISTS" / number SP "RECENT"
+
+mailbox-list    = "(" [mbx-list-flags] ")" SP
+                   (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
+
+mbx-list-flags  = *(mbx-list-oflag SP) mbx-list-sflag
+                  *(SP mbx-list-oflag) /
+                  mbx-list-oflag *(SP mbx-list-oflag)
+
+mbx-list-oflag  = "\Noinferiors" / flag-extension
+                    ; Other flags; multiple possible per LIST response
+
+mbx-list-sflag  = "\Noselect" / "\Marked" / "\Unmarked"
+                    ; Selectability flags; only one per LIST response
+
+media-basic     = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /
+                  "MESSAGE" / "VIDEO") DQUOTE) / string) SP
+                  media-subtype
+                    ; Defined in [MIME-IMT]
+
+media-message   = DQUOTE "MESSAGE" DQUOTE SP DQUOTE "RFC822" DQUOTE
+                    ; Defined in [MIME-IMT]
+
+media-subtype   = string
+                    ; Defined in [MIME-IMT]
+
+media-text      = DQUOTE "TEXT" DQUOTE SP media-subtype
+                    ; Defined in [MIME-IMT]
+
+message-data    = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att))
+
+msg-att         = "(" (msg-att-dynamic / msg-att-static)
+                   *(SP (msg-att-dynamic / msg-att-static)) ")"
+
+msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"
+                    ; MAY change for a message
+
+
+
+Crispin                     Standards Track                    [Page 87]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+msg-att-static  = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time /
+                  "RFC822" [".HEADER" / ".TEXT"] SP nstring /
+                  "RFC822.SIZE" SP number /
+                  "BODY" ["STRUCTURE"] SP body /
+                  "BODY" section ["<" number ">"] SP nstring /
+                  "UID" SP uniqueid
+                    ; MUST NOT change for a message
+
+nil             = "NIL"
+
+nstring         = string / nil
+
+number          = 1*DIGIT
+                    ; Unsigned 32-bit integer
+                    ; (0 <= n < 4,294,967,296)
+
+nz-number       = digit-nz *DIGIT
+                    ; Non-zero unsigned 32-bit integer
+                    ; (0 < n < 4,294,967,296)
+
+password        = astring
+
+quoted          = DQUOTE *QUOTED-CHAR DQUOTE
+
+QUOTED-CHAR     = <any TEXT-CHAR except quoted-specials> /
+                  "\" quoted-specials
+
+quoted-specials = DQUOTE / "\"
+
+rename          = "RENAME" SP mailbox SP mailbox
+                    ; Use of INBOX as a destination gives a NO error
+
+response        = *(continue-req / response-data) response-done
+
+response-data   = "*" SP (resp-cond-state / resp-cond-bye /
+                  mailbox-data / message-data / capability-data) CRLF
+
+response-done   = response-tagged / response-fatal
+
+response-fatal  = "*" SP resp-cond-bye CRLF
+                    ; Server closes connection immediately
+
+response-tagged = tag SP resp-cond-state CRLF
+
+resp-cond-auth  = ("OK" / "PREAUTH") SP resp-text
+                    ; Authentication condition
+
+
+
+
+
+Crispin                     Standards Track                    [Page 88]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+resp-cond-bye   = "BYE" SP resp-text
+
+resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
+                    ; Status condition
+
+resp-specials   = "]"
+
+resp-text       = ["[" resp-text-code "]" SP] text
+
+resp-text-code  = "ALERT" /
+                  "BADCHARSET" [SP "(" astring *(SP astring) ")" ] /
+                  capability-data / "PARSE" /
+                  "PERMANENTFLAGS" SP "("
+                  [flag-perm *(SP flag-perm)] ")" /
+                  "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
+                  "UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number /
+                  "UNSEEN" SP nz-number /
+                  atom [SP 1*<any TEXT-CHAR except "]">]
+
+search          = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key)
+                    ; CHARSET argument to MUST be registered with IANA
+
+search-key      = "ALL" / "ANSWERED" / "BCC" SP astring /
+                  "BEFORE" SP date / "BODY" SP astring /
+                  "CC" SP astring / "DELETED" / "FLAGGED" /
+                  "FROM" SP astring / "KEYWORD" SP flag-keyword /
+                  "NEW" / "OLD" / "ON" SP date / "RECENT" / "SEEN" /
+                  "SINCE" SP date / "SUBJECT" SP astring /
+                  "TEXT" SP astring / "TO" SP astring /
+                  "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
+                  "UNKEYWORD" SP flag-keyword / "UNSEEN" /
+                    ; Above this line were in [IMAP2]
+                  "DRAFT" / "HEADER" SP header-fld-name SP astring /
+                  "LARGER" SP number / "NOT" SP search-key /
+                  "OR" SP search-key SP search-key /
+                  "SENTBEFORE" SP date / "SENTON" SP date /
+                  "SENTSINCE" SP date / "SMALLER" SP number /
+                  "UID" SP sequence-set / "UNDRAFT" / sequence-set /
+                  "(" search-key *(SP search-key) ")"
+
+section         = "[" [section-spec] "]"
+
+section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list /
+                  "TEXT"
+                    ; top-level or MESSAGE/RFC822 part
+
+section-part    = nz-number *("." nz-number)
+                    ; body part nesting
+
+
+
+Crispin                     Standards Track                    [Page 89]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+section-spec    = section-msgtext / (section-part ["." section-text])
+
+section-text    = section-msgtext / "MIME"
+                    ; text other than actual body part (headers, etc.)
+
+select          = "SELECT" SP mailbox
+
+seq-number      = nz-number / "*"
+                    ; message sequence number (COPY, FETCH, STORE
+                    ; commands) or unique identifier (UID COPY,
+                    ; UID FETCH, UID STORE commands).
+                    ; * represents the largest number in use.  In
+                    ; the case of message sequence numbers, it is
+                    ; the number of messages in a non-empty mailbox.
+                    ; In the case of unique identifiers, it is the
+                    ; unique identifier of the last message in the
+                    ; mailbox or, if the mailbox is empty, the
+                    ; mailbox's current UIDNEXT value.
+                    ; The server should respond with a tagged BAD
+                    ; response to a command that uses a message
+                    ; sequence number greater than the number of
+                    ; messages in the selected mailbox.  This
+                    ; includes "*" if the selected mailbox is empty.
+
+seq-range       = seq-number ":" seq-number
+                    ; two seq-number values and all values between
+                    ; these two regardless of order.
+                    ; Example: 2:4 and 4:2 are equivalent and indicate
+                    ; values 2, 3, and 4.
+                    ; Example: a unique identifier sequence range of
+                    ; 3291:* includes the UID of the last message in
+                    ; the mailbox, even if that value is less than 3291.
+
+sequence-set    = (seq-number / seq-range) *("," sequence-set)
+                    ; set of seq-number values, regardless of order.
+                    ; Servers MAY coalesce overlaps and/or execute the
+                    ; sequence in any order.
+                    ; Example: a message sequence number set of
+                    ; 2,4:7,9,12:* for a mailbox with 15 messages is
+                    ; equivalent to 2,4,5,6,7,9,12,13,14,15
+                    ; Example: a message sequence number set of *:4,5:7
+                    ; for a mailbox with 10 messages is equivalent to
+                    ; 10,9,8,7,6,5,4,5,6,7 and MAY be reordered and
+                    ; overlap coalesced to be 4,5,6,7,8,9,10.
+
+status          = "STATUS" SP mailbox SP
+                  "(" status-att *(SP status-att) ")"
+
+
+
+
+Crispin                     Standards Track                    [Page 90]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+status-att      = "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" /
+                  "UNSEEN"
+
+status-att-list =  status-att SP number *(SP status-att SP number)
+
+store           = "STORE" SP sequence-set SP store-att-flags
+
+store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP
+                  (flag-list / (flag *(SP flag)))
+
+string          = quoted / literal
+
+subscribe       = "SUBSCRIBE" SP mailbox
+
+tag             = 1*<any ASTRING-CHAR except "+">
+
+text            = 1*TEXT-CHAR
+
+TEXT-CHAR       = <any CHAR except CR and LF>
+
+time            = 2DIGIT ":" 2DIGIT ":" 2DIGIT
+                    ; Hours minutes seconds
+
+uid             = "UID" SP (copy / fetch / search / store)
+                    ; Unique identifiers used instead of message
+                    ; sequence numbers
+
+uniqueid        = nz-number
+                    ; Strictly ascending
+
+unsubscribe     = "UNSUBSCRIBE" SP mailbox
+
+userid          = astring
+
+x-command       = "X" atom <experimental command arguments>
+
+zone            = ("+" / "-") 4DIGIT
+                    ; Signed four-digit value of hhmm representing
+                    ; hours and minutes east 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                     Standards Track                    [Page 91]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+10.     Author's Note
+
+   This document is a revision or rewrite of earlier documents, and
+   supercedes the protocol specification in those documents: RFC 2060,
+   RFC 1730, unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064.
+
+11.     Security Considerations
+
+   IMAP4rev1 protocol transactions, including electronic mail data, are
+   sent in the clear over the network unless protection from snooping is
+   negotiated.  This can be accomplished either by the use of STARTTLS,
+   negotiated privacy protection in the AUTHENTICATE command, or some
+   other protection mechanism.
+
+11.1.   STARTTLS Security Considerations
+
+   The specification of the STARTTLS command and LOGINDISABLED
+   capability in this document replaces that in [IMAP-TLS].  [IMAP-TLS]
+   remains normative for the PLAIN [SASL] authenticator.
+
+   IMAP client and server implementations MUST implement the
+   TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite, and SHOULD implement the
+   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite.  This is
+   important as it assures that any two compliant implementations can be
+   configured to interoperate.  All other cipher suites are OPTIONAL.
+   Note that this is a change from section 2.1 of [IMAP-TLS].
+
+   During the [TLS] negotiation, the client MUST check its understanding
+   of the server hostname against the server's identity as presented in
+   the server Certificate message, in order to prevent man-in-the-middle
+   attacks.  If the match fails, the client SHOULD either ask for
+   explicit user confirmation, or terminate the connection and indicate
+   that the server's identity is suspect.  Matching is performed
+   according to these rules:
+
+        The client MUST use the server hostname it used to open the
+        connection as the value to compare against the server name
+        as expressed in the server certificate.  The client MUST
+        NOT use any form of the server hostname derived from an
+        insecure remote source (e.g., insecure DNS lookup).  CNAME
+        canonicalization is not done.
+
+        If a subjectAltName extension of type dNSName is present in
+        the certificate, it SHOULD be used as the source of the
+        server's identity.
+
+        Matching is case-insensitive.
+
+
+
+
+Crispin                     Standards Track                    [Page 92]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+        A "*" wildcard character MAY be used as the left-most name
+        component in the certificate.  For example, *.example.com
+        would match a.example.com, foo.example.com, etc. but would
+        not match example.com.
+
+        If the certificate contains multiple names (e.g., more than
+        one dNSName field), then a match with any one of the fields
+        is considered acceptable.
+
+   Both the client and server MUST check the result of the STARTTLS
+   command and subsequent [TLS] negotiation to see whether acceptable
+   authentication or privacy was achieved.
+
+11.2.   Other Security Considerations
+
+   A server error message for an AUTHENTICATE command which fails due to
+   invalid credentials SHOULD NOT detail why the credentials are
+   invalid.
+
+   Use of the LOGIN command sends passwords in the clear.  This can be
+   avoided by using the AUTHENTICATE command with a [SASL] mechanism
+   that does not use plaintext passwords, by first negotiating
+   encryption via STARTTLS or some other protection mechanism.
+
+   A server implementation MUST implement a configuration that, at the
+   time of authentication, requires:
+      (1) The STARTTLS command has been negotiated.
+   OR
+      (2) Some other mechanism that protects the session from password
+      snooping has been provided.
+   OR
+      (3) The following measures are in place:
+         (a) The LOGINDISABLED capability is advertised, and [SASL]
+         mechanisms (such as PLAIN) using plaintext passwords are NOT
+         advertised in the CAPABILITY list.
+      AND
+         (b) The LOGIN command returns an error even if the password is
+         correct.
+      AND
+         (c) The AUTHENTICATE command returns an error with all [SASL]
+         mechanisms that use plaintext passwords, even if the password
+         is correct.
+
+   A server error message for a failing LOGIN command SHOULD NOT specify
+   that the user name, as opposed to the password, is invalid.
+
+   A server SHOULD have mechanisms in place to limit or delay failed
+   AUTHENTICATE/LOGIN attempts.
+
+
+
+Crispin                     Standards Track                    [Page 93]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   Additional security considerations are discussed in the section
+   discussing the AUTHENTICATE and LOGIN commands.
+
+12.     IANA Considerations
+
+   IMAP4 capabilities are registered by publishing a standards track or
+   IESG approved experimental RFC.  The registry is currently located
+   at:
+
+        http://www.iana.org/assignments/imap4-capabilities
+
+   As this specification revises the STARTTLS and LOGINDISABLED
+   extensions previously defined in [IMAP-TLS], the registry will be
+   updated accordingly.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 94]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+Appendices
+
+A.      Normative References
+
+   The following documents contain definitions or specifications that
+   are necessary to understand this document properly:
+   [ABNF]                Crocker, D. and P. Overell, "Augmented BNF for
+                         Syntax Specifications: ABNF", RFC 2234,
+                         November 1997.
+
+   [ANONYMOUS]           Newman, C., "Anonymous SASL Mechanism", RFC
+                         2245, November 1997.
+
+   [CHARSET]             Freed, N. and J. Postel, "IANA Character Set
+                         Registration Procedures", RFC 2978, October
+                         2000.
+
+   [DIGEST-MD5]          Leach, P. and C. Newman, "Using Digest
+                         Authentication as a SASL Mechanism", RFC 2831,
+                         May 2000.
+
+   [DISPOSITION]         Troost, R., Dorner, S. and K. Moore,
+                         "Communicating Presentation Information in
+                         Internet Messages: The Content-Disposition
+                         Header", RFC 2183, August 1997.
+
+   [IMAP-TLS]            Newman, C., "Using TLS with IMAP, POP3 and
+                         ACAP", RFC 2595, June 1999.
+
+   [KEYWORDS]            Bradner, S., "Key words for use in RFCs to
+                         Indicate Requirement Levels", BCP 14, RFC 2119,
+                         March 1997.
+
+   [LANGUAGE-TAGS]       Alvestrand, H., "Tags for the Identification of
+                         Languages", BCP 47, RFC 3066, January 2001.
+
+   [LOCATION]            Palme, J., Hopmann, A. and N. Shelness, "MIME
+                         Encapsulation of Aggregate Documents, such as
+                         HTML (MHTML)", RFC 2557, March 1999.
+
+   [MD5]                 Myers, J. and M. Rose, "The Content-MD5 Header
+                         Field", RFC 1864, October 1995.
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 95]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   [MIME-HDRS]           Moore, K., "MIME (Multipurpose Internet Mail
+                         Extensions) Part Three: Message Header
+                         Extensions for Non-ASCII Text", RFC 2047,
+                         November 1996.
+
+   [MIME-IMB]            Freed, N. and N. Borenstein, "MIME
+                         (Multipurpose Internet Mail Extensions) Part
+                         One: Format of Internet Message Bodies", RFC
+                         2045, November 1996.
+
+   [MIME-IMT]            Freed, N. and N. Borenstein, "MIME
+                         (Multipurpose Internet Mail Extensions) Part
+                         Two: Media Types", RFC 2046, November 1996.
+
+   [RFC-2822]            Resnick, P., "Internet Message Format", RFC
+                         2822, April 2001.
+
+   [SASL]                Myers, J., "Simple Authentication and Security
+                         Layer (SASL)", RFC 2222, October 1997.
+
+   [TLS]                 Dierks, T. and C. Allen, "The TLS Protocol
+                         Version 1.0", RFC 2246, January 1999.
+
+   [UTF-7]               Goldsmith, D. and M. Davis, "UTF-7: A Mail-Safe
+                         Transformation Format of Unicode", RFC 2152,
+                         May 1997.
+
+   The following documents describe quality-of-implementation issues
+   that should be carefully considered when implementing this protocol:
+
+   [IMAP-IMPLEMENTATION] Leiba, B., "IMAP Implementation
+                         Recommendations", RFC 2683, September 1999.
+
+   [IMAP-MULTIACCESS]    Gahrns, M., "IMAP4 Multi-Accessed Mailbox
+                         Practice", RFC 2180, July 1997.
+
+A.1     Informative References
+
+   The following documents describe related protocols:
+
+   [IMAP-DISC]           Austein, R., "Synchronization Operations for
+                         Disconnected IMAP4 Clients", Work in Progress.
+
+   [IMAP-MODEL]          Crispin, M., "Distributed Electronic Mail
+                         Models in IMAP4", RFC 1733, December 1994.
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 96]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   [ACAP]                Newman, C. and J. Myers, "ACAP -- Application
+                         Configuration Access Protocol", RFC 2244,
+                         November 1997.
+
+   [SMTP]                Klensin, J., "Simple Mail Transfer Protocol",
+                         STD 10, RFC 2821, April 2001.
+
+   The following documents are historical or describe historical aspects
+   of this protocol:
+
+   [IMAP-COMPAT]         Crispin, M., "IMAP4 Compatibility with
+                         IMAP2bis", RFC 2061, December 1996.
+
+   [IMAP-HISTORICAL]     Crispin, M., "IMAP4 Compatibility with IMAP2
+                         and IMAP2bis", RFC 1732, December 1994.
+
+   [IMAP-OBSOLETE]       Crispin, M., "Internet Message Access Protocol
+                         - Obsolete Syntax", RFC 2062, December 1996.
+
+   [IMAP2]               Crispin, M., "Interactive Mail Access Protocol
+                         - Version 2", RFC 1176, August 1990.
+
+   [RFC-822]             Crocker, D., "Standard for the Format of ARPA
+                         Internet Text Messages", STD 11, RFC 822,
+                         August 1982.
+
+   [RFC-821]             Postel, J., "Simple Mail Transfer Protocol",
+                         STD 10, RFC 821, August 1982.
+
+B.      Changes from RFC 2060
+
+   1) Clarify description of unique identifiers and their semantics.
+
+   2) Fix the SELECT description to clarify that UIDVALIDITY is required
+   in the SELECT and EXAMINE responses.
+
+   3) Added an example of a failing search.
+
+   4) Correct store-att-flags: "#flag" should be "1#flag".
+
+   5) Made search and section rules clearer.
+
+   6) Correct the STORE example.
+
+   7) Correct "BASE645" misspelling.
+
+   8) Remove extraneous close parenthesis in example of two-part message
+   with text and BASE64 attachment.
+
+
+
+Crispin                     Standards Track                    [Page 97]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   9) Remove obsolete "MAILBOX" response from mailbox-data.
+
+   10) A spurious "<" in the rule for mailbox-data was removed.
+
+   11) Add CRLF to continue-req.
+
+   12) Specifically exclude "]" from the atom in resp-text-code.
+
+   13) Clarify that clients and servers should adhere strictly to the
+   protocol syntax.
+
+   14) Emphasize in 5.2 that EXISTS can not be used to shrink a mailbox.
+
+   15) Add NEWNAME to resp-text-code.
+
+   16) Clarify that the empty string, not NIL, is used as arguments to
+   LIST.
+
+   17) Clarify that NIL can be returned as a hierarchy delimiter for the
+   empty string mailbox name argument if the mailbox namespace is flat.
+
+   18) Clarify that addr-mailbox and addr-name have RFC-2822 quoting
+   removed.
+
+   19) Update UTF-7 reference.
+
+   20) Fix example in 6.3.11.
+
+   21) Clarify that non-existent UIDs are ignored.
+
+   22) Update DISPOSITION reference.
+
+   23) Expand state diagram.
+
+   24) Clarify that partial fetch responses are only returned in
+   response to a partial fetch command.
+
+   25) Add UIDNEXT response code.  Correct UIDVALIDITY definition
+   reference.
+
+   26) Further clarification of "can" vs. "MAY".
+
+   27) Reference RFC-2119.
+
+   28) Clarify that superfluous shifts are not permitted in modified
+   UTF-7.
+
+   29) Clarify that there are no implicit shifts in modified UTF-7.
+
+
+
+Crispin                     Standards Track                    [Page 98]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   30) Clarify that "INBOX" in a mailbox name is always INBOX, even if
+   it is given as a string.
+
+   31) Add missing open parenthesis in media-basic grammar rule.
+
+   32) Correct attribute syntax in mailbox-data.
+
+   33) Add UIDNEXT to EXAMINE responses.
+
+   34) Clarify UNSEEN, PERMANENTFLAGS, UIDVALIDITY, and UIDNEXT
+   responses in SELECT and EXAMINE.  They are required now, but weren't
+   in older versions.
+
+   35) Update references with RFC numbers.
+
+   36) Flush text-mime2.
+
+   37) Clarify that modified UTF-7 names must be case-sensitive and that
+   violating the convention should be avoided.
+
+   38) Correct UID FETCH example.
+
+   39) Clarify UID FETCH, UID STORE, and UID SEARCH vs. untagged EXPUNGE
+   responses.
+
+   40) Clarify the use of the word "convention".
+
+   41) Clarify that a command is not "in progress" until it has been
+   fully received (specifically, that a command is not "in progress"
+   during command continuation negotiation).
+
+   42) Clarify envelope defaulting.
+
+   43) Clarify that SP means one and only one space character.
+
+   44) Forbid silly states in LIST response.
+
+   45) Clarify that the ENVELOPE, INTERNALDATE, RFC822*, BODY*, and UID
+   for a message is static.
+
+   46) Add BADCHARSET response code.
+
+   47) Update formal syntax to [ABNF] conventions.
+
+   48) Clarify trailing hierarchy delimiter in CREATE semantics.
+
+   49) Clarify that the "blank line" is the [RFC-2822] delimiting blank
+   line.
+
+
+
+Crispin                     Standards Track                    [Page 99]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   50) Clarify that RENAME should also create hierarchy as needed for
+   the command to complete.
+
+   51) Fix body-ext-mpart to not require language if disposition
+   present.
+
+   52) Clarify the RFC822.HEADER response.
+
+   53) Correct missing space after charset astring in search.
+
+   54) Correct missing quote for BADCHARSET in resp-text-code.
+
+   55) Clarify that ALL, FAST, and FULL preclude any other data items
+   appearing.
+
+   56) Clarify semantics of reference argument in LIST.
+
+   57) Clarify that a null string for SEARCH HEADER X-FOO means any
+   message with a header line with a field-name of X-FOO regardless of
+   the text of the header.
+
+   58) Specifically reserve 8-bit mailbox names for future use as UTF-8.
+
+   59) It is not an error for the client to store a flag that is not in
+   the PERMANENTFLAGS list; however, the server will either ignore the
+   change or make the change in the session only.
+
+   60) Correct/clarify the text regarding superfluous shifts.
+
+   61) Correct typographic errors in the "Changes" section.
+
+   62) Clarify that STATUS must not be used to check for new messages in
+   the selected mailbox
+
+   63) Clarify LSUB behavior with "%" wildcard.
+
+   64) Change AUTHORIZATION to AUTHENTICATE in section 7.5.
+
+   65) Clarify description of multipart body type.
+
+   66) Clarify that STORE FLAGS does not affect \Recent.
+
+   67) Change "west" to "east" in description of timezone.
+
+   68) Clarify that commands which break command pipelining must wait
+   for a completion result response.
+
+   69) Clarify that EXAMINE does not affect \Recent.
+
+
+
+Crispin                     Standards Track                   [Page 100]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   70) Make description of MIME structure consistent.
+
+   71) Clarify that date searches disregard the time and timezone of the
+   INTERNALDATE or Date: header.  In other words, "ON 13-APR-2000" means
+   messages with an INTERNALDATE text which starts with "13-APR-2000",
+   even if timezone differential from the local timezone is sufficient
+   to move that INTERNALDATE into the previous or next day.
+
+   72) Clarify that the header fetches don't add a blank line if one
+   isn't in the [RFC-2822] message.
+
+   73) Clarify (in discussion of UIDs) that messages are immutable.
+
+   74) Add an example of CHARSET searching.
+
+   75) Clarify in SEARCH that keywords are a type of flag.
+
+   76) Clarify the mandatory nature of the SELECT data responses.
+
+   77) Add optional CAPABILITY response code in the initial OK or
+   PREAUTH.
+
+   78) Add note that server can send an untagged CAPABILITY command as
+   part of the responses to AUTHENTICATE and LOGIN.
+
+   79) Remove statement about it being unnecessary to issue a CAPABILITY
+   command more than once in a connection.  That statement is no longer
+   true.
+
+   80) Clarify that untagged EXPUNGE decrements the number of messages
+   in the mailbox.
+
+   81) Fix definition of "body" (concatenation has tighter binding than
+   alternation).
+
+   82) Add a new "Special Notes to Implementors" section with reference
+   to [IMAP-IMPLEMENTATION].
+
+   83) Clarify that an untagged CAPABILITY response to an AUTHENTICATE
+   command should only be done if a security layer was not negotiated.
+
+   84) Change the definition of atom to exclude "]".  Update astring to
+   include "]" for compatibility with the past.  Remove resp-text-atom.
+
+   85) Remove NEWNAME.  It can't work because mailbox names can be
+   literals and can include "]".  Functionality can be addressed via
+   referrals.
+
+
+
+
+Crispin                     Standards Track                   [Page 101]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   86) Move modified UTF-7 rationale in order to have more logical
+   paragraph flow.
+
+   87) Clarify UID uniqueness guarantees with the use of MUST.
+
+   88) Note that clients should read response data until the connection
+   is closed instead of immediately closing on a BYE.
+
+   89) Change RFC-822 references to RFC-2822.
+
+   90) Clarify that RFC-2822 should be followed instead of RFC-822.
+
+   91) Change recommendation of optional automatic capabilities in LOGIN
+   and AUTHENTICATE to use the CAPABILITY response code in the tagged
+   OK.  This is more interoperable than an unsolicited untagged
+   CAPABILITY response.
+
+   92) STARTTLS and AUTH=PLAIN are mandatory to implement; add
+   recommendations for other [SASL] mechanisms.
+
+   93) Clarify that a "connection" (as opposed to "server" or "command")
+   is in one of the four states.
+
+   94) Clarify that a failed or rejected command does not change state.
+
+   95) Split references between normative and informative.
+
+   96) Discuss authentication failure issues in security section.
+
+   97) Clarify that a data item is not necessarily of only one data
+   type.
+
+   98) Clarify that sequence ranges are independent of order.
+
+   99) Change an example to clarify that superfluous shifts in
+   Modified-UTF7 can not be fixed just by omitting the shift.  The
+   entire string must be recalculated.
+
+   100) Change Envelope Structure definition since [RFC-2822] uses
+   "envelope" to refer to the [SMTP] envelope and not the envelope data
+   that appears in the [RFC-2822] header.
+
+   101) Expand on RFC822.HEADER response data vs. BODY[HEADER].
+
+   102) Clarify Logout state semantics, change ASCII art.
+
+   103) Security changes to comply with IESG requirements.
+
+
+
+
+Crispin                     Standards Track                   [Page 102]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+   104) Add definition for body URI.
+
+   105) Break sequence range definition into three rules, with rewritten
+   descriptions for each.
+
+   106) Move STARTTLS and LOGINDISABLED here from [IMAP-TLS].
+
+   107) Add IANA Considerations section.
+
+   108) Clarify valid client assumptions for new message UIDs vs.
+   UIDNEXT.
+
+   109) Clarify that changes to permanentflags affect concurrent
+   sessions as well as subsequent sessions.
+
+   110) Clarify that authenticated state can be entered by the CLOSE
+   command.
+
+   111) Emphasize that SELECT and EXAMINE are the exceptions to the rule
+   that a failing command does not change state.
+
+   112) Clarify that newly-appended messages have the Recent flag set.
+
+   113) Clarify that newly-copied messages SHOULD have the Recent flag
+   set.
+
+   114) Clarify that UID commands always return the UID in FETCH
+   responses.
+
+C.      Key Word Index
+
+       +FLAGS <flag list> (store command data item) ...............   59
+       +FLAGS.SILENT <flag list> (store command data item) ........   59
+       -FLAGS <flag list> (store command data item) ...............   59
+       -FLAGS.SILENT <flag list> (store command data item) ........   59
+       ALERT (response code) ......................................   64
+       ALL (fetch item) ...........................................   55
+       ALL (search key) ...........................................   50
+       ANSWERED (search key) ......................................   50
+       APPEND (command) ...........................................   45
+       AUTHENTICATE (command) .....................................   27
+       BAD (response) .............................................   66
+       BADCHARSET (response code) .................................   64
+       BCC <string> (search key) ..................................   51
+       BEFORE <date> (search key) .................................   51
+       BODY (fetch item) ..........................................   55
+       BODY (fetch result) ........................................   73
+       BODY <string> (search key) .................................   51
+
+
+
+Crispin                     Standards Track                   [Page 103]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+       BODY.PEEK[<section>]<<partial>> (fetch item) ...............   57
+       BODYSTRUCTURE (fetch item) .................................   57
+       BODYSTRUCTURE (fetch result) ...............................   74
+       BODY[<section>]<<origin octet>> (fetch result) .............   74
+       BODY[<section>]<<partial>> (fetch item) ....................   55
+       BYE (response) .............................................   67
+       Body Structure (message attribute) .........................   12
+       CAPABILITY (command) .......................................   24
+       CAPABILITY (response code) .................................   64
+       CAPABILITY (response) ......................................   68
+       CC <string> (search key) ...................................   51
+       CHECK (command) ............................................   47
+       CLOSE (command) ............................................   48
+       COPY (command) .............................................   59
+       CREATE (command) ...........................................   34
+       DELETE (command) ...........................................   35
+       DELETED (search key) .......................................   51
+       DRAFT (search key) .........................................   51
+       ENVELOPE (fetch item) ......................................   57
+       ENVELOPE (fetch result) ....................................   77
+       EXAMINE (command) ..........................................   33
+       EXISTS (response) ..........................................   71
+       EXPUNGE (command) ..........................................   48
+       EXPUNGE (response) .........................................   72
+       Envelope Structure (message attribute) .....................   12
+       FAST (fetch item) ..........................................   55
+       FETCH (command) ............................................   54
+       FETCH (response) ...........................................   73
+       FLAGGED (search key) .......................................   51
+       FLAGS (fetch item) .........................................   57
+       FLAGS (fetch result) .......................................   78
+       FLAGS (response) ...........................................   71
+       FLAGS <flag list> (store command data item) ................   59
+       FLAGS.SILENT <flag list> (store command data item) .........   59
+       FROM <string> (search key) .................................   51
+       FULL (fetch item) ..........................................   55
+       Flags (message attribute) ..................................   11
+       HEADER (part specifier) ....................................   55
+       HEADER <field-name> <string> (search key) ..................   51
+       HEADER.FIELDS <header-list> (part specifier) ...............   55
+       HEADER.FIELDS.NOT <header-list> (part specifier) ...........   55
+       INTERNALDATE (fetch item) ..................................   57
+       INTERNALDATE (fetch result) ................................   78
+       Internal Date (message attribute) ..........................   12
+       KEYWORD <flag> (search key) ................................   51
+       Keyword (type of flag) .....................................   11
+       LARGER <n> (search key) ....................................   51
+       LIST (command) .............................................   40
+
+
+
+Crispin                     Standards Track                   [Page 104]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+       LIST (response) ............................................   69
+       LOGIN (command) ............................................   30
+       LOGOUT (command) ...........................................   25
+       LSUB (command) .............................................   43
+       LSUB (response) ............................................   70
+       MAY (specification requirement term) .......................    4
+       MESSAGES (status item) .....................................   45
+       MIME (part specifier) ......................................   56
+       MUST (specification requirement term) ......................    4
+       MUST NOT (specification requirement term) ..................    4
+       Message Sequence Number (message attribute) ................   10
+       NEW (search key) ...........................................   51
+       NO (response) ..............................................   66
+       NOOP (command) .............................................   25
+       NOT <search-key> (search key) ..............................   52
+       OK (response) ..............................................   65
+       OLD (search key) ...........................................   52
+       ON <date> (search key) .....................................   52
+       OPTIONAL (specification requirement term) ..................    4
+       OR <search-key1> <search-key2> (search key) ................   52
+       PARSE (response code) ......................................   64
+       PERMANENTFLAGS (response code) .............................   64
+       PREAUTH (response) .........................................   67
+       Permanent Flag (class of flag) .............................   12
+       READ-ONLY (response code) ..................................   65
+       READ-WRITE (response code) .................................   65
+       RECENT (response) ..........................................   72
+       RECENT (search key) ........................................   52
+       RECENT (status item) .......................................   45
+       RENAME (command) ...........................................   37
+       REQUIRED (specification requirement term) ..................    4
+       RFC822 (fetch item) ........................................   57
+       RFC822 (fetch result) ......................................   78
+       RFC822.HEADER (fetch item) .................................   57
+       RFC822.HEADER (fetch result) ...............................   78
+       RFC822.SIZE (fetch item) ...................................   57
+       RFC822.SIZE (fetch result) .................................   78
+       RFC822.TEXT (fetch item) ...................................   58
+       RFC822.TEXT (fetch result) .................................   79
+       SEARCH (command) ...........................................   49
+       SEARCH (response) ..........................................   71
+       SEEN (search key) ..........................................   52
+       SELECT (command) ...........................................   31
+       SENTBEFORE <date> (search key) .............................   52
+       SENTON <date> (search key) .................................   52
+       SENTSINCE <date> (search key) ..............................   52
+       SHOULD (specification requirement term) ....................    4
+       SHOULD NOT (specification requirement term) ................    4
+
+
+
+Crispin                     Standards Track                   [Page 105]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+       SINCE <date> (search key) ..................................   52
+       SMALLER <n> (search key) ...................................   52
+       STARTTLS (command) .........................................   27
+       STATUS (command) ...........................................   44
+       STATUS (response) ..........................................   70
+       STORE (command) ............................................   58
+       SUBJECT <string> (search key) ..............................   53
+       SUBSCRIBE (command) ........................................   38
+       Session Flag (class of flag) ...............................   12
+       System Flag (type of flag) .................................   11
+       TEXT (part specifier) ......................................   56
+       TEXT <string> (search key) .................................   53
+       TO <string> (search key) ...................................   53
+       TRYCREATE (response code) ..................................   65
+       UID (command) ..............................................   60
+       UID (fetch item) ...........................................   58
+       UID (fetch result) .........................................   79
+       UID <sequence set> (search key) ............................   53
+       UIDNEXT (response code) ....................................   65
+       UIDNEXT (status item) ......................................   45
+       UIDVALIDITY (response code) ................................   65
+       UIDVALIDITY (status item) ..................................   45
+       UNANSWERED (search key) ....................................   53
+       UNDELETED (search key) .....................................   53
+       UNDRAFT (search key) .......................................   53
+       UNFLAGGED (search key) .....................................   53
+       UNKEYWORD <flag> (search key) ..............................   53
+       UNSEEN (response code) .....................................   65
+       UNSEEN (search key) ........................................   53
+       UNSEEN (status item) .......................................   45
+       UNSUBSCRIBE (command) ......................................   39
+       Unique Identifier (UID) (message attribute) ................    8
+       X<atom> (command) ..........................................   62
+       [RFC-2822] Size (message attribute) ........................   12
+       \Answered (system flag) ....................................   11
+       \Deleted (system flag) .....................................   11
+       \Draft (system flag) .......................................   11
+       \Flagged (system flag) .....................................   11
+       \Marked (mailbox name attribute) ...........................   69
+       \Noinferiors (mailbox name attribute) ......................   69
+       \Noselect (mailbox name attribute) .........................   69
+       \Recent (system flag) ......................................   11
+       \Seen (system flag) ........................................   11
+       \Unmarked (mailbox name attribute) .........................   69
+
+
+
+
+
+
+
+Crispin                     Standards Track                   [Page 106]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+Author's Address
+
+   Mark R. Crispin
+   Networks and Distributed Computing
+   University of Washington
+   4545 15th Avenue NE
+   Seattle, WA  98105-4527
+
+   Phone: (206) 543-5762
+
+   EMail: MRC@CAC.Washington.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                   [Page 107]
+
+RFC 3501                         IMAPv4                       March 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.  v This
+   document and the information contained herein is provided on an "AS
+   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
+   FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
+   LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
+   NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
+   OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                   [Page 108]
+
diff --git a/docs/rfcs/rfc3502.txt b/docs/rfcs/rfc3502.txt
new file mode 100644
index 0000000..f6b61a4
--- /dev/null
+++ b/docs/rfcs/rfc3502.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                         M. Crispin
+Request for Comments: 3502                      University of Washington
+Category: Standards Track                                     March 2003
+
+
+    Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document describes the multiappending extension to the Internet
+   Message Access Protocol (IMAP) (RFC 3501).  This extension provides
+   substantial performance improvements for IMAP clients which upload
+   multiple messages at a time to a mailbox on the server.
+
+   A server which supports this extension indicates this with a
+   capability name of "MULTIAPPEND".
+
+Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
+   be interpreted as described in [KEYWORDS].
+
+Introduction
+
+   The MULTIAPPEND extension permits uploading of multiple messages with
+   a single command.  When used in conjunction with the [LITERAL+]
+   extension, the entire upload is accomplished in a single
+   command/response round trip.
+
+   A MULTIAPPEND APPEND operation is atomic; either all messages are
+   successfully appended, or no messages are appended.
+
+   In the base IMAP specification, each message must be appended in a
+   separate command, and there is no mechanism to "unappend" messages if
+   an error occurs while appending.  Also, some mail stores may require
+
+
+
+Crispin                     Standards Track                     [Page 1]
+
+RFC 3502                    IMAP MULTIAPPEND                  March 2003
+
+
+   an expensive "open/lock + sync/unlock/close" operation as part of
+   appending; this can be quite expensive if it must be done on a
+   per-message basis.
+
+   If the server supports both LITERAL+ and pipelining but not
+   MULTIAPPEND, it may be possible to get some of the performance
+   advantages of MULTIAPPEND by doing a pipelined "batch" append.
+   However, it will not work as well as MULTIAPPEND for the following
+   reasons:
+
+        1) Multiple APPEND commands, even as part of a pipelined batch,
+        are non-atomic by definition.  There is no way to revert the
+        mailbox to the state before the batch append in the event of an
+        error.
+
+        2) It may not be feasible for the server to coalesce pipelined
+        APPEND operations so as to avoid the "open/lock +
+        sync/unlock/close" overhead described above.  In any case, such
+        coalescing would be timing dependent and thus potentially
+        unreliable.  In particular, with traditional UNIX mailbox files,
+        it is assumed that a lock is held only for a single atomic
+        operation, and many applications disregard any lock that is
+        older than 5 minutes.
+
+        3) If an error occurs, depending upon the nature of the error,
+        it is possible for additional messages to be appended after the
+        error.  For example, the user wants to append 5 messages, but a
+        disk quota error occurs with the third message because of its
+        size.  However, the fourth and fifth messages have already been
+        sent in the pipeline, so the mailbox ends up with the first,
+        second, fourth, and fifth messages of the batch appended.
+
+6.3.11.  APPEND Command
+
+   Arguments:  mailbox name
+               one or more messages to upload, specified as:
+                  OPTIONAL flag parenthesized list
+                  OPTIONAL date/time string
+                  message literal
+
+   Data:       no specific responses for this command
+
+   Result:     OK - append completed
+               NO - append error: can't append to that mailbox, error
+                    in flags or date/time or message text,
+                    append cancelled
+               BAD - command unknown or arguments invalid
+
+
+
+
+Crispin                     Standards Track                     [Page 2]
+
+RFC 3502                    IMAP MULTIAPPEND                  March 2003
+
+
+      The APPEND command appends the literal arguments as new messages
+      to the end of the specified destination mailbox.  This argument
+      SHOULD be in the format of an [RFC-2822] message.  8-bit
+      characters are permitted in the message.  A server implementation
+      that is unable to preserve 8-bit data properly MUST be able to
+      reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB]
+      content transfer encoding.
+
+            Note: There MAY be exceptions, e.g., draft messages, in
+            which required [RFC-2822] header lines are omitted in the
+            message literal argument to APPEND.  The full implications
+            of doing so MUST be understood and carefully weighed.
+
+      If a flag parenthesized list is specified, the flags SHOULD be set
+      in the resulting message; otherwise, the flag list of the
+      resulting message is set empty by default.
+
+      If a date-time is specified, the internal date SHOULD be set in
+      the resulting message; otherwise, the internal date of the
+      resulting message is set to the current date and time by default.
+
+      A zero-length message literal argument is an error, and MUST
+      return a NO.  This can be used to cancel the append.
+
+      If the append is unsuccessful for any reason (including being
+      cancelled), the mailbox MUST be restored to its state before the
+      APPEND attempt; no partial appending is permitted.  The server MAY
+      return an error before processing all the message arguments.
+
+      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 send the response code "[TRYCREATE]" as the prefix of
+      the text of the tagged NO response.  This gives a hint to the
+      client that it can attempt a CREATE command and retry the APPEND
+      if the CREATE is successful.
+
+      If the mailbox is currently selected, the normal new message
+      actions SHOULD occur.  Specifically, the server SHOULD notify the
+      client immediately via an untagged EXISTS response.  If the server
+      does not do so, the client MAY issue a NOOP command (or failing
+      that, a CHECK command) after one or more APPEND commands.
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                     [Page 3]
+
+RFC 3502                    IMAP MULTIAPPEND                  March 2003
+
+
+   Example: C: A003 APPEND saved-messages (\Seen) {329}
+            S: + Ready for literal data
+            C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
+            C: From: Fred Foobar <foobar@Blurdybloop.example.COM>
+            C: Subject: afternoon meeting
+            C: To: mooch@owatagu.example.net
+            C: Message-Id: <B27397-0100000@Blurdybloop.example.COM>
+            C: MIME-Version: 1.0
+            C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+            C:
+            C: Hello Joe, do you think we can meet at 3:30 tomorrow?
+            C:  (\Seen) " 7-Feb-1994 22:43:04 -0800" {295}
+            S: + Ready for literal data
+            C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST)
+            C: From: Joe Mooch <mooch@OWaTaGu.example.net>
+            C: Subject: Re: afternoon meeting
+            C: To: foobar@blurdybloop.example.com
+            C: Message-Id: <a0434793874930@OWaTaGu.example.net>
+            C: MIME-Version: 1.0
+            C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+            C:
+            C: 3:30 is fine with me.
+            C:
+            S: A003 OK APPEND completed
+            C: A004 APPEND bogusname (\Flagged) {1023}
+            S: A004 NO [TRYCREATE] No such mailbox as bogusname
+            C: A005 APPEND test (\Flagged) {99}
+            S: + Ready for literal data
+            C: Date: Mon, 7 Feb 2000 22:43:04 -0800 (PST)
+            C: From: Fred Foobar <fred@example.com>
+            C: Subject: hmm...
+            C:  {35403}
+            S: A005 NO APPEND failed: Disk quota exceeded
+
+        Note: The APPEND command is not used for message delivery,
+        because it does not provide a mechanism to transfer [SMTP]
+        envelope information.
+
+Modification to IMAP4rev1 Base Protocol Formal Syntax
+
+   The following syntax specification uses the Augmented Backus-Naur
+   Form (ABNF) notation as specified in [ABNF].
+
+   append          = "APPEND" SP mailbox 1*append-message
+
+   append-message  = [SP flag-list] [SP date-time] SP literal
+
+
+
+
+
+Crispin                     Standards Track                     [Page 4]
+
+RFC 3502                    IMAP MULTIAPPEND                  March 2003
+
+
+MULTIAPPEND Interaction with UIDPLUS Extension
+
+   Servers which support both MULTIAPPEND and [UIDPLUS] will have the
+   "resp-code-apnd" rule modified as follows:
+
+   resp-code-apnd  = "APPENDUID" SP nz-number SP set
+
+   That is, the APPENDUID response code returns as many UIDs as there
+   were messages appended in the multiple append.  The UIDs returned
+   should be in the order the articles where appended.  The message set
+   may not contain extraneous UIDs or the symbol "*".
+
+Security Considerations
+
+   The MULTIAPPEND extension does not raise any security considerations
+   that are not present in the base [IMAP] protocol, and these issues
+   are discussed in [IMAP].  Nevertheless, it is important to remember
+   that IMAP4rev1 protocol transactions, including electronic mail data,
+   are sent in the clear over the network unless protection from
+   snooping is negotiated, either by the use of STARTTLS, privacy
+   protection is negotiated in the AUTHENTICATE command, or some other
+   protection mechanism is in effect.
+
+Normative References
+
+   [ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 2234, November 1997.
+
+   [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
+              4rev1", RFC 3501, March 2003.
+
+   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [MIME-IMB] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet
+              Mail Extensions) Part One: Format of Internet Message
+              Bodies", RFC 2045, November 1996.
+
+   [RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April
+              2001.
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                     [Page 5]
+
+RFC 3502                    IMAP MULTIAPPEND                  March 2003
+
+
+Informative References
+
+   [LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
+              January 1997.
+
+   [UIDPLUS]  Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 1988.
+
+   [SMTP]     Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC
+              2821, April 2001.
+
+Author's Address
+
+   Mark R. Crispin
+   Networks and Distributed Computing
+   University of Washington
+   4545 15th Avenue NE
+   Seattle, WA  98105-4527
+
+   Phone: (206) 543-5762
+   EMail: MRC@CAC.Washington.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                     [Page 6]
+
+RFC 3502                    IMAP MULTIAPPEND                  March 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                     [Page 7]
+
diff --git a/docs/rfcs/rfc3503.txt b/docs/rfcs/rfc3503.txt
new file mode 100644
index 0000000..5b82fb0
--- /dev/null
+++ b/docs/rfcs/rfc3503.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                        A. Melnikov
+Request for Comments: 3503                 ACI Worldwide/MessagingDirect
+Category: Standards Track                                     March 2003
+
+
+          Message Disposition Notification (MDN) profile for
+                Internet Message Access Protocol (IMAP)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   The Message Disposition Notification (MDN) facility defined in RFC
+   2298 provides a means by which a message can request that message
+   processing by the recipient be acknowledged as well as a format to be
+   used for such acknowledgements.  However, it doesn't describe how
+   multiple Mail User Agents (MUAs) should handle the generation of MDNs
+   in an Internet Message Access Protocol (IMAP4) environment.
+
+   This document describes how to handle MDNs in such an environment and
+   provides guidelines for implementers of IMAP4 that want to add MDN
+   support to their products.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                     [Page 1]
+
+RFC 3503                  MDN profile for IMAP                March 2003
+
+
+Table of Contents
+
+   1.  Conventions Used in this Document.............................  2
+   2.  Introduction and Overview.....................................  2
+   3.  Client behavior...............................................  3
+       3.1. Client behavior when receiving a message.................  5
+       3.2. Client behavior when copying a message...................  5
+       3.3. Client behavior when sending a message...................  5
+       3.4. Client behavior when saving a temporary message..........  5
+   4.  Server behavior...............................................  5
+       4.1. Server that supports arbitrary keywords..................  5
+       4.2. Server that supports only $MDNSent keyword...............  5
+       4.3. Interaction with IMAP ACL extension......................  6
+   5.  Examples......................................................  6
+   6.  Security Considerations.......................................  7
+   7.  Formal Syntax.................................................  7
+   8.  Acknowledgments...............................................  7
+   9.  Normative References..........................................  8
+   10. Author's Address..............................................  8
+   11. Full Copyright Statement......................................  9
+
+1.  Conventions Used in this Document
+
+   "C:" and "S:" in examples show lines sent by the client and server
+   respectively.
+
+   The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
+   this document when typed in uppercase are to be interpreted as
+   defined in "Key words for use in RFCs to Indicate Requirement Levels"
+   [KEYWORDS].
+
+2.  Introduction and Overview
+
+   This memo defines an additional [IMAP4] mailbox keyword that allows
+   multiple Mail User Agents (MUAs) to know if a requested receipt
+   notification was sent.
+
+   Message Disposition Notification [MDN] does not require any special
+   support of IMAP in the case where a user has access to the mailstore
+   from only one computer and is using a single MUA.  In this case, the
+   MUA behaves as described in [MDN], i.e., the MUA performs automatic
+   processing and generates corresponding MDNs, it performs requested
+   action and, with the user's permission, sends appropriate MDNs.  The
+   MUA will not send MDN twice because the MUA keeps track of sent
+   notifications in a local configuration.  However, that does not work
+   when IMAP is used to access the same mailstore from different
+   locations or is using different MUAs.
+
+
+
+
+Melnikov                    Standards Track                     [Page 2]
+
+RFC 3503                  MDN profile for IMAP                March 2003
+
+
+   This document defines a new special purpose mailbox keyword $MDNSent
+   that must be used by MUAs.  It does not define any new command or
+   response for IMAP, but describes a technique that MUAs should use to
+   achieve interoperability.
+
+   When a client opens a mailbox for the first time, it verifies that
+   the server is capable of storing the $MDNSent keyword by examining
+   the PERMANENTFLAGS response code.  In order to support MDN in IMAP, a
+   server MUST support either the $MDNSent keyword, or arbitrary message
+   keywords.
+
+3.  Client behavior
+
+   The use of IMAP requires few additional steps in mail processing on
+   the client side.  The following timeline modifies the timeline found
+   in Section 4 of [MDN].
+
+   -- User composes message.
+
+   -- User tells MUA to send message.
+
+   -- MUA passes message to MSA (original recipient information passed
+      along).  MUA [optionally] saves message to a folder for sent mail
+      with $MDNSent flag set.
+
+   -- MSA sends message to MTA.
+
+   -- Final MTA receives message.
+
+   -- Final MTA delivers message to MUA (possibly generating DSN).
+
+   -- MUA logs into IMAP server, opens mailbox, verifies if mailbox can
+      store $MDNSent keyword by examining PERMANENTFLAGS response.
+
+   -- MUA performs automatic processing and generates corresponding MDNs
+      ("dispatched", "processed", "deleted", "denied" or "failed"
+      disposition type with "automatic-action" and "MDN-sent-
+      automatically" disposition modes) for messages that do not have
+      $MDNSent keyword, or \Draft flag set. (*)
+
+   -- MUA sets the $MDNSent keyword for every message that required an
+      automatic MDN to be sent, whether or not the MDN was sent.
+
+   -- MUA displays a list of messages to user.
+
+   -- User selects a message and requests that some action be performed
+      on it.
+
+
+
+
+Melnikov                    Standards Track                     [Page 3]
+
+RFC 3503                  MDN profile for IMAP                March 2003
+
+
+   -- MUA performs requested action and, with user's permission, sends
+      appropriate MDN ("displayed", "dispatched", "processed",
+      "deleted", "denied" or "failed" disposition type with "manual-
+      action" and "MDN-sent-manually" or "MDN-sent-automatically"
+      disposition mode).  If the generated MDN is saved to a mailbox
+      with the APPEND command, the client MUST specify the $MDNSent
+      keyword in the APPEND.
+
+   -- MUA sets the $MDNSent keyword for all messages for which the user
+      confirmed the dispatching of disposition (or was explicitly
+      prohibited to do so).
+
+   -- User possibly performs other actions on message, but no further
+      MDNs are generated.
+
+   (*) Note: MUA MUST NOT use \Recent flag as an indicator that it
+       should send MDN, because according to [IMAP4], "If multiple
+       connections have the same mailbox selected simultaneously, it is
+       undefined which of these connections will see newly-arrived
+       messages with \Recent set and which will see it without \Recent
+       set".  Thus, using \Recent as an indicator will cause
+       unpredictable client behavior with different IMAP4 servers.
+       However, the client MAY use \Seen flag as one of the indicators
+       that MDN must not be sent.  The client MUST NOT use any other
+       standard flags, like \Draft or \Answered, to indicate that MDN
+       was previously sent, because they have different well known
+       meaning.  In any case, in the presence of the $MDNSent keyword,
+       the client MUST ignore all other flags or keywords for the
+       purpose of generating an MDN and MUST NOT send the MDN.
+
+   When the client opens a mailbox for the first time, it must verify
+   that the server supports the $MDNSent keyword, or arbitrary message
+   keywords by examining PERMANENTFLAGS response code.
+
+   The client MUST NOT try to set the $MDNSent keyword if the server is
+   incapable of storing it permanently.
+
+   The client MUST be prepared to receive NO from the server as the
+   result of STORE $MDNSent when the server advertises the support of
+   storing arbitrary keywords, because the server may limit the number
+   of message keywords it can store in a particular mailbox.  A client
+   SHOULD NOT send MDN if it fails to store the $MDNSent keyword.
+
+   Once the $MDNSent keyword is set, it MUST NOT be unset by a client.
+   The client MAY set the $MDNSent keyword when a user denies sending
+   the notification.  This prohibits all other MUAs from sending MDN for
+   this message.
+
+
+
+
+Melnikov                    Standards Track                     [Page 4]
+
+RFC 3503                  MDN profile for IMAP                March 2003
+
+
+3.1.  Client behavior when receiving a message
+
+   The client MUST NOT send MDN if a message has the $MDNSent keyword
+   set.  It also MUST NOT send MDN if a message has \Draft flag, because
+   some clients use this flag to mark a message as incomplete.
+
+   See the timeline in section 3 for details on client behavior when
+   receiving a message.
+
+3.2.  Client behavior when copying a message
+
+   The client SHOULD verify that $MDNSent is preserved on a COPY
+   operation.  Furthermore, when a message is copied between servers
+   with the APPEND command, the client MUST set the $MDNSent keyword
+   correctly.
+
+3.3.  Client behavior when sending a message
+
+   When saving a sent message to any folder, the client MUST set the
+   $MDNSent keyword to prevent another client from sending MDN for the
+   message.
+
+3.4.  Client behavior when saving a temporary message
+
+   When saving an unfinished message to any folder client MUST set
+   $MDNSent keyword to prevent another client from sending MDN for the
+   message.
+
+4.  Server behavior
+
+   Server implementors that want to follow this specification must
+   insure that their server complies with either section 4.1 or section
+   4.2.  If the server also supports the IMAP [ACL] extension, it MUST
+   also comply with the section 4.3.
+
+4.1.  Server that supports arbitrary keywords
+
+   No changes are required from the server to make it compatible with
+   the extension described in this document if it supports arbitrary
+   keywords.
+
+4.2.  Server that supports only $MDNSent keyword
+
+   Servers that support only the $MDNSent keyword MUST preserve it on
+   the COPY operation.  It is also expected that a server that supports
+   SEARCH <flag> will also support the SEARCH KEYWORD $MDNSent.
+
+
+
+
+
+Melnikov                    Standards Track                     [Page 5]
+
+RFC 3503                  MDN profile for IMAP                March 2003
+
+
+4.3.  Interaction with IMAP ACL extension
+
+   Any server that conforms to either 4.1 or 4.2 and also supports the
+   IMAP [ACL] extension, SHOULD preserve the $MDNSent keyword on COPY
+   even if the client does not have 'w' right.  This will prevent the
+   generation of a duplicated MDN for the same message.  Note that the
+   server MUST still check if the client has rights to perform the COPY
+   operation on a message according to [ACL].
+
+5.  Examples
+
+   1) MUA opens mailbox for the first time.
+
+   a) The server supports storing of arbitrary keywords
+
+   C: a100 select INBOX
+   S: * FLAGS (\Flagged \Draft \Deleted \Seen)
+   S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen \*)]
+   S: * 5 EXISTS
+   S: * 3 RECENT
+   S: * OK [UIDVALIDITY 894294713]
+   S: a100 OK [READ-WRITE] Completed
+
+   b) The server supports storing of the $MDNSent keyword
+
+   C: a100 select INBOX
+   S: * FLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)
+   S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)]
+   S: * 5 EXISTS
+   S: * 3 RECENT
+   S: * OK [UIDVALIDITY 894294713]
+   S: a100 OK [READ-WRITE] Completed
+
+   2) The MUA successfully sets the $MDNSent keyword
+
+   C: a200 STORE 4 +FLAGS ($MDNSent)
+   S: * 4 FETCH (FLAGS (\Flagged \Seen $MDNSent))
+   S: * FLAGS ($MDNSent \Flagged \Deleted \Draft \Seen)
+   S: * OK [PERMANENTFLAGS ($MDNSent \Flagged \Deleted \Draft \Seen \*)]
+   S: a200 OK STORE completed
+
+   3) The server refuses to store the $MDNSent keyword
+
+   C: a200 STORE 4 +FLAGS ($MDNSent)
+   S: a200 NO STORE failed : no space left to store $MDNSent keyword
+
+
+
+
+
+
+Melnikov                    Standards Track                     [Page 6]
+
+RFC 3503                  MDN profile for IMAP                March 2003
+
+
+   4) All clients and servers MUST treat the $MDNSent keyword as case
+   insensitive in all operations, as stated in [IMAP].
+
+   C: a300 FETCH 1:* FLAGS
+   S: * 1 FETCH (FLAGS (\Seen))
+   S: * 2 FETCH (FLAGS (\Answered \Seen $MdnSENt))
+   S: * 3 FETCH (FLAGS ())
+   S: * 4 FETCH (FLAGS (\Flagged \Seen $MdnSENT))
+   S: * 5 FETCH (FLAGS ($MDNSent))
+   S: * 6 FETCH (FLAGS (\Recent))
+   S: a300 OK FETCH completed
+   C: a400 SEARCH KEYWORDS $mdnsent
+   S: * SEARCH 2 4 5
+   S: a400 OK SEARCH completed
+
+6.  Security Considerations
+
+   There are no known security issues with this extension, not found in
+   [MDN] and/or [IMAP4].
+
+   Section 4.3 changes ACL checking requirements on an IMAP server that
+   implements IMAP [ACL] extension.
+
+7.  Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) notation as specified in [RFC-822], as modified by
+   [IMAP4].  Non-terminals referenced, but not defined below, are as
+   defined by [IMAP4].
+
+   Except as noted otherwise, all alphabetic characters are case-
+   insensitive.  The use of upper or lower case characters to define
+   token strings is for editorial clarity only.  Implementations MUST
+   accept these strings in a case-insensitive fashion.
+
+   flag_keyword    ::= "$MDNSent" / other_keywords
+
+   other_keywords  ::= atom
+
+8.  Acknowledgments
+
+   This document is the product of discussions that took place on the
+   IMAP mailing list.  Special gratitude to Cyrus Daboo and Randall
+   Gellens for reviewing the document.
+
+   Thank you to my father who as he has helped to make me what I am.  I
+   miss you terribly.
+
+
+
+
+Melnikov                    Standards Track                     [Page 7]
+
+RFC 3503                  MDN profile for IMAP                March 2003
+
+
+9.  Normative References
+
+   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [MDN]      Fajman, R., "An Extensible Message Format for Message
+              Disposition Notifications", RFC 2298, March 1998.
+
+   [IMAP4]    Crispin, M., "Internet Message Access Protocol - Version
+              4rev1", RFC 3501, March 2003.
+
+   [ACL]      Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
+
+10.  Author's Address
+
+   Alexey Melnikov
+   ACI Worldwide/MessagingDirect
+   59 Clarendon Road
+   Watford, Hertfordshire
+   United Kingdom, WD17 1FQ
+
+   Phone: +44 1923 81 2877
+   EMail: mel@messagingdirect.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                     [Page 8]
+
+RFC 3503                  MDN profile for IMAP                March 2003
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                     [Page 9]
+
diff --git a/docs/rfcs/rfc3516.txt b/docs/rfcs/rfc3516.txt
new file mode 100644
index 0000000..4d02197
--- /dev/null
+++ b/docs/rfcs/rfc3516.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                       L. Nerenberg
+Request for Comments: 3516                               Orthanc Systems
+Category: Standards Track                                     April 2003
+
+
+                     IMAP4 Binary Content Extension
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This memo defines the Binary extension to the Internet Message Access
+   Protocol (IMAP4).  It provides a mechanism for IMAP4 clients and
+   servers to exchange message body data without using a MIME content-
+   transfer-encoding.
+
+1.   Conventions Used in this Document
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+   in this document are to be interpreted as described in [KEYWORD].
+
+   The abbreviation "CTE" means content-transfer-encoding.
+
+2.   Introduction
+
+   The MIME extensions to Internet messaging allow for the transmission
+   of non-textual (binary) message content [MIME-IMB].  Since the
+   traditional transports for messaging are not always capable of
+   passing binary data transparently, MIME provides encoding schemes
+   that allow binary content to be transmitted over transports that are
+   not otherwise able to do so.
+
+   The overhead of MIME-encoding this content can be considerable in
+   some contexts (e.g., slow radio links, streaming multimedia).
+   Reducing the overhead associated with CTE schemes such as base64
+
+
+
+
+
+
+Nerenberg                   Standards Track                     [Page 1]
+
+RFC 3516             IMAP4 Binary Content Extension           April 2003
+
+
+   can give a noticeable reduction in resource consumption.  The Binary
+   extension lets the server perform CTE decoding prior to transmitting
+   message data to the client.
+
+3.  Content-Transfer-Encoding Considerations
+
+   Every IMAP4 body section has a MIME content-transfer-encoding.
+   (Those without an explicit Content-Transfer-Encoding header are
+   implicitly labeled as "7bit" content.)  In the terminology of [MIME-
+   IMB], the CTE specifies both a decoding algorithm and the domain of
+   the decoded data.  In this memo, "decoding" refers to the CTE
+   decoding step described in [MIME-IMB].
+
+   Certain CTEs use an identity encoding transformation.  For these CTEs
+   there is no decoding required, however the domain of the underlying
+   data may not be expressible in the IMAP4 protocol (e.g., MIME
+   "binary" content containing NUL octets).  To accommodate these cases
+   the Binary extension introduces a new type of literal protocol
+   element that is fully eight bit transparent.
+
+   Thus, server  processing of the FETCH BINARY command involves two
+   logical steps:
+
+   1)  perform any CTE-related decoding
+
+   2)  determine the domain of the decoded data
+
+   Step 2 is necessary to determine which protocol element should be
+   used to transmit the decoded data.  (See FETCH Response Extensions
+   for further details.)
+
+4.  Framework for the IMAP4 Binary Extension
+
+   This memo defines the following extensions to [IMAP4rev1].
+
+4.1.  CAPABILITY Identification
+
+   IMAP4 servers that support this extension MUST include "BINARY" in
+   the response list to the CAPABILITY command.
+
+4.2.  FETCH Command Extensions
+
+   This extension defines three new FETCH command data items.
+
+      BINARY<section-binary>[<partial>]
+
+         Requests that the specified section be transmitted after
+         performing CTE-related decoding.
+
+
+
+Nerenberg                   Standards Track                     [Page 2]
+
+RFC 3516             IMAP4 Binary Content Extension           April 2003
+
+
+         The <partial> argument, if present, requests that a subset of
+         the data be returned.  The semantics of a partial FETCH BINARY
+         command are the same as for a partial FETCH BODY command, with
+         the exception that the <partial> arguments refer to the DECODED
+         section data.
+
+      BINARY.PEEK<section-binary>[<partial>]
+
+         An alternate form of FETCH BINARY that does not implicitly set
+         the \Seen flag.
+
+      BINARY.SIZE<section-binary>
+
+         Requests the decoded size of the section (i.e., the size to
+         expect in response to the corresponding FETCH BINARY request).
+
+         Note: client authors are cautioned that this might be an
+         expensive operation for some server implementations.
+         Needlessly issuing this request could result in degraded
+         performance due to servers having to calculate the value every
+         time the request is issued.
+
+4.3.  FETCH Response Extensions
+
+   This extension defines two new FETCH response data items.
+
+      BINARY<section-binary>[<<number>>]
+
+         An <nstring> or <literal8> expressing the content of the
+         specified section after removing any CTE-related encoding.  If
+         <number> is present it refers to the offset within the DECODED
+         section data.
+
+         If the domain of the decoded data is "8bit" and the data does
+         not contain the NUL octet, the server SHOULD return the data in
+         a <string> instead of a <literal8>; this allows the client to
+         determine if the "8bit" data contains the NUL octet without
+         having to explicitly scan the data stream for for NULs.
+
+         If the server does not know how to decode the section's CTE, it
+         MUST fail the request and issue a "NO" response that contains
+         the "UNKNOWN-CTE" extended response code.
+
+
+
+
+
+
+
+
+
+Nerenberg                   Standards Track                     [Page 3]
+
+RFC 3516             IMAP4 Binary Content Extension           April 2003
+
+
+      BINARY.SIZE<section-binary>
+
+         The size of the section after removing any CTE-related
+         encoding.  The value returned MUST match the size of the
+         <nstring> or <literal8> that will be returned by the
+         corresponding FETCH BINARY request.
+
+         If the server does not know how to decode the section's CTE, it
+         MUST fail the request and issue a "NO" response that contains
+         the "UNKNOWN-CTE" extended response code.
+
+4.4.  APPEND Command Extensions
+
+   The APPEND command is extended to allow the client to append data
+   containing NULs by using the <literal8> syntax.  The server MAY
+   modify the CTE of the appended data, however any such transformation
+   MUST NOT result in a loss of data.
+
+   If the destination mailbox does not support the storage of binary
+   content, the server MUST fail the request and issue a "NO" response
+   that contains the "UNKNOWN-CTE" extended response code.
+
+5.  MIME Encoded Headers
+
+   [MIME-MHE] defines an encoding that allows for non-US-ASCII text in
+   message headers.  This encoding is not the same as the content-
+   transfer-encoding applied to message bodies, and the decoding
+   transformations described in this memo do not apply to [MIME-MHE]
+   encoded header text.  A server MUST NOT perform any conversion of
+   [MIME-MHE] encoded header text in response to any binary FETCH or
+   APPEND request.
+
+6.  Implementation Considerations
+
+   Messaging clients and servers have been notoriously lax in their
+   adherence to the Internet CRLF convention for terminating lines of
+   textual data in Internet protocols.  When sending data using the
+   Binary extension, servers MUST ensure that textual line-oriented
+   sections are always transmitted using the IMAP4 CRLF line termination
+   syntax, regardless of the underlying storage representation of the
+   data on the server.
+
+   A server may choose to store message body binary content in a non-
+   encoded format.  Regardless of the internal storage representation
+   used, the server MUST issue BODYSTRUCTURE responses that describe the
+   message as though the binary-encoded sections are encoded in a CTE
+
+
+
+
+
+Nerenberg                   Standards Track                     [Page 4]
+
+RFC 3516             IMAP4 Binary Content Extension           April 2003
+
+
+   acceptable to the IMAP4 base specification.  Furthermore, the results
+   of a FETCH BODY MUST return the message body content in the format
+   described by the corresponding FETCH BODYSTRUCTURE response.
+
+   While the server is allowed to modify the CTE of APPENDed <literal8>
+   data, this should only be done when it is absolutely necessary.
+   Gratuitous encoding changes will render useless most cryptographic
+   operations that have been performed on the message.
+
+   This extension provides an optimization that is useful in certain
+   specific situations.  It does not absolve clients from providing
+   basic functionality (content transfer decoding) that should be
+   available in all messaging clients.  Clients supporting this
+   extension SHOULD be prepared to perform their own CTE decoding
+   operations.
+
+7.  Formal Protocol Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (ABNF) notation as used in [ABNF], and incorporates by reference
+   the Core Rules defined in that document.
+
+   This syntax augments the grammar specified in [IMAP4rev1].
+
+   append         =/  "APPEND" SP mailbox [SP flag-list]
+                      [SP date-time] SP literal8
+
+   fetch-att      =/  "BINARY" [".PEEK"] section-binary [partial]
+                      / "BINARY.SIZE" section-binary
+
+   literal8       =   "~{" number "}" CRLF *OCTET
+                      ; <number> represents the number of OCTETs
+                      ; in the response string.
+
+   msg-att-static =/  "BINARY" section-binary SP (nstring / literal8)
+                      / "BINARY.SIZE" section-binary SP number
+
+   partial        =   "<" number "." nz-number ">"
+
+   resp-text-code =/  "UNKNOWN-CTE"
+
+   section-binary =   "[" [section-part] "]"
+
+
+
+
+
+
+
+
+
+Nerenberg                   Standards Track                     [Page 5]
+
+RFC 3516             IMAP4 Binary Content Extension           April 2003
+
+
+8.  Normative References
+
+   [ABNF]      Crocker, D., Editor, and P. Overell, "Augmented BNF for
+               Syntax Specifications: ABNF", RFC 2234, November 1997.
+
+   [IMAP4rev1] Crispin, M., "Internet Message Access Protocol Version
+               4rev1", RFC 3501, March 2003.
+
+   [KEYWORD]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [MIME-IMB]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [MIME-MHE]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
+               Part Three: Message Header Extensions for Non-ASCII
+               Text", RFC 2047, November 1996.
+
+9.  Security Considerations
+
+   There are no known additional security issues with this extension
+   beyond those described in the base protocol described in [IMAP4rev1].
+
+10.  Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+
+Nerenberg                   Standards Track                     [Page 6]
+
+RFC 3516             IMAP4 Binary Content Extension           April 2003
+
+
+11.  Author's Address
+
+   Lyndon Nerenberg
+   Orthanc Systems
+   1606 - 10770 Winterburn Road
+   Edmonton, Alberta
+   Canada  T5S 1T6
+
+   EMail: lyndon@orthanc.ab.ca
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nerenberg                   Standards Track                     [Page 7]
+
+RFC 3516             IMAP4 Binary Content Extension           April 2003
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nerenberg                   Standards Track                     [Page 8]
+
diff --git a/docs/rfcs/rfc3656.txt b/docs/rfcs/rfc3656.txt
new file mode 100644
index 0000000..6c0ab5b
--- /dev/null
+++ b/docs/rfcs/rfc3656.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                      R. Siemborski
+Request for Comments: 3656                    Carnegie Mellon University
+Category: Experimental                                     December 2003
+
+
+                     The Mailbox Update (MUPDATE)
+                 Distributed Mailbox Database Protocol
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   As the demand for high-performance mail delivery agents increases, it
+   becomes apparent that single-machine solutions are inadequate to the
+   task, both because of capacity limits and that the failure of the
+   single machine means a loss of mail delivery for all users.  It is
+   preferable to allow many machines to share the responsibility of mail
+   delivery.
+
+   The Mailbox Update (MUPDATE) protocol allows a group of Internet
+   Message Access Protocol (IMAP) or Post Office Protocol - Version 3
+   (POP3) servers to function with a unified mailbox namespace.  This
+   document is intended to serve as a reference guide to that protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Siemborski                    Experimental                      [Page 1]
+
+RFC 3656     MUPDATE Distributed Mailbox Database Protocol December 2003
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   3
+       2.1.  Atoms . . . . . . . . . . . . . . . . . . . . . . . . .   4
+       2.2.  Strings . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3.  Server Responses  . . . . . . . . . . . . . . . . . . . . . .   4
+       3.1.  Response: OK  . . . . . . . . . . . . . . . . . . . . .   5
+       3.2.  Response: NO  . . . . . . . . . . . . . . . . . . . . .   5
+       3.3.  Response: BAD . . . . . . . . . . . . . . . . . . . . .   5
+       3.4.  Response: BYE . . . . . . . . . . . . . . . . . . . . .   6
+       3.5.  Response: RESERVE . . . . . . . . . . . . . . . . . . .   6
+       3.6.  Response: MAILBOX . . . . . . . . . . . . . . . . . . .   6
+       3.7.  Response: DELETE  . . . . . . . . . . . . . . . . . . .   7
+       3.8.  Server Capability Response. . . . . . . . . . . . . . .   7
+   4.  Client Commands . . . . . . . . . . . . . . . . . . . . . . .   8
+       4.1.  Command: ACTIVATE . . . . . . . . . . . . . . . . . . .   8
+       4.2.  Command: AUTHENTICATE . . . . . . . . . . . . . . . . .   8
+       4.3.  Command: DEACTIVATE . . . . . . . . . . . . . . . . . .   9
+       4.4.  Command: DELETE . . . . . . . . . . . . . . . . . . . .   9
+       4.5.  Command: FIND . . . . . . . . . . . . . . . . . . . . .   9
+       4.6.  Command: LIST . . . . . . . . . . . . . . . . . . . . .  10
+       4.7.  Command: LOGOUT . . . . . . . . . . . . . . . . . . . .  10
+       4.8.  Command: NOOP . . . . . . . . . . . . . . . . . . . . .  10
+       4.9.  Command: RESERVE. . . . . . . . . . . . . . . . . . . .  10
+       4.10. Command: STARTTLS . . . . . . . . . . . . . . . . . . .  11
+       4.11. Command: UPDATE . . . . . . . . . . . . . . . . . . . .  12
+   5.  MUPDATE Formal Syntax . . . . . . . . . . . . . . . . . . . .  12
+   6.  MUPDATE URL Scheme. . . . . . . . . . . . . . . . . . . . . .  14
+       6.1.  MUPDATE URL Scheme Registration Form. . . . . . . . . .  14
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
+   9.  Intellectual Property Rights. . . . . . . . . . . . . . . . .  16
+   10. References. . . . . . . . . . . . . . . . . . . . . . . . . .  17
+       10.1. Normative References. . . . . . . . . . . . . . . . . .  17
+       10.2. Informative References. . . . . . . . . . . . . . . . .  17
+   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  18
+   12. Author's Address. . . . . . . . . . . . . . . . . . . . . . .  18
+   13. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  19
+
+
+
+
+
+
+
+
+
+
+
+
+Siemborski                    Experimental                      [Page 2]
+
+RFC 3656     MUPDATE Distributed Mailbox Database Protocol December 2003
+
+
+1.  Introduction
+
+   In order to support an architecture where there are multiple [IMAP,
+   POP3] servers sharing a common mailbox database, it is necessary to
+   be able to provide atomic mailbox operations, as well as offer
+   sufficient guarantees about database consistency.
+
+   The primary goal of the MUPDATE protocol is to be simple to implement
+   yet allow for database consistency between participants.
+
+   The key words "MUST, "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
+   "RECOMMENDED", and "MAY" in this document are to be interpreted as
+   defined in BCP 14, RFC 2119 [KEYWORDS].
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+2.  Protocol Overview
+
+   The MUPDATE protocol assumes a reliable data stream such as a TCP
+   network connection.  IANA has registered port 3905 with a short name
+   of "mupdate" for this purpose.
+
+   In the current implementation of the MUPDATE protocol there are three
+   types of participants: a single master server, slave (or replica)
+   servers, and clients.  The master server maintains an authoritative
+   copy of the mailbox database.  Slave servers connect to the MUPDATE
+   master server as clients, and function as replicas from the point of
+   view of end clients.  End clients may connect to either the master or
+   any slave and perform searches against the database, however
+   operations that change the database can only be performed against the
+   master.  For the purposes of protocol discussion we will consider a
+   slave's connection to the master identical to that of any other
+   client.
+
+   After connection, all commands from a client to server must have an
+   associated unique tag which is an alphanumeric string.  Commands MAY
+   be pipelined from the client to the server (that is, the client need
+   not wait for the response before sending the next command).  The
+   server MUST execute the commands in the order they were received,
+   however.
+
+   If the server supports an inactivity login timeout, it MUST be at
+   least 15 minutes.
+
+
+
+
+
+
+
+Siemborski                    Experimental                      [Page 3]
+
+RFC 3656     MUPDATE Distributed Mailbox Database Protocol December 2003
+
+
+   MUPDATE uses data formats similar to those used in [ACAP].  That is,
+   atoms and strings.  All commands and tags in the protocol are
+   transmitted as atoms.  All other data is considered to a string, and
+   must be quoted or transmitted as a literal.
+
+   Outside of a literal, both clients and servers MUST support line
+   lengths of at least 1024 octets (including the trailing CR and LF
+   characters).  If a line of a longer length must be transmitted,
+   implementations MUST make use of literals to do so.
+
+2.1.  Atoms
+
+   An atom consists of one or more alphanumeric characters.  Atoms MUST
+   be less than 15 octets in length.
+
+2.2.  Strings
+
+   As in [ACAP], a string may be either literal or a quoted string.  A
+   literal is a sequence of zero or more octets (including CR and LF),
+   prefix-quoted with an octet count in the form of an open brace ("{"),
+   the number of octets, an optional plus sign to indicate that the data
+   follows immediately (a non-synchronized literal), a close brace
+   ("}"), and a CRLF sequence.  If the plus sign is omitted (a
+   synchronized literal), then the receiving side MUST send a "+ go
+   ahead" response, and the sending side MUST wait for this response.
+   Servers MUST support literals of atleast 4096 octets.
+
+   Strings that are sent from server to client SHOULD NOT be in the
+   synchronized literal format.
+
+   A quoted string is a sequence of zero or more 7-bit characters,
+   excluding CR, LF, and the double quote (<">), with double quote
+   characters at each end.
+
+   The empty string is represented as either "" (a quoted string with
+   zero characters between double quotes) or as {0} followed by CRLF (a
+   literal with an octet count of 0).
+
+3.  Server Responses
+
+   Every client command in the MUPDATE protocol may receive one or more
+   tagged responses from the server.  Each response is preceded by the
+   same tag as the command that elicited the response from the server.
+
+
+
+
+
+
+
+
+Siemborski                    Experimental                      [Page 4]
+
+RFC 3656     MUPDATE Distributed Mailbox Database Protocol December 2003
+
+
+3.1.  Response: OK
+
+   A tagged OK response indicates that the operation completed
+   successfully.  There is a mandatory implementation-defined string
+   after the OK response.  This response also indicates the beginning of
+   the streaming update mode when given in response to an UPDATE
+   command.
+
+   Example:
+
+C: N01 NOOP
+S: N01 OK "NOOP Complete"
+
+3.2.  Response: NO
+
+   A tagged NO response indicates that the operation was explicitly
+   denied by the server or otherwise failed.  There is a mandatory
+   implementation-defined string after the NO response that SHOULD
+   explain the reason for denial.
+
+   Example:
+
+C: A01 AUTHENTICATE "PLAIN"
+S: A01 NO "PLAIN is not a supported SASL mechanism"
+
+3.3.  Response: BAD
+
+   A tagged BAD response indicates that the command from the client
+   could not be parsed or understood.  There is a mandatory
+   implementation-defined string after the BAD response to provide
+   additional information about the error.  Note that untagged BAD
+   responses are allowed if it is unclear what the tag for a given
+   command is (for example, if a blank line is received by the mupdate
+   server, it can generate an untagged BAD response).  In the case of an
+   untagged response, the tag should be replaced with a "*".
+
+   Example:
+
+C: C01 SELECT "INBOX"
+S: C01 BAD "This is not an IMAP server"
+C:
+S: * BAD "Need Command"
+
+
+
+
+
+
+
+
+
+Siemborski                    Experimental                      [Page 5]
+
+RFC 3656     MUPDATE Distributed Mailbox Database Protocol December 2003
+
+
+3.4.  Response: BYE
+
+   A tagged BYE response indicates that the server has decided to close
+   the connection.  There is a mandatory implementation-defined string
+   after the BYE response that SHOULD explain the reason for closing the
+   connection.  The server MUST close the connection immediately after
+   transmitting the BYE response.
+
+   Example:
+
+C: L01 LOGOUT
+S: L01 BYE "User Logged Out"
+
+3.5.  Response: RESERVE
+
+   A tagged RESERVE response may only be given in response to a FIND,
+   LIST, or UPDATE command.  It includes two parameters: the name of the
+   mailbox that is being reserved (in mUTF-7 encoding, as specified in
+   [IMAP]) and a location string whose contents is defined by the
+   clients that are using the database, though it is RECOMMENDED that
+   the format of this string be the hostname of the server which is
+   storing the mailbox.
+
+   This response indicates that the given name is no longer available in
+   the namespace, though it does not indicate that the given mailbox is
+   available to clients at the current time.
+
+   Example:
+
+S: U01 RESERVE "internet.bugtraq" "mail2.example.org"
+
+3.6.  Response: MAILBOX
+
+   A tagged MAILBOX response may only be given in response to a FIND,
+   LIST, or UPDATE command.  It includes three parameters: the name of
+   the mailbox, a location string (as with RESERVE), and a client-
+   defined string that specifies the IMAP ACL [IMAP-ACL] of the mailbox.
+   This message indicates that the given mailbox is ready to be accessed
+   by clients.
+
+   Example:
+
+S: U01 MAILBOX "internet.bugtraq" "mail2.example.org" "anyone rls"
+
+
+
+
+
+
+
+
+Siemborski                    Experimental                      [Page 6]
+
+RFC 3656     MUPDATE Distributed Mailbox Database Protocol December 2003
+
+
+3.7.  Response: DELETE
+
+   A tagged DELETE response may only be given in response to an UPDATE
+   command, and MUST NOT be given before the OK response to the UPDATE
+   command is given.  It contains a single parameter, that of the
+   mailbox that should be deleted from the slave's database.  This
+   response indicates that the given mailbox no longer exists in the
+   namespace of the database, and may be given for any mailbox name,
+   active, reserved, or nonexistent.  (Though implementations SHOULD NOT
+   issue DELETE responses for nonexistent mailboxes).
+
+   Example:
+
+S: U01 DELETE "user.rjs3.sent-mail-jan-2002"
+
+3.8.  Server Capability Response
+
+   Upon connection of the client to the server, and directly following a
+   successful STARTTLS command, the server MUST issue a capabilities
+   banner, of the following format:
+
+   The banner MUST contain a line that begins with "* AUTH" and contain
+   a space-separated list of SASL mechanisms that the server will accept
+   for authentication.  The mechanism names are transmitted as atoms.
+   Servers MAY advertise no available mechanisms (to indicate that
+   STARTTLS must be completed before authentication may occur).  If
+   STARTTLS is not supported by the server, then the line MUST contain
+   at least one mechanism.
+
+   If the banner is being issued without a TLS layer, and the server
+   supports the STARTTLS command, the banner MUST contain the line "*
+   STARTTLS".  If the banner is being issued under a TLS layer (or the
+   server does not support STARTTLS), the banner MUST NOT contain this
+   line.
+
+   The last line of the banner MUST start with "* OK MUPDATE" and be
+   followed by four strings: the server's hostname, an implementation-
+   defined string giving the name of the implementation, an
+   implementation-defined string giving the version of the
+   implementation, and a string that indicates if the server is a master
+   or a slave.  The master/slave indication MUST be either "(master)" or
+   an MUPDATE URL that defines where the master can be contacted.
+
+   Any unrecognized responses before the "* OK MUPDATE" response MUST be
+   ignored by the client.
+
+
+
+
+
+
+Siemborski                    Experimental                      [Page 7]
+
+RFC 3656     MUPDATE Distributed Mailbox Database Protocol December 2003
+
+
+   Example:
+
+S: * AUTH KERBEROS_V4 GSSAPI
+S: * STARTTLS
+S: * OK MUPDATE "mupdate.example.org" "Cyrus" "v2.1.2" "(master)"
+
+4.  Client Commands
+
+   The following are valid commands that a client may send to the
+   MUPDATE server: AUTHENTICATE, ACTIVATE, DEACTIVATE, DELETE, FIND,
+   LIST, LOGOUT, NOOP, RESERVE, STARTTLS, and UPDATE.
+
+   Before a successful AUTHENTICATE command has occurred, the server
+   MUST NOT accept any commands except for AUTHENTICATE, STARTTLS, and
+   LOGOUT (and SHOULD reply with a NO response for all other commands).
+
+4.1.  Command: ACTIVATE
+
+   The ACTIVATE command has 3 parameters: the mailbox name, its
+   location, and its ACL.  This command MUST NOT not be issued to a
+   slave server.
+
+   This command can also be used to update the ACL or location
+   information of a mailbox.  Note that it is not a requirement for a
+   mailbox to be reserved (or even exist in the database) for an
+   ACTIVATE command to succeed, implementations MUST allow this behavior
+   as it facilitates synchronization of the database with the current
+   state of the mailboxes.
+
+4.2.  Command: AUTHENTICATE
+
+   The AUTHENTICATE command initiates a [SASL] negotiation session
+   between the client and the server.  It has two parameters.  The first
+   parameter is mandatory, and is a string indicating the desired [SASL]
+   mechanism.  The second is a string containing an optional BASE64
+   encoded (as defined in section 6.8 of [MIME]) client first send.
+
+   All of the remaining SASL blobs that are sent MUST be sent across the
+   wire must be in BASE64 encoded format, and followed by a CR and LF
+   combination.  They MUST NOT be encoded as strings.
+
+   Clients may cancel authentication by sending a * followed by a CR and
+   LF.
+
+   The [SASL] service name for the MUPDATE protocol is "mupdate".
+   Implementations are REQUIRED to implement the GSSAPI [SASL]
+   mechanism, though they SHOULD implement as many mechanisms as
+   possible.
+
+
+
+Siemborski                    Experimental                      [Page 8]
+
+RFC 3656     MUPDATE Distributed Mailbox Database Protocol December 2003
+
+
+   If a security layer is negotiated, it should be used directly
+   following the CR and LF combination at the end of the server's OK
+   response (i.e., beginning with the client's next command) Only one
+   successful AUTHENTICATE command may be issued per session.
+
+4.3.  Command: DEACTIVATE
+
+   The DEACTIVATE command takes two parameters, the mailbox name and
+   location data.  The mailbox MUST already exist and be activated on
+   the MUPDATE server.  If the server responds OK, then the mailbox name
+   has been moved to the RESERVE state.  If the server responds NO, then
+   the mailbox name has not been moved (for example, the mailbox was not
+   already active).  Any ACL information that is known about the mailbox
+   MAY be lost when a DEACTIVATE succeeds.  This command MUST NOT be
+   issued to a slave.
+
+   Example:
+
+C: A01 DEACTIVATE "user.rjs3.new" "mail3.example.org!u4"
+S: A01 OK "Mailbox Reserved."
+
+4.4.  Command: DELETE
+
+   The DELETE command takes only a single parameter, the mailbox name to
+   be removed from the database's namespace.  The server SHOULD give a
+   NO response if the mailbox does not exist.  This command MUST NOT be
+   issued to a slave server.
+
+4.5.  Command: FIND
+
+   The FIND command takes a single parameter, a mailbox name.  The
+   server then responds with the current record for the given mailbox,
+   if any, and an OK response.
+
+   Example (mailbox does not exist):
+
+C: F01 FIND "user.rjs3.xyzzy"
+S: F01 OK "Search Complete"
+
+   Example (mailbox is reserved):
+
+C: F01 FIND "user.rjs3"
+S: F01 RESERVE "user.rjs3" "mail4.example.org"
+S: F01 OK "Search Complete"
+
+
+
+
+
+
+
+Siemborski                    Experimental                      [Page 9]
+
+RFC 3656     MUPDATE Distributed Mailbox Database Protocol December 2003
+
+
+4.6.  Command: LIST
+
+   The LIST command is similar to running FIND across the entire
+   database.  The LIST command takes a single optional parameter, which
+   is a prefix to try to match against the location field of the
+   records.  Without the parameter, LIST returns every record in the
+   database.
+
+   For each mailbox that matches, either a MAILBOX or a RESERVE response
+   (as applicable) is sent to the client.  When all responses are
+   complete, an OK response is issued.
+
+   Example:
+
+C: L01 LIST
+S: L01 RESERVE "user.rjs3" "mail4.example.org!u2"
+S: L01 MAILBOX "user.leg" "mail2.example.org!u1" "leg lrswipcda"
+S: L01 OK "List Complete"
+C: L02 LIST "mail4.example.org!"
+S: L02 RESERVE "user.rjs3" "mail4.example.org!u2"
+S: L02 OK "List Complete"
+
+4.7.  Command: LOGOUT
+
+   The LOGOUT command tells the server to close the connection.  Its
+   only valid response is the BYE response.  The LOGOUT command takes no
+   parameters.
+
+4.8.  Command: NOOP
+
+   The NOOP command takes no parameters.  Provided the client is
+   authenticated, its only acceptable response is an OK.  Any idle
+   timeouts that the server may have on the connection SHOULD be reset
+   upon receipt of this command.
+
+   If this command is issued after an UPDATE command has been issued,
+   then the OK response also indicates that all pending database updates
+   have been sent to the client.  That is, the slave can guarantee that
+   its local database is up to date as of a certain time by issuing a
+   NOOP and waiting for the OK.  The OK MUST NOT return until all
+   updates that were pending at the time of the NOOP have been sent.
+
+4.9.  Command: RESERVE
+
+   The RESERVE command takes two parameters (just like the RESERVE
+   response), the mailbox name to reserve and location data.  If the
+   server responds OK, then the mailbox name has been reserved.  If the
+   server responds NO, then the mailbox name has not been reserved (for
+
+
+
+Siemborski                    Experimental                     [Page 10]
+
+RFC 3656     MUPDATE Distributed Mailbox Database Protocol December 2003
+
+
+   example, another server has reserved it already).  This command MUST
+   NOT be issued to a slave.
+
+   The typical sequence for mailbox creation is:
+
+C: R01 RESERVE "user.rjs3.new" "mail3.example.org!u4"
+S: R01 OK "Mailbox Reserved."
+<client does local mailbox create operations>
+C: A01 ACTIVATE "user.rjs3.new" "mail3.example.org!u4" "rjs3 lrswipcda"
+S: A01 OK "Mailbox Activated."
+
+4.10.  Command: STARTTLS
+
+   The STARTTLS command requests the commencement of a [TLS]
+   negotiation.  The negotiation begins immediately after the CRLF in
+   the OK response.  After a client issues a STARTTLS command, it MUST
+   NOT issue further commands until a server response is seen and the
+   [TLS] negotiation is complete.
+
+   The STARTTLS command is only valid in non-authenticated state.  The
+   server remains in non-authenticated state, even if client credentials
+   are supplied during the [TLS] negotiation.  The [SASL] EXTERNAL
+   mechanism MAY be used to authenticate once [TLS] client credentials
+   are successfully exchanged.  Note that servers are not required to
+   support the EXTERNAL mechanism.
+
+   After the [TLS] layer is established, the server MUST re-issue the
+   initial response banner (see Section 3.8).  This is necessary to
+   protect against man-in-the-middle attacks which alter the
+   capabilities list prior to STARTTLS, as well as to advertise any new
+   SASL mechanisms (or other capabilities) that may be available under
+   the layer.  The client MUST discard cached capability information and
+   replace it with the new information.
+
+   After the a successful STARTTLS command, the server SHOULD return a
+   NO response to additional STARTTLS commands.
+
+   Servers MAY choose to not implement STARTTLS.  In this case, they
+   MUST NOT advertise STARTTLS in their capabilities banner, and SHOULD
+   return a BAD response to the STARTTLS command, if it is issued.
+
+   Example:
+
+C: S01 STARTTLS
+S: S01 OK "Begin TLS negotiation now"
+<TLS negotiation, further commands are under TLS layer>
+S: * AUTH KERBEROS_V4 GSSAPI PLAIN
+S: * OK MUPDATE "mupdate.example.org" "Cyrus" "v2.1.2" "(master)"
+
+
+
+Siemborski                    Experimental                     [Page 11]
+
+RFC 3656     MUPDATE Distributed Mailbox Database Protocol December 2003
+
+
+4.11.  Command: UPDATE
+
+   The UPDATE command is how a slave initializes an update stream from
+   the master (though it is also valid to issue this command to a
+   slave).  In response to the command, the server returns a list of all
+   mailboxes in its database (the same results as a parameterless LIST
+   command) followed by an OK response.  From this point forward,
+   whenever an update occurs to the master database, it MUST stream the
+   update to the slave within 30 seconds.  That is, it will send
+   RESERVE, MAILBOX, or DELETE responses as they are applicable.
+
+   After a client has issued an UPDATE command, it may only issue NOOP
+   and LOGOUT commands for the remainder of the session.
+
+   Example:
+
+C: U01 UPDATE
+S: U01 MAILBOX "user.leg" "mail2.example.org!u1" "leg lrswipcda"
+S: U01 MAILBOX "user.rjs3" "mail3.example.org!u4" "rjs3 lrswipcda"
+S: U01 RESERVE "internet.bugtraq" "mail1.example.org!u5" "anyone lrs"
+S: U01 OK "Streaming Begins"
+<some time goes by, and another client creates a new mailbox>
+S: U01 RESERVE "user.leg.new" "mail2.example.org!u1"
+<some more time passes, and the create succeeds>
+S: U01 MAILBOX "user.leg.new" "mail2.example.org!u1" "leg lrswipcda"
+<much more time passes, and the slave decides to send a NOOP to reset
+its inactivity timer>
+C: N01 NOOP
+S: U01 DELETE "user.leg.new"
+S: N01 OK "NOOP Complete"
+
+5.  MUPDATE Formal Syntax
+
+   The following syntax specification uses the Augmented Backus-Naur
+   Form (ABNF) notation as specified in [ABNF].  This uses the ABNF core
+   rules as specified in Appendix A of [ABNF].
+
+   Except as noted otherwise, all alphabetic characters are case-
+   insensitive.  The use of upper or lower case characters to define
+   token strings is for editorial clarity only.  Implementations MUST
+   accept these strings in a case-insensitive fashion.
+
+   Note that this specification also uses some terminals from section 8
+   of [ACAP].
+
+   cmd-activate = "ACTIVATE" SP string SP string SP string
+
+   cmd-authenticate = "AUTHENTICATE" SP sasl-mech [ SP string ]
+
+
+
+Siemborski                    Experimental                     [Page 12]
+
+RFC 3656     MUPDATE Distributed Mailbox Database Protocol December 2003
+
+
+   cmd-delete = "DELETE" SP string
+
+   cmd-find = "FIND" SP string
+
+   cmd-list = "LIST" [ SP string ]
+
+   cmd-logout = "LOGOUT"
+
+   cmd-noop = "NOOP"
+
+   cmd-reserve = "RESERVE" SP string SP string
+
+   cmd-starttls = "STARTTLS"
+
+   cmd-update = "UPDATE"
+
+   command = tag SP command-type CRLF
+
+   command-type = cmd-activate / cmd-authenticate / cmd-delete /
+                  cmd-find / cmd-list / cmd-logout / cmd-noop /
+                  cmd-reserve / cmd-starttls / cmd-update
+
+   response = tag SP response-type CRLF
+
+   response-type = rsp-ok / rsp-no / rsp-bad / rsp-bye / rsp-mailbox /
+                   rsp-reserve / rsp-delete
+
+   rsp-bad = "BAD" SP string
+
+   rsp-bye = "BYE" SP string
+
+   rsp-mailbox = "MAILBOX" SP string SP string SP string
+
+   rsp-no = "NO" SP string
+
+   rsp-ok = "OK" SP string
+
+   rsp-reserve = "RESERVE" SP string SP string
+
+   rsp-delete = "DELETE" SP string
+
+   sasl-mech = 1*ATOM-CHAR
+      ; ATOM-CHAR is defined in [ACAP]
+
+   string = quoted / literal
+      ; quoted and literal are defined in [ACAP]
+
+
+
+
+
+Siemborski                    Experimental                     [Page 13]
+
+RFC 3656     MUPDATE Distributed Mailbox Database Protocol December 2003
+
+
+   tag = 1*ATOM-CHAR
+      ; ATOM-CHAR is defined in [ACAP]
+
+6.  MUPDATE URL Scheme
+
+   This document defines the a URL scheme for the purposes of
+   referencing MUPDATE resources, according to the requirements in
+   [RFC2717].  This includes both MUPDATE servers as a whole, along with
+   individual mailbox entries on a given MUPDATE server.
+
+   There is no MIME type associated with these resources.  It is
+   intended that a URL consumer would either retrieve the MUPDATE record
+   in question, or simply connect to the MUPDATE server running on the
+   specified host.  Note that the consumer will need to have
+   authentication credentials for the specified host.
+
+   The MUPDATE URL scheme is similar to the IMAP URL scheme [IMAP-URL].
+   However, it only takes one of two possible forms:
+
+      mupdate://<iserver>/
+      mupdate://<iserver>/<mailbox>
+
+   The first form refers to a MUPDATE server as a whole, the second form
+   indicates both the server and a mailbox to run a FIND against once
+   authenticated to the server.  Note that part of <iserver> may include
+   username and authentication information along with a hostname and
+   port.
+
+6.1.  MUPDATE URL Scheme Registration Form
+
+   URL scheme name: "mupdate"
+
+   URL scheme syntax:
+
+      This defines the MUPDATE URL Scheme in [ABNF].  Terminals from the
+      BNF of IMAP URLs [IMAP-URL] are also used.
+
+         mupdateurl = "mupdate://" iserver "/" [ enc_mailbox ]
+            ; iserver and enc_mailbox are as defined in [IMAP-URL]
+
+   Character encoding considerations:
+
+      Identical to those described in [IMAP-URL] for the appropriate
+      terminals.
+
+
+
+
+
+
+
+Siemborski                    Experimental                     [Page 14]
+
+RFC 3656     MUPDATE Distributed Mailbox Database Protocol December 2003
+
+
+   Intended Usage:
+
+      The form of the URL without an associated mailbox is intended to
+      designate a MUPDATE server only.  If a mailbox name is included in
+      the URL, then the consumer is expected to execute a FIND command
+      for that mailbox on the specified server.
+
+   Applications and/or protocols which use this URL scheme name:
+
+      The protocol described in this document.
+
+   Interoperability Considerations:
+
+      None.
+
+   Security Considerations:
+
+      Users of the MUPDATE URL Scheme should review the security
+      considerations that are discussed in [IMAP-URL].  In particular,
+      the consequences of including authentication mechanism information
+      in a URL should be reviewed.
+
+   Relevant Publications:
+
+      This document and [IMAP-URL].
+
+   Author, Change Controller, and Contact for Further Information:
+
+      Author of this document.
+
+7.  Security Considerations
+
+   While no unauthenticated users may make modifications or even perform
+   searches on the database, it is important to note that this
+   specification assumes no protections of any type for authenticated
+   users.
+
+   All authenticated users have complete access to the database.  For
+   this reason it is important to ensure that accounts that are making
+   use of the database are well secured.
+
+   A more secure deployment might have all read only access go through a
+   slave, and only have accounts which need write access use the master.
+   This has the disadvantage of a marginally longer time for updates to
+   reach the clients.
+
+
+
+
+
+
+Siemborski                    Experimental                     [Page 15]
+
+RFC 3656     MUPDATE Distributed Mailbox Database Protocol December 2003
+
+
+   The protocol assumes that all authenticated users are cooperating to
+   maintain atomic operations.  Therefore, all new mailboxes SHOULD be
+   RESERVEd before they are ACTIVATEd, despite the fact that the
+   protocol does not require this, and it is therefore possible for a
+   set of participants which do not obey the provided locking to create
+   an inconsistent database.  RESERVEing the mailbox first is not
+   required to perform an activate because this behavior simplifies
+   synchronization with the actual location of the mailboxes.
+
+8.  IANA Considerations
+
+   The IANA has assigned TCP port number 3905 to "mupdate".
+
+   The IANA has registered a URL scheme for the MUPDATE protocol, as
+   defined in section 6.1 of this document.
+
+   IANA has registered a GSSAPI service name of "mupdate" for the
+   MUPDATE protocol in the registry maintained at:
+
+   http://www.iana.org/assignments/gssapi-service-names
+
+9.  Intellectual Property Rights
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+
+
+
+
+Siemborski                    Experimental                     [Page 16]
+
+RFC 3656     MUPDATE Distributed Mailbox Database Protocol December 2003
+
+
+10.  References
+
+10.1.  Normative References
+
+   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [IMAP]      Crispin, M., "Internet Message Access Protocol - Version
+               4", RFC 3501, March 2003.
+
+   [ABNF]      Crocker, D., Ed. and P. Overell, "Augmented BNF for
+               Syntax Specifications: ABNF", RFC 2234, November 1997.
+
+   [MIME]      Freed, N. and N. Bornstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [IMAP-ACL]  Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
+
+   [SASL]      Myers, J., "Simple Authentication and Security Layer
+               (SASL)", RFC 2222, October 1997.
+
+   [IMAP-URL]  Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
+
+   [ACAP]      Newman, C. and J. Myers, "ACAP -- Application
+               Configuration Access Protocol", RFC 2244, November 1997.
+
+   [TLS]       Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+               RFC 2246, January 1999.
+
+10.2.  Informative References
+
+   [POP3]      Myers, J. and M. Rose, "Post Office Protocol - Version
+               3", STD 53, RFC 1939, May 1996.
+
+   [RFC2717]   Petke, R. and I. King, "Registration Procedures for URL
+               Scheme Names", BCP 35, RFC 2717, November 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Siemborski                    Experimental                     [Page 17]
+
+RFC 3656     MUPDATE Distributed Mailbox Database Protocol December 2003
+
+
+11.  Acknowledgments
+
+   Lawrence Greenfield and Ken Murchison, for a great deal of input on
+   both the protocol and the text of the documents.
+
+12.  Author's  Address
+
+   Robert Siemborski
+   Carnegie Mellon, Andrew Systems Group
+   Cyert Hall 207
+   5000 Forbes Avenue
+   Pittsburgh, PA  15213
+
+   Phone: (412) 268-7456
+   EMail: rjs3+@andrew.cmu.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Siemborski                    Experimental                     [Page 18]
+
+RFC 3656     MUPDATE Distributed Mailbox Database Protocol December 2003
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Siemborski                    Experimental                     [Page 19]
+
diff --git a/docs/rfcs/rfc3691.txt b/docs/rfcs/rfc3691.txt
new file mode 100644
index 0000000..2f4e9b4
--- /dev/null
+++ b/docs/rfcs/rfc3691.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                        A. Melnikov
+Request for Comments: 3691                                    Isode Ltd.
+Category: Standards Track                                  February 2004
+
+
+        Internet Message Access Protocol (IMAP) UNSELECT command
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document defines an UNSELECT command that can be used to close
+   the current mailbox in an Internet Message Access Protocol - version
+   4 (IMAP4) session without expunging it.  Certain types of IMAP
+   clients need to release resources associated with the selected
+   mailbox without selecting a different mailbox.  While IMAP4 provides
+   this functionality (via a SELECT command with a nonexistent mailbox
+   name or reselecting the same mailbox with EXAMINE command), a more
+   clean solution is desirable.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  UNSELECT command . . . . . . . . . . . . . . . . . . . . . . .  2
+   3.  Security Considerations. . . . . . . . . . . . . . . . . . . .  3
+   4.  Formal Syntax. . . . . . . . . . . . . . . . . . . . . . . . .  3
+   5.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  3
+   6.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .  3
+   7.  Normative References . . . . . . . . . . . . . . . . . . . . .  4
+   8.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .  4
+   9.  Full Copyright Statement . . . . . . . . . . . . . . . . . . .  5
+
+
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                     [Page 1]
+
+RFC 3691                 IMAP UNSELECT command             February 2004
+
+
+1.  Introduction
+
+   Certain types of IMAP clients need to release resources associated
+   with the selected mailbox without selecting a different mailbox.
+   While [IMAP4] provides this functionality (via a SELECT command with
+   a nonexistent mailbox name or reselecting the same mailbox with
+   EXAMINE command), a more clean solution is desirable.
+
+   [IMAP4] defines the CLOSE command that closes the selected mailbox as
+   well as permanently removes all messages with the \Deleted flag set.
+
+   However [IMAP4] lacks a command that simply closes the mailbox
+   without expunging it.  This document defines the UNSELECT command for
+   this purpose.
+
+   A server which supports this extension indicates this with a
+   capability name of "UNSELECT".
+
+   "C:" and "S:" in examples show lines sent by the client and server
+   respectively.
+
+   The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
+   this document when typed in uppercase are to be interpreted as
+   defined in "Key words for use in RFCs to Indicate Requirement Levels"
+   [KEYWORDS].
+
+2.  UNSELECT Command
+
+   Arguments:  none
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - unselect completed, now in authenticated state
+               BAD - no mailbox selected, or argument supplied but
+                     none permitted
+
+      The UNSELECT command frees server's resources associated with the
+      selected mailbox and returns the server to the authenticated
+      state.  This command performs the same actions as CLOSE, except
+      that no messages are permanently removed from the currently
+      selected mailbox.
+
+   Example:    C: A341 UNSELECT
+               S: A341 OK Unselect completed
+
+
+
+
+
+
+
+Melnikov                    Standards Track                     [Page 2]
+
+RFC 3691                 IMAP UNSELECT command             February 2004
+
+
+3.  Security Considerations
+
+   It is believed that this extension doesn't raise any additional
+   security concerns not already discussed in [IMAP4].
+
+4.  Formal Syntax
+
+   The following syntax specification uses the Augmented Backus-Naur
+   Form (ABNF) notation as specified in [ABNF].  Non-terminals
+   referenced but not defined below are as defined by [IMAP4].
+
+   Except as noted otherwise, all alphabetic characters are case-
+   insensitive.  The use of upper or lower case characters to define
+   token strings is for editorial clarity only.  Implementations MUST
+   accept these strings in a case-insensitive fashion.
+
+   command-select  /= "UNSELECT"
+
+5.  IANA Considerations
+
+   IMAP4 capabilities are registered by publishing a standards track or
+   IESG approved experimental RFC.  The registry is currently located
+   at:
+
+      http://www.iana.org/assignments/imap4-capabilities
+
+   This document defines the UNSELECT IMAP capabilities.  IANA has added
+   this capability to the registry.
+
+6.  Acknowledgments
+
+   UNSELECT command was originally implemented by Tim Showalter in Cyrus
+   IMAP server.
+
+   Also, the author of the document would like to thank Vladimir Butenko
+   and Mark Crispin for reminding that UNSELECT has to be documented.
+   Also thanks to Simon Josefsson for pointing out that there are
+   multiple ways to implement UNSELECT.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                     [Page 3]
+
+RFC 3691                 IMAP UNSELECT command             February 2004
+
+
+7.  Normative References
+
+   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [IMAP4]    Crispin, M., "Internet Message Access Protocol - Version
+              4rev1", RFC 3501, March 2003.
+
+   [ABNF]     Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 2234, November 1997.
+
+8.  Author's Address
+
+   Alexey Melnikov
+   Isode Limited
+   5 Castle Business Village
+   Hampton, Middlesex TW12 2BX
+
+   EMail: Alexey.Melnikov@isode.com
+   URI: http://www.melnikov.ca/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                     [Page 4]
+
+RFC 3691                 IMAP UNSELECT command             February 2004
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78 and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed
+   to pertain to the implementation or use of the technology
+   described in this document or the extent to which any license
+   under such rights might or might not be available; nor does it
+   represent that it has made any independent effort to identify any
+   such rights.  Information on the procedures with respect to
+   rights in RFC documents can be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use
+   of such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository
+   at http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention
+   any copyrights, patents or patent applications, or other
+   proprietary rights that may cover technology that may be required
+   to implement this standard.  Please address the information to the
+   IETF at ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                     [Page 5]
+
diff --git a/docs/rfcs/rfc4314.txt b/docs/rfcs/rfc4314.txt
new file mode 100644
index 0000000..e73a56f
--- /dev/null
+++ b/docs/rfcs/rfc4314.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group                                        A. Melnikov
+Request for Comments: 4314                                    Isode Ltd.
+Obsoletes: 2086                                            December 2005
+Category: Standards Track
+
+
+               IMAP4 Access Control List (ACL) Extension
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   The Access Control List (ACL) extension (RFC 2086) of the Internet
+   Message Access Protocol (IMAP) permits mailbox access control lists
+   to be retrieved and manipulated through the IMAP protocol.
+
+   This document is a revision of RFC 2086.  It defines several new
+   access control rights and clarifies which rights are required for
+   different IMAP commands.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                     [Page 1]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+Table of Contents
+
+   1. Introduction and Overview .......................................3
+      1.1. Conventions Used in This Document ..........................3
+   2. Access Control ..................................................3
+      2.1. Standard Rights ............................................5
+           2.1.1. Obsolete Rights .....................................5
+      2.2. Rights Defined in RFC 2086 .................................8
+   3. Access control management commands and responses ................8
+      3.1. SETACL Command .............................................8
+      3.2. DELETEACL Command ..........................................9
+      3.3. GETACL Command ............................................10
+      3.4. LISTRIGHTS Command ........................................10
+      3.5. MYRIGHTS Command ..........................................11
+      3.6. ACL Response ..............................................11
+      3.7. LISTRIGHTS Response .......................................12
+      3.8. MYRIGHTS Response .........................................12
+   4. Rights Required to Perform Different IMAP4rev1 Commands ........12
+   5. Other Considerations ...........................................17
+      5.1. Additional Requirements and Implementation Notes ..........17
+           5.1.1. Servers ............................................17
+           5.1.2. Clients ............................................18
+      5.2. Mapping of ACL Rights to READ-WRITE and READ-ONLY
+           Response Codes ............................................19
+   6. Security Considerations ........................................20
+   7. Formal Syntax ..................................................21
+   8. IANA Considerations ............................................22
+   9. Internationalization Considerations ............................22
+   Appendix A. Changes since RFC 2086 ................................23
+   Appendix B. Compatibility with RFC 2086 ...........................24
+   Appendix C. Known Deficiencies ....................................24
+   Appendix D. Acknowledgements ......................................25
+   Normative References ..............................................25
+   Informative References ............................................25
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                     [Page 2]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+1.  Introduction and Overview
+
+   The ACL (Access Control List) extension of the Internet Message
+   Access Protocol [IMAP4] permits mailbox access control lists to be
+   retrieved and manipulated through the IMAP protocol.
+
+   This document is a revision of RFC 2086 [RFC2086].  It tries to
+   clarify different ambiguities in RFC 2086, in particular, the use of
+   UTF-8 [UTF-8] in access identifiers, which rights are required for
+   different IMAP4 commands, and how READ-WRITE/READ-ONLY response codes
+   are related to ACL.
+
+1.1.  Conventions Used in This Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+   In all examples "/" character is used as hierarchy separator.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [KEYWORDS].
+
+   The phrase "ACL server" is just a shortcut for saying "IMAP server
+   that supports ACL extension as defined in this document".
+
+2.  Access Control
+
+   The ACL extension is present in any IMAP4 implementation that returns
+   "ACL" as one of the supported capabilities to the CAPABILITY command.
+
+   A server implementation conformant to this document MUST also return
+   rights (see below) not defined in Section 2.2 in the "RIGHTS="
+   capability.
+
+   An access control list is a set of <access identifier,rights> pairs.
+   An ACL applies to a mailbox name.
+
+   Access identifier (or just "identifier") is a UTF-8 [UTF-8] string.
+   The identifier "anyone" is reserved to refer to the universal
+   identity (all authentications, including anonymous).  All user name
+   strings accepted by the LOGIN or AUTHENTICATE commands to
+   authenticate to the IMAP server are reserved as identifiers for the
+   corresponding users.  Identifiers starting with a dash ("-") are
+   reserved for "negative rights", described below.  All other
+   identifier strings are interpreted in an implementation-defined
+   manner.
+
+
+
+
+Melnikov                    Standards Track                     [Page 3]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   Rights is a string listing a (possibly empty) set of alphanumeric
+   characters, each character listing a set of operations that is being
+   controlled.  Lowercase letters are reserved for "standard" rights,
+   listed in Section 2.1.  (Note that for compatibility with deployed
+   clients and servers uppercase rights are not allowed.)  The set of
+   standard rights can only be extended by a standards-track document.
+   Digits are reserved for implementation- or site-defined rights.
+
+   An implementation MAY tie rights together or MAY force rights to
+   always or never be granted to particular identifiers.  For example,
+   in an implementation that uses UNIX mode bits, the rights "swite" are
+   tied, the "a" right is always granted to the owner of a mailbox and
+   is never granted to another user.  If rights are tied in an
+   implementation, the implementation must be conservative in granting
+   rights in response to SETACL commands--unless all rights in a tied
+   set are specified, none of that set should be included in the ACL
+   entry for that identifier.  A client can discover the set of rights
+   that may be granted to a given identifier in the ACL for a given
+   mailbox name by using the LISTRIGHTS command.
+
+   It is possible for multiple identifiers in an access control list to
+   apply to a given user.  For example, an ACL may include rights to be
+   granted to the identifier matching the user, one or more
+   implementation-defined identifiers matching groups that include the
+   user, and/or the identifier "anyone".  How these rights are combined
+   to determine the user's access is implementation defined.  An
+   implementation may choose, for example, to use the union of the
+   rights granted to the applicable identifiers.  An implementation may
+   instead choose, for example, to use only those rights granted to the
+   most specific identifier present in the ACL.  A client can determine
+   the set of rights granted to the logged-in user for a given mailbox
+   name by using the MYRIGHTS command.
+
+   When an identifier in an ACL starts with a dash ("-"), that indicates
+   that associated rights are to be removed from the identifier prefixed
+   by the dash.  This is referred to as a "negative right".  This
+   differs from DELETEACL in that a negative right is added to the ACL
+   and is a part of the calculation of the rights.
+
+   Let's assume that an identifier "fred" refers to a user with login
+   "fred".  If the identifier "-fred" is granted the "w" right, that
+   indicates that the "w" right is to be removed from users matching the
+   identifier "fred", even though the user "fred" might have the "w"
+   right as a consequence of some other identifier in the ACL.  A
+   DELETEACL of "fred" simply deletes the identifier "fred" from the
+   ACL; it does not affect any rights that the user "fred" may get from
+   another entry in the ACL, in particular it doesn't affect rights
+   granted to the identifier "-fred".
+
+
+
+Melnikov                    Standards Track                     [Page 4]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   Server implementations are not required to support "negative right"
+   identifiers.
+
+2.1.  Standard Rights
+
+   The currently defined standard rights are (note that the list below
+   doesn't list all commands that use a particular right):
+
+   l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE
+       mailbox)
+   r - read (SELECT the mailbox, perform STATUS)
+   s - keep seen/unseen information across sessions (set or clear
+       \SEEN flag via STORE, also set \SEEN during APPEND/COPY/
+       FETCH BODY[...])
+   w - write (set or clear flags other than \SEEN and \DELETED via
+       STORE, also set them during APPEND/COPY)
+   i - insert (perform APPEND, COPY into mailbox)
+   p - post (send mail to submission address for mailbox,
+       not enforced by IMAP4 itself)
+   k - create mailboxes (CREATE new sub-mailboxes in any
+       implementation-defined hierarchy, parent mailbox for the new
+       mailbox name in RENAME)
+   x - delete mailbox (DELETE mailbox, old mailbox name in RENAME)
+   t - delete messages (set or clear \DELETED flag via STORE, set
+       \DELETED flag during APPEND/COPY)
+   e - perform EXPUNGE and expunge as a part of CLOSE
+   a - administer (perform SETACL/DELETEACL/GETACL/LISTRIGHTS)
+
+2.1.1.  Obsolete Rights
+
+   Due to ambiguity in RFC 2086, some existing RFC 2086 server
+   implementations use the "c" right to control the DELETE command.
+   Others chose to use the "d" right to control the DELETE command.  For
+   the former group, let's define the "create" right as union of the "k"
+   and "x" rights, and the "delete" right as union of the "e" and "t"
+   rights.  For the latter group, let's define the "create" rights as a
+   synonym to the "k" right, and the "delete" right as union of the "e",
+   "t", and "x" rights.
+
+   For compatibility with RFC 2086, this section defines two virtual
+   rights "d" and "c".
+
+   If a client includes the "d" right in a rights list, then it MUST be
+   treated as if the client had included every member of the "delete"
+   right.  (It is not an error for a client to specify both the "d"
+   right and one or more members of the "delete" right, but the effect
+   is no different than if just the "d" right or all members of the
+   "delete" right had been specified.)
+
+
+
+Melnikov                    Standards Track                     [Page 5]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   When any of the "delete" member rights is set in a list of rights,
+   the server MUST also include the "d" right when returning the list in
+   a MYRIGHTS or ACL response.  This is to enable older clients
+   conforming to RFC 2086 to work with newer servers. (*)
+
+   Example:    C: A001 SeTacl INBOX/Drafts David lrswida
+               S: A001 OK Setacl complete
+
+   The client has specified the "d" right in the SETACL command above
+   and it expands to "et" on the server:
+
+               C: A002 getacl INBOX/Drafts
+               S: * ACL INBOX Fred rwipslxcetda David lrswideta
+               S: A002 OK Getacl complete
+
+   If the identifier specified in the LISTRIGHTS command can be granted
+   any of the "delete" member rights on a mailbox, then the server MUST
+   include the "d" right in the corresponding LISTRIGHTS response. (*)
+   If the member rights aren't tied to non-member rights, then the "d"
+   right is returned by itself in the LISTRIGHTS response.  If any of
+   the member rights needs to be tied to one (or more) non-member right,
+   then the "d" right and all of the member rights need to be tied to
+   the same non-member right(s) (**).
+
+   If a client includes the "c" right in a rights list, then it MUST be
+   treated as if the client had included every member of the "create"
+   right.  (It is not an error for a client to specify both the "c"
+   right and one or more members of the "create" right, but the effect
+   is no different than if just the "c" right or all members of the
+   "create" right had been specified.)
+
+   When any of the "create" member rights is set in a list of rights,
+   the server MUST also include the "c" right when returning the list in
+   a MYRIGHTS or ACL response.  This is to enable older clients
+   conforming to RFC 2086 to work with newer servers. (*)
+
+   Example:    C: A003 Setacl INBOX/Drafts Byron lrswikda
+               S: A001 OK Setacl complete
+               C: A002 getAcl INBOX/Drafts
+               S: * ACL INBOX Fred rwipslxcetda Byron lrswikcdeta
+               S: A002 OK Getacl complete
+
+   The client has specified the "d" right in the SETACL command above
+   and it expands to "et" on the server: As the client has specified the
+   "k" right (which is a member of the "c" right), the server also
+   returns the "c" right.
+
+
+
+
+
+Melnikov                    Standards Track                     [Page 6]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   If the identifier specified in the LISTRIGHTS command can be granted
+   any of the "create" member rights on a mailbox, then the server MUST
+   include the "c" right in the corresponding LISTRIGHTS response. (*)
+   If the member rights aren't tied to non-member rights, then the "c"
+   right is returned by itself in the LISTRIGHTS response.  If any of
+   the member rights needs to be tied to one (or more) non-member right,
+   then the "c" right and all of the member rights need to be tied to
+   the same non-member right(s) (**).
+
+   Example: The server that ties the rights as follows:
+
+               lr s w i p k x t
+
+            and c=k
+
+            will return:
+
+               S: * LISTRIGHTS archive/imap anyone ""
+                  lr s w i p k x t c d
+
+   Example: The server that ties the rights as follows:
+
+               lr s w i p k xte
+
+            and c=k
+
+            will return:
+
+               S: * LISTRIGHTS archive/imap anyone ""
+                  lr s w i p k xte c d
+
+   Example: The server that ties the rights as follows:
+
+               lr s w i p k x te
+
+            and c=k
+
+            will return:
+
+               S: * LISTRIGHTS archive/imap anyone ""
+                  lr s w i p k c x te d
+
+   Example: The server that ties the rights as follows:
+
+               lr swte i p k x
+
+            and c=kx
+
+
+
+
+Melnikov                    Standards Track                     [Page 7]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+            will return:
+
+               S: * LISTRIGHTS archive/imap anyone ""
+                  lr swted i p k x c
+
+   (*)  Clients conforming to this document MUST ignore the virtual "d"
+        and "c" rights in MYRIGHTS, ACL, and LISTRIGHTS responses.
+
+   (**) The IMAPEXT Working Group has debated this issue in great length
+        and after reviewing existing ACL implementations concluded that
+        this is a reasonable restriction.
+
+2.2.  Rights Defined in RFC 2086
+
+   The "RIGHTS=" capability MUST NOT include any of the rights defined
+   in RFC 2086: "l", "r", "s", "w", "i", "p", "a", "c", "d", and the
+   digits ("0" .. "9").
+
+3.  Access control management commands and responses
+
+   Servers, when processing a command that has an identifier as a
+   parameter (i.e., any of SETACL, DELETEACL, and LISTRIGHTS commands),
+   SHOULD first prepare the received identifier using "SASLprep" profile
+   [SASLprep] of the "stringprep" algorithm [Stringprep].  If the
+   preparation of the identifier fails or results in an empty string,
+   the server MUST refuse to perform the command with a BAD response.
+   Note that Section 6 recommends additional identifier's verification
+   steps.
+
+3.1.  SETACL Command
+
+   Arguments:  mailbox name
+               identifier
+               access right modification
+
+   Data:       no specific data for this command
+
+   Result:     OK - setacl completed
+               NO - setacl failure: can't set acl
+               BAD - arguments invalid
+
+   The SETACL command changes the access control list on the specified
+   mailbox so that the specified identifier is granted permissions as
+   specified in the third argument.
+
+   The third argument is a string containing an optional plus ("+") or
+   minus ("-") prefix, followed by zero or more rights characters.  If
+   the string starts with a plus, the following rights are added to any
+
+
+
+Melnikov                    Standards Track                     [Page 8]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   existing rights for the identifier.  If the string starts with a
+   minus, the following rights are removed from any existing rights for
+   the identifier.  If the string does not start with a plus or minus,
+   the rights replace any existing rights for the identifier.
+
+   Note that an unrecognized right MUST cause the command to return the
+   BAD response.  In particular, the server MUST NOT silently ignore
+   unrecognized rights.
+
+   Example:    C: A001 GETACL INBOX/Drafts
+               S: * ACL INBOX/Drafts Fred rwipslxetad Chris lrswi
+               S: A001 OK Getacl complete
+               C: A002 SETACL INBOX/Drafts Chris +cda
+               S: A002 OK Setacl complete
+               C: A003 GETACL INBOX/Drafts
+               S: * ACL INBOX/Drafts Fred rwipslxetad Chris lrswicdakxet
+               S: A003 OK Getacl complete
+
+
+               C: A035 SETACL INBOX/Drafts John lrQswicda
+               S: A035 BAD Uppercase rights are not allowed
+
+
+               C: A036 SETACL INBOX/Drafts John lrqswicda
+               S: A036 BAD The q right is not supported
+
+3.2.  DELETEACL Command
+
+   Arguments:  mailbox name
+               identifier
+
+   Data:       no specific data for this command
+
+   Result:     OK - deleteacl completed
+               NO - deleteacl failure: can't delete acl
+              BAD - arguments invalid
+
+   The DELETEACL command removes any <identifier,rights> pair for the
+   specified identifier from the access control list for the specified
+   mailbox.
+
+   Example:    C: B001 getacl INBOX
+               S: * ACL INBOX Fred rwipslxetad -Fred wetd $team w
+               S: B001 OK Getacl complete
+               C: B002 DeleteAcl INBOX Fred
+               S: B002 OK Deleteacl complete
+
+
+
+
+
+Melnikov                    Standards Track                     [Page 9]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+               C: B003 GETACL INBOX
+               S: * ACL INBOX -Fred wetd $team w
+               S: B003 OK Getacl complete
+
+3.3.  GETACL Command
+
+   Arguments:  mailbox name
+
+   Data:       untagged responses: ACL
+
+   Result:     OK - getacl completed
+               NO - getacl failure: can't get acl
+              BAD - arguments invalid
+
+   The GETACL command returns the access control list for mailbox in an
+   untagged ACL response.
+
+   Some implementations MAY permit multiple forms of an identifier to
+   reference the same IMAP account.  Usually, such implementations will
+   have a canonical form that is stored internally.  An ACL response
+   caused by a GETACL command MAY include a canonicalized form of the
+   identifier that might be different from the one used in the
+   corresponding SETACL command.
+
+   Example:    C: A002 GETACL INBOX
+               S: * ACL INBOX Fred rwipsldexta
+               S: A002 OK Getacl complete
+
+3.4.  LISTRIGHTS Command
+
+   Arguments:  mailbox name
+               identifier
+
+   Data:       untagged responses: LISTRIGHTS
+
+   Result:     OK - listrights completed
+               NO - listrights failure: can't get rights list
+               BAD - arguments invalid
+
+   The LISTRIGHTS command takes a mailbox name and an identifier and
+   returns information about what rights can be granted to the
+   identifier in the ACL for the mailbox.
+
+   Some implementations MAY permit multiple forms of an identifier to
+   reference the same IMAP account.  Usually, such implementations will
+   have a canonical form that is stored internally.  A LISTRIGHTS
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 10]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   response caused by a LISTRIGHTS command MUST always return the same
+   form of an identifier as specified by the client.  This is to allow
+   the client to correlate the response with the command.
+
+   Example:    C: a001 LISTRIGHTS ~/Mail/saved smith
+               S: * LISTRIGHTS ~/Mail/saved smith la r swicdkxte
+               S: a001 OK Listrights completed
+
+   Example:    C: a005 listrights archive/imap anyone
+               S: * LISTRIGHTS archive.imap anyone ""
+                  l r s w i p k x t e c d a 0 1 2 3 4 5 6 7 8 9
+               S: a005 Listrights successful
+
+3.5.  MYRIGHTS Command
+
+   Arguments:  mailbox name
+
+   Data:       untagged responses: MYRIGHTS
+
+   Result:     OK - myrights completed
+               NO - myrights failure: can't get rights
+               BAD - arguments invalid
+
+   The MYRIGHTS command returns the set of rights that the user has to
+   mailbox in an untagged MYRIGHTS reply.
+
+   Example:    C: A003 MYRIGHTS INBOX
+               S: * MYRIGHTS INBOX rwiptsldaex
+               S: A003 OK Myrights complete
+
+3.6.  ACL Response
+
+   Data:       mailbox name
+               zero or more identifier rights pairs
+
+   The ACL response occurs as a result of a GETACL command.  The first
+   string is the mailbox name for which this ACL applies.  This is
+   followed by zero or more pairs of strings; each pair contains the
+   identifier for which the entry applies followed by the set of rights
+   that the identifier has.
+
+   Section 2.1.1 details additional server requirements related to
+   handling of the virtual "d" and "c" rights.
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 11]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+3.7.  LISTRIGHTS Response
+
+   Data:       mailbox name
+               identifier
+               required rights
+               list of optional rights
+
+   The LISTRIGHTS response occurs as a result of a LISTRIGHTS command.
+   The first two strings are the mailbox name and identifier for which
+   this rights list applies.  Following the identifier is a string
+   containing the (possibly empty) set of rights the identifier will
+   always be granted in the mailbox.
+
+   Following this are zero or more strings each containing a set of
+   rights the identifier can be granted in the mailbox.  Rights
+   mentioned in the same string are tied together.  The server MUST
+   either grant all tied rights to the identifier in the mailbox or
+   grant none.  Section 2.1.1 details additional server requirements
+   related to handling of the virtual "d" and "c" rights.
+
+   The same right MUST NOT be listed more than once in the LISTRIGHTS
+   command.
+
+3.8.  MYRIGHTS Response
+
+   Data:       mailbox name
+               rights
+
+   The MYRIGHTS response occurs as a result of a MYRIGHTS command.  The
+   first string is the mailbox name for which these rights apply.  The
+   second string is the set of rights that the client has.
+
+   Section 2.1.1 details additional server requirements related to
+   handling of the virtual "d" and "c" rights.
+
+4.  Rights Required to Perform Different IMAP4rev1 Commands
+
+   Before executing a command, an ACL-compliant server MUST check which
+   rights are required to perform it.  This section groups command by
+   functions they perform and list the rights required.  It also gives
+   the detailed description of any special processing required.
+
+   For the purpose of this section the UID counterpart of a command is
+   considered to be the same command, e.g., both UID COPY and COPY
+   commands require the same set of rights.
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 12]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   The table below summarizes different rights or their combinations
+   that are required in order to perform different IMAP operations.  As
+   it is not always possible to express complex right checking and
+   interactions, the description after the table should be used as the
+   primary reference.
+
+   +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+
+   |Operations\Rights  | l | r | s | w | i | k | x | t | e | a |Any|Non|
+   +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+
+   |                  commands in authenticated state                  |
+   +-------------------------------------------------------------------+
+   |      LIST         | + |   |   |   |   |   |   |   |   |   |   |   |
+   |   SUBSCRIBE       | * |   |   |   |   |   |   |   |   |   |   | * |
+   |  UNSUBSCRIBE      |   |   |   |   |   |   |   |   |   |   |   | + |
+   |      LSUB         | * |   |   |   |   |   |   |   |   |   |   | * |
+   |CREATE (for parent)|   |   |   |   |   | + |   |   |   |   |   |   |
+   |     DELETE        |   | ? |   |   |   |   | + | ? | ? |   |   |   |
+   |     RENAME        |   |   |   |   |   | + | + |   |   |   |   |   |
+   |  SELECT/EXAMINE   |   | + |   |   |   |   |   |   |   |   |   |   |
+   |      STATUS       |   | + |   |   |   |   |   |   |   |   |   |   |
+   |  SETACL/DELETEACL |   |   |   |   |   |   |   |   |   | + |   |   |
+   | GETACL/LISTRIGHTS |   |   |   |   |   |   |   |   |   | + |   |   |
+   |     MYRIGHTS      |   |   |   |   |   |   |   |   |   |   | + |   |
+   |      APPEND       |   |   | ? | ? | + |   |   | ? |   |   |   |   |
+   +-------------------------------------------------------------------+
+   |                     commands in selected state                    |
+   +-------------------------------------------------------------------+
+   |       COPY        |   |   | ? | ? | + |   |   | ? |   |   |   |   |
+   |     EXPUNGE       |   |   |   |   |   |   |   |   | + |   |   |   |
+   |      CLOSE        |   |   |   |   |   |   |   |   | ? |   |   |   |
+   |      FETCH        |   |   | ? |   |   |   |   |   |   |   |   |   |
+   |   STORE flags     |   |   | ? | ? |   |   |   | ? |   |   |   |   |
+   +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+
+
+   Note: for all commands in the selected state, the "r" is implied,
+   because it is required to SELECT/EXAMINE a mailbox.  Servers are not
+   required to check presence of the "r" right once a mailbox is
+   successfully selected.
+
+   Legend:
+    +     - The right is required
+    *     - Only one of the rights marked with * is required
+            (see description below)
+    ?     - The right is OPTIONAL (see description below)
+    "Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is
+            required
+    "Non" - No rights required to perform the command
+
+
+
+
+Melnikov                    Standards Track                    [Page 13]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   Listing and subscribing/unsubscribing mailboxes:
+      LIST - "l" right is required.  However, unlike other commands
+      (e.g., SELECT) the server MUST NOT return a NO response if it
+      can't list a mailbox.
+      Note that if the user has "l" right to a mailbox "A/B", but not to
+      its parent mailbox "A", the LIST command should behave as if the
+      mailbox "A" doesn't exist, for example:
+
+               C: A777 LIST "" *
+               S: * LIST (\NoInferiors) "/" "A/B"
+               S: * LIST () "/" "C"
+               S: * LIST (\NoInferiors) "/" "C/D"
+               S: A777 OK LIST completed
+
+
+      SUBSCRIBE - "l" right is required only if the server checks for
+      mailbox existence when performing SUBSCRIBE.
+
+      UNSUBSCRIBE - no rights required to perform this operation.
+
+      LSUB - "l" right is required only if the server checks for mailbox
+      existence when performing SUBSCRIBE.  However, unlike other
+      commands (e.g., SELECT) the server MUST NOT return a NO response
+      if it can't list a subscribed mailbox.
+
+   Mailbox management:
+      CREATE - "k" right on a nearest existing parent mailbox.  When a
+      new mailbox is created, it SHOULD inherit the ACL from the parent
+      mailbox (if one exists) in the defined hierarchy.
+
+      DELETE - "x" right on the mailbox.  Note that some servers don't
+      allow to delete a non-empty mailbox.  If this is the case, the
+      user would also need "r", "e", and "t" rights, in order to open
+      the mailbox and empty it.
+
+      The DELETE command MUST delete the ACL associated with the deleted
+      mailbox.
+
+      RENAME - Moving a mailbox from one parent to another requires the
+      "x" right on the mailbox itself and the "k" right for the new
+      parent.  For example, if the user wants to rename the mailbox
+      named "A/B/C" to "D/E", the user must have the "x" right for the
+      mailbox "A/B/C" and the "k" right for the mailbox "D".
+      The RENAME command SHOULD NOT change the ACLs on the renamed
+      mailbox and submailboxes.
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 14]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   Copying or appending messages:
+      Before performing a COPY/APPEND command, the server MUST check if
+      the user has "i" right for the target mailbox.  If the user
+      doesn't have "i" right, the operation fails.  Otherwise for each
+      copied/appended message the server MUST check if the user has
+         "t" right - when the message has \Deleted flag set
+         "s" right - when the message has \Seen flag set
+         "w" right - for all other message flags.
+      Only when the user has a particular right are the corresponding
+      flags stored for the newly created message.  The server MUST NOT
+      fail a COPY/APPEND if the user has no rights to set a particular
+      flag.
+
+   Example:    C: A003 MYRIGHTS TargetMailbox
+               S: * MYRIGHTS TargetMailbox rwis
+               S: A003 OK Myrights complete
+
+               C: A004 FETCH 1:3 (FLAGS)
+               S: * 1 FETCH (FLAGS (\Draft \Deleted)
+               S: * 2 FETCH (FLAGS (\Answered)
+               S: * 3 FETCH (FLAGS ($Forwarded \Seen)
+               S: A004 OK Fetch Completed
+
+               C: A005 COPY 1:3 TargetMailbox
+               S: A005 OK Copy completed
+
+               C: A006 SELECT TargetMailbox
+                  ...
+               S: A006 Select Completed
+
+      Let's assume that the copied messages received message numbers
+      77:79.
+
+               C: A007 FETCH 77:79 (FLAGS)
+               S: * 77 FETCH (FLAGS (\Draft))
+               S: * 78 FETCH (FLAGS (\Answered))
+               S: * 79 FETCH (FLAGS ($Forwarded \Seen))
+               S: A007 OK Fetch Completed
+
+      \Deleted flag was lost on COPY, as the user has no "t" right in
+      the target mailbox.
+      If the MYRIGHTS command with the tag A003 would have returned:
+
+               S: * MYRIGHTS TargetMailbox rsti
+
+      the response from the FETCH with the tag A007 would have been:
+
+               C: A007 FETCH 77:79 (FLAGS)
+
+
+
+Melnikov                    Standards Track                    [Page 15]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+               S: * 77 FETCH (FLAGS (\Deleted))
+               S: * 78 FETCH (FLAGS ())
+               S: * 79 FETCH (FLAGS (\Seen))
+               S: A007 OK Fetch Completed
+
+      In the latter case, \Answered, $Forwarded, and \Draft flags were
+      lost on COPY, as the user has no "w" right in the target mailbox.
+
+   Expunging the selected mailbox:
+      EXPUNGE - "e" right on the selected mailbox.
+
+      CLOSE - "e" right on the selected mailbox.  If the server is
+      unable to expunge the mailbox because the user doesn't have the
+      "e" right, the server MUST ignore the expunge request, close the
+      mailbox, and return the tagged OK response.
+
+   Fetch information about a mailbox and its messages:
+      SELECT/EXAMINE/STATUS - "r" right on the mailbox.
+
+      FETCH - A FETCH request that implies setting \Seen flag MUST NOT
+      set it, if the current user doesn't have "s" right.
+
+   Changing flags:
+      STORE - the server MUST check if the user has
+         "t" right - when the user modifies \Deleted flag
+         "s" right - when the user modifies \Seen flag
+         "w" right - for all other message flags.
+      STORE operation SHOULD NOT fail if the user has rights to modify
+      at least one flag specified in the STORE, as the tagged NO
+      response to a STORE command is not handled very well by deployed
+      clients.
+
+   Changing ACLs:
+      SETACL/DELETEACL - "a" right on the mailbox.
+
+   Reading ACLs:
+      GETACL - "a" right on the mailbox.
+
+      MYRIGHTS - any of the following rights is required to perform the
+      operation: "l", "r", "i", "k", "x", "a".
+
+      LISTRIGHTS - "a" right on the mailbox.
+
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 16]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+5.  Other Considerations
+
+5.1.  Additional Requirements and Implementation Notes
+
+5.1.1.  Servers
+
+   This document defines an additional capability that is used to
+   announce the list of extra rights (excluding the ones defined in RFC
+   2086) supported by the server.  The set of rights MUST include "t",
+   "e", "x", and "k".  Note that the extra rights can appear in any
+   order.
+
+   Example:    C: 1 capability
+               S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+
+                  ACL RIGHTS=texk
+               S: 1 OK completed
+
+   Any server implementing an ACL extension MUST accurately reflect the
+   current user's rights in FLAGS and PERMANENTFLAGS responses.
+
+   Example:    C: A142 SELECT INBOX
+               S: * 172 EXISTS
+               S: * 1 RECENT
+               S: * OK [UNSEEN 12] Message 12 is first unseen
+               S: * OK [UIDVALIDITY 3857529045] UIDs valid
+               S: * OK [UIDNEXT 4392] Predicted next UID
+               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+               S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L
+               S: A142 OK [READ-WRITE] SELECT completed
+               C: A143 MYRIGHTS INBOX
+               S: * MYRIGHTS INBOX lrwis
+               S: A143 OK completed
+
+   Note that in order to get better performance the client MAY pipeline
+   SELECT and MYRIGHTS commands:
+
+               C: A142 SELECT INBOX
+               C: A143 MYRIGHTS INBOX
+               S: * 172 EXISTS
+               S: * 1 RECENT
+               S: * OK [UNSEEN 12] Message 12 is first unseen
+               S: * OK [UIDVALIDITY 3857529045] UIDs valid
+               S: * OK [UIDNEXT 4392] Predicted next UID
+               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+               S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L
+               S: A142 OK [READ-WRITE] SELECT completed
+               S: * MYRIGHTS INBOX lrwis
+               S: A143 OK completed
+
+
+
+Melnikov                    Standards Track                    [Page 17]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   Servers MAY cache the rights a user has on a mailbox when the mailbox
+   is selected, so that if a client's rights on a mailbox are changed
+   with SETACL or DELETEACL, commands specific to the selected state
+   (e.g., STORE, EXPUNGE) might not reflect the changed rights until the
+   mailbox is re-selected.  If the server checks the rights on each
+   command, then it SHOULD send FLAGS and PERMANENTFLAGS responses if
+   they have changed.  If such server detects that the user no longer
+   has read access to the mailbox, it MAY send an untagged BYE response
+   and close connection.  It MAY also refuse to execute all commands
+   specific to the selected state until the mailbox is closed; however,
+   server implementors should note that most clients don't handle NO
+   responses very well.
+
+   An ACL server MAY modify one or more ACLs for one or more identifiers
+   as a side effect of modifying the ACL specified in a
+   SETACL/DELETEACL.  If the server does that, it MUST send untagged ACL
+   response(s) to notify the client about the changes made.
+
+   An ACL server implementation MUST treat received ACL modification
+   commands as a possible ambiguity with respect to subsequent commands
+   affected by the ACL, as described in Section 5.5 of [IMAP4].  Hence a
+   pipeline SETACL + MYRIGHTS is an ambiguity with respect to the
+   server, meaning that the server must execute the SETACL command to
+   completion before the MYRIGHTS.  However, clients are permitted to
+   send such a pipeline.
+
+5.1.2.  Clients
+
+   The following requirement is put on clients in order to allow for
+   future extensibility.  A client implementation that allows a user to
+   read and update ACLs MUST preserve unrecognized rights that it
+   doesn't allow the user to change.  That is, if the client
+
+   1) can read ACLs
+    and
+   2) can update ACLs
+    but
+   3) doesn't allow the user to change the rights the client doesn't
+   recognize, then it MUST preserve unrecognized rights.
+
+   Otherwise the client could risk unintentionally removing permissions
+   it doesn't understand.
+
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 18]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+5.2.  Mapping of ACL Rights to READ-WRITE and READ-ONLY Response Codes
+
+   A particular ACL server implementation MAY allow "shared multiuser
+   access" to some mailboxes.  "Shared multiuser access" to a mailbox
+   means that multiple different users are able to access the same
+   mailbox, if they have proper access rights.  "Shared multiuser
+   access" to the mailbox doesn't mean that the ACL for the mailbox is
+   currently set to allow access by multiple users.  Let's denote a
+   "shared multiuser write access" as a "shared multiuser access" when a
+   user can be granted flag modification rights (any of "w", "s", or
+   "t").
+
+   Section 4 describes which rights are required for modifying different
+   flags.
+
+   If the ACL server implements some flags as shared for a mailbox
+   (i.e., the ACL for the mailbox MAY be set up so that changes to those
+   flags are visible to another user), let's call the set of rights
+   associated with these flags (as described in Section 4) for that
+   mailbox collectively as "shared flag rights".  Note that the "shared
+   flag rights" set MAY be different for different mailboxes.
+
+   If the server doesn't support "shared multiuser write access" to a
+   mailbox or doesn't implement shared flags on the mailbox, "shared
+   flag rights" for the mailbox is defined to be the empty set.
+
+   Example 1: Mailbox "banan" allows "shared multiuser write access" and
+              implements flags \Deleted, \Answered, and $MDNSent as
+              shared flags. "Shared flag rights" for the mailbox "banan"
+              is a set containing flags "t" (because system flag
+              \Deleted requires "t" right) and "w" (because both
+              \Answered and $MDNSent require "w" right).
+
+   Example 2: Mailbox "apple" allows "shared multiuser write access" and
+              implements \Seen system flag as shared flag. "Shared flag
+              rights" for the mailbox "apple" contains "s" right
+              because system flag \Seen requires "s" right.
+
+   Example 3: Mailbox "pear" allows "shared multiuser write access" and
+              implements flags \Seen, \Draft as shared flags. "Shared
+              flag rights" for the mailbox "apple" is a set containing
+              flags "s" (because system flag \Seen requires "s" right)
+              and "w" (because system flag \Draft requires "w" right).
+
+   The server MUST include a READ-ONLY response code in the tagged OK
+   response to a SELECT command if none of the following rights is
+   granted to the current user:
+
+
+
+
+Melnikov                    Standards Track                    [Page 19]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+    "i", "e", and "shared flag rights"(***).
+
+   The server SHOULD include a READ-WRITE response code in the tagged OK
+   response if at least one of the "i", "e", or "shared flag
+   rights"(***) is granted to the current user.
+
+   (***) Note that a future extension to this document can extend the
+   list of rights that causes the server to return the READ-WRITE
+   response code.
+
+   Example 1 (continued): The user that has "lrs" rights for the mailbox
+                          "banan".  The server returns READ-ONLY
+                          response code on SELECT, as none of "iewt"
+                          rights is granted to the user.
+
+   Example 2 (continued): The user that has "rit" rights for the mailbox
+                          "apple".  The server returns READ-WRITE
+                          response code on SELECT, as the user has "i"
+                          right.
+
+   Example 3 (continued): The user that has "rset" rights for the
+                          mailbox "pear".  The server returns READ-WRITE
+                          response code on SELECT, as the user has "e"
+                          and "s" rights.
+
+6.  Security Considerations
+
+   An implementation MUST make sure the ACL commands themselves do not
+   give information about mailboxes with appropriately restricted ACLs.
+   For example, when a user agent executes a GETACL command on a mailbox
+   that the user has no permission to LIST, the server would respond to
+   that request with the same error that would be used if the mailbox
+   did not exist, thus revealing no existence information, much less the
+   mailbox's ACL.
+
+   IMAP clients implementing ACL that are able to modify ACLs SHOULD
+   warn a user that wants to give full access (or even just the "a"
+   right) to the special identifier "anyone".
+
+   This document relies on [SASLprep] to describe steps required to
+   perform identifier canonicalization (preparation).  The preparation
+   algorithm in SASLprep was specifically designed such that its output
+   is canonical, and it is well-formed.  However, due to an anomaly
+   [PR29] in the specification of Unicode normalization, canonical
+   equivalence is not guaranteed for a select few character sequences.
+   Identifiers prepared with SASLprep can be stored and returned by an
+   ACL server.  The anomaly affects ACL manipulation and evaluation of
+   identifiers containing the selected character sequences.  These
+
+
+
+Melnikov                    Standards Track                    [Page 20]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   sequences, however, do not appear in well-formed text.  In order to
+   address this problem, an ACL server MAY reject identifiers containing
+   sequences described in [PR29] by sending the tagged BAD response.
+   This is in addition to the requirement to reject identifiers that
+   fail SASLprep preparation as described in Section 3.
+
+   Other security considerations described in [IMAP4] are relevant to
+   this document.  In particular, ACL information is sent in the clear
+   over the network unless confidentiality protection is negotiated.
+
+   This can be accomplished either by the use of STARTTLS, negotiated
+   privacy protection in the AUTHENTICATE command, or some other
+   protection mechanism.
+
+7.  Formal Syntax
+
+   Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
+   in Section 9 of [IMAP4].  Elements not defined here can be found in
+   [ABNF] and [IMAP4].
+
+   Except as noted otherwise, all alphabetic characters are case
+   insensitive.  The use of uppercase or lowercase characters to define
+   token strings is for editorial clarity only.  Implementations MUST
+   accept these strings in a case-insensitive fashion.
+
+   LOWER-ALPHA     =  %x61-7A   ;; a-z
+
+   acl-data        = "ACL" SP mailbox *(SP identifier SP
+                       rights)
+
+   capability      =/ rights-capa
+                       ;;capability is defined in [IMAP4]
+
+   command-auth    =/ setacl / deleteacl / getacl /
+                       listrights / myrights
+                       ;;command-auth is defined in [IMAP4]
+
+   deleteacl       = "DELETEACL" SP mailbox SP identifier
+
+   getacl          = "GETACL" SP mailbox
+
+   identifier      = astring
+
+   listrights      = "LISTRIGHTS" SP mailbox SP identifier
+
+   listrights-data = "LISTRIGHTS" SP mailbox SP identifier
+                           SP rights *(SP rights)
+
+
+
+
+Melnikov                    Standards Track                    [Page 21]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   mailbox-data    =/ acl-data / listrights-data / myrights-data
+                       ;;mailbox-data is defined in [IMAP4]
+
+   mod-rights      = astring
+                       ;; +rights to add, -rights to remove
+                       ;; rights to replace
+
+   myrights        = "MYRIGHTS" SP mailbox
+
+   myrights-data   = "MYRIGHTS" SP mailbox SP rights
+
+   new-rights      = 1*LOWER-ALPHA
+                       ;; MUST include "t", "e", "x", and "k".
+                       ;; MUST NOT include standard rights listed
+                       ;; in section 2.2
+
+   rights          = astring
+                       ;; only lowercase ASCII letters and digits
+                       ;; are allowed.
+
+   rights-capa     = "RIGHTS=" new-rights
+                       ;; RIGHTS=... capability
+
+   setacl          = "SETACL" SP mailbox SP identifier
+                       SP mod-rights
+
+8.  IANA Considerations
+
+   IMAP4 capabilities are registered by publishing a standards-track or
+   IESG-approved experimental RFC.  The registry is currently located
+   at:
+
+      http://www.iana.org/assignments/imap4-capabilities
+
+   This document defines the RIGHTS= IMAP capability.  IANA has added
+   this capability to the registry.
+
+9.  Internationalization Considerations
+
+   Section 3 states requirements on servers regarding
+   internationalization of identifiers.
+
+
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 22]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+Appendix A.  Changes since RFC 2086
+
+   1.   Changed the charset of "identifier" from US-ASCII to UTF-8.
+   2.   Specified that mailbox deletion is controlled by the "x" right
+        and EXPUNGE is controlled by the "e" right.
+   3.   Added the "t" right that controls STORE \Deleted.  Redefined the
+        "d" right to be a macro for "e", "t", and possibly "x".
+   4.   Added the "k" right that controls CREATE.  Redefined the "c"
+        right to be a macro for "k" and possibly "x".
+   5.   Specified that the "a" right also controls DELETEACL.
+   6.   Specified that the "r" right also controls STATUS.
+   7.   Removed the requirement to check the "r" right for CHECK, SEARCH
+        and FETCH, as this is required for SELECT/EXAMINE to be
+        successful.
+   8.   LISTRIGHTS requires the "a" right on the mailbox (same as
+        SETACL).
+   9.   Deleted "PARTIAL", this is a deprecated feature of RFC 1730.
+   10.  Specified that the "w" right controls setting flags other than
+        \Seen and \Deleted on APPEND.  Also specified that the "s" right
+        controls the \Seen flag and that the "t" right controls the
+        \Deleted flag.
+   11.  Specified that SUBSCRIBE is NOT allowed with the "r" right.
+   12.  Specified that the "l" right controls SUBSCRIBE.
+   13.  GETACL is NOT allowed with the "r" right, even though there are
+        several implementations that allows that.  If a user only has
+        "r" right, GETACL can disclose information about identifiers
+        existing on the mail system.
+   14.  Clarified that RENAME requires the "k" right for the new parent
+        and the "x" right for the old name.
+   15.  Added new section that describes which rights are required
+        and/or checked when performing various IMAP commands.
+   16.  Added mail client security considerations when dealing with
+        special identifier "anyone".
+   17.  Clarified that negative rights are not the same as DELETEACL.
+   18.  Added "Compatibility with RFC 2086" section.
+   19.  Added section about mapping of ACL rights to READ-WRITE and
+        READ-ONLY response codes.
+   20.  Changed BNF to ABNF.
+   21.  Added "Implementation Notes" section.
+   22.  Updated "References" section.
+   23.  Added more examples.
+   24.  Clarified when the virtual "c" and "d" rights are returned in
+        ACL, MYRIGHTS, and LISTRIGHTS responses.
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 23]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+Appendix B.  Compatibility with RFC 2086
+
+   This non-normative section gives guidelines as to how an existing RFC
+   2086 server implementation may be updated to comply with this
+   document.
+
+   This document splits the "d" right into several new different rights:
+   "t", "e", and possibly "x" (see Section 2.1.1 for more details).  The
+   "d" right remains for backward-compatibility, but it is a virtual
+   right.  There are two approaches for RFC 2086 server implementors to
+   handle the "d" right and the new rights that have replaced it:
+
+   a.  Tie "t", "e" (and possibly "x) together - almost no changes.
+   b.  Implement separate "x", "t" and "e".  Return the "d" right in a
+       MYRIGHTS response or an ACL response containing ACL information
+       when any of the "t", "e" (and "x") is granted.
+
+   In a similar manner this document splits the "c" right into several
+   new different rights: "k" and possibly "x" (see Section 2.1.1 for
+   more details).  The "c" right remains for backwards-compatibility but
+   it is a virtual right.  Again, RFC 2086 server implementors can
+   choose to tie rights or to implement separate rights, as described
+   above.
+
+   Also check Sections 5.1.1 and 5.1.2, as well as Appendix A, to see
+   other changes required.  Server implementors should check which
+   rights are required to invoke different IMAP4 commands as described
+   in Section 4.
+
+Appendix C.  Known Deficiencies
+
+   This specification has some known deficiencies including:
+
+   1.  This is inadequate to provide complete read-write access to
+       mailboxes protected by Unix-style rights bits because there is no
+       equivalent to "chown" and "chgrp" commands nor is there a good
+       way to discover such limitations are present.
+   2.  Because this extension leaves the specific semantics of how
+       rights are combined by the server as implementation defined, the
+       ability to build a user-friendly interface is limited.
+   3.  Users, groups, and special identifiers (e.g., anyone) exist in
+       the same namespace.
+
+   The work-in-progress "ACL2" extension is intended to redesign this
+   extension to address these deficiencies without the constraint of
+   backward-compatibility and may eventually supercede this facility.
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 24]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   However, RFC 2086 is deployed in multiple implementations so this
+   intermediate step, which fixes the straightforward deficiencies in a
+   backward-compatible fashion, is considered worthwhile.
+
+Appendix D.  Acknowledgements
+
+   This document is a revision of RFC 2086 written by John G. Myers.
+
+   Editor appreciates comments received from Mark Crispin, Chris Newman,
+   Cyrus Daboo, John G. Myers, Dave Cridland, Ken Murchison, Steve Hole,
+   Vladimir Butenko, Larry Greenfield, Robert Siemborski, Harrie
+   Hazewinkel, Philip Guenther, Brian Candler, Curtis King, Lyndon
+   Nerenberg, Lisa Dusseault, Arnt Gulbrandsen, and other participants
+   of the IMAPEXT working group.
+
+Normative References
+
+   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [ABNF]       Crocker, D. and P. Overell, "Augmented BNF for Syntax
+                Specifications: ABNF", RFC 4234, October 2005.
+
+   [IMAP4]      Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+                4rev1", RFC 3501, March 2003.
+
+   [UTF-8]      Yergeau, F., "UTF-8, a transformation format of ISO
+                10646", STD 63, RFC 3629, November 2003.
+
+   [Stringprep] Hoffman, P. and M. Blanchet, "Preparation of
+                Internationalized Strings ("stringprep")", RFC 3454,
+                December 2002.
+
+   [SASLprep]   Zeilenga, K., "SASLprep: Stringprep Profile for User
+                Names and Passwords", RFC 4013, February 2005.
+
+Informative References
+
+   [RFC2086]    Myers, J., "IMAP4 ACL extension", RFC 2086,
+                January 1997.
+
+   [PR29]       "Public Review Issue #29: Normalization Issue",
+                February 2004,
+                <http://www.unicode.org/review/pr-29.html>.
+
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 25]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+Author's Address
+
+   Alexey Melnikov
+   Isode Ltd.
+   5 Castle Business Village
+   36 Station Road
+   Hampton, Middlesex  TW12 2BX
+   GB
+
+   EMail: alexey.melnikov@isode.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 26]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 27]
+
diff --git a/docs/rfcs/rfc4315.txt b/docs/rfcs/rfc4315.txt
new file mode 100644
index 0000000..c026f42
--- /dev/null
+++ b/docs/rfcs/rfc4315.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                         M. Crispin
+Request for Comments: 4315                                 December 2005
+Obsoletes: 2359
+Category: Standards Track
+
+
+      Internet Message Access Protocol (IMAP) - UIDPLUS extension
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   The UIDPLUS extension of the Internet Message Access Protocol (IMAP)
+   provides a set of features intended to reduce the amount of time and
+   resources used by some client operations.  The features in UIDPLUS
+   are primarily intended for disconnected-use clients.
+
+1.  Introduction and Overview
+
+   The UIDPLUS extension is present in any IMAP server implementation
+   that returns "UIDPLUS" as one of the supported capabilities to the
+   CAPABILITY command.
+
+   The UIDPLUS extension defines an additional command.  In addition,
+   this document recommends new status response codes in IMAP that
+   SHOULD be returned by all server implementations, regardless of
+   whether or not the UIDPLUS extension is implemented.
+
+   The added facilities of the features in UIDPLUS are optimizations;
+   clients can provide equivalent functionality, albeit less
+   efficiently, by using facilities in the base protocol.
+
+1.1.  Conventions Used in This Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server, respectively.
+
+
+
+
+
+Crispin                     Standards Track                     [Page 1]
+
+RFC 4315                IMAP - UIDPLUS Extension           December 2005
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
+   be interpreted as described in [KEYWORDS].
+
+   A "UID set" is similar to the [IMAP] sequence set; however, the "*"
+   value for a sequence number is not permitted.
+
+2.  Additional Commands
+
+   The following command definition is an extension to [IMAP] section
+   6.4.
+
+2.1.  UID EXPUNGE Command
+
+   Arguments:  sequence set
+
+   Data:       untagged responses: EXPUNGE
+
+   Result:     OK - expunge completed
+               NO - expunge failure (e.g., permission denied)
+               BAD - command unknown or arguments invalid
+
+      The UID EXPUNGE command permanently removes all messages that both
+      have the \Deleted flag set and have a UID that is included in the
+      specified sequence set from the currently selected mailbox.  If a
+      message either does not have the \Deleted flag set or has a UID
+      that is not included in the specified sequence set, it is not
+      affected.
+
+      This command is particularly useful for disconnected use clients.
+      By using UID EXPUNGE instead of EXPUNGE when resynchronizing with
+      the server, the client can ensure that it does not inadvertantly
+      remove any messages that have been marked as \Deleted by other
+      clients between the time that the client was last connected and
+      the time the client resynchronizes.
+
+      If the server does not support the UIDPLUS capability, the client
+      should fall back to using the STORE command to temporarily remove
+      the \Deleted flag from messages it does not want to remove, then
+      issuing the EXPUNGE command.  Finally, the client should use the
+      STORE command to restore the \Deleted flag on the messages in
+      which it was temporarily removed.
+
+      Alternatively, the client may fall back to using just the EXPUNGE
+      command, risking the unintended removal of some messages.
+
+
+
+
+
+
+Crispin                     Standards Track                     [Page 2]
+
+RFC 4315                IMAP - UIDPLUS Extension           December 2005
+
+
+   Example:    C: A003 UID EXPUNGE 3000:3002
+               S: * 3 EXPUNGE
+               S: * 3 EXPUNGE
+               S: * 3 EXPUNGE
+               S: A003 OK UID EXPUNGE completed
+
+3.  Additional Response Codes
+
+   The following response codes are extensions to the response codes
+   defined in [IMAP] section 7.1.  With limited exceptions, discussed
+   below, server implementations that advertise the UIDPLUS extension
+   SHOULD return these response codes.
+
+   In the case of a mailbox that has permissions set so that the client
+   can COPY or APPEND to the mailbox, but not SELECT or EXAMINE it, the
+   server SHOULD NOT send an APPENDUID or COPYUID response code as it
+   would disclose information about the mailbox.
+
+   In the case of a mailbox that has UIDNOTSTICKY status (as defined
+   below), the server MAY omit the APPENDUID or COPYUID response code as
+   it is not meaningful.
+
+   If the server does not return the APPENDUID or COPYUID response
+   codes, the client can discover this information by selecting the
+   destination mailbox.  The location of messages placed in the
+   destination mailbox by COPY or APPEND can be determined by using
+   FETCH and/or SEARCH commands (e.g., for Message-ID or some unique
+   marker placed in the message in an APPEND).
+
+   APPENDUID
+
+      Followed by the UIDVALIDITY of the destination mailbox and the UID
+      assigned to the appended message in the destination mailbox,
+      indicates that the message has been appended to the destination
+      mailbox with that UID.
+
+      If the server also supports the [MULTIAPPEND] extension, and if
+      multiple messages were appended in the APPEND command, then the
+      second value is a UID set containing the UIDs assigned to the
+      appended messages, in the order they were transmitted in the
+      APPEND command.  This UID set may not contain extraneous UIDs or
+      the symbol "*".
+
+         Note: the UID set form of the APPENDUID response code MUST NOT
+         be used if only a single message was appended.  In particular,
+         a server MUST NOT send a range such as 123:123.  This is
+         because a client that does not support [MULTIAPPEND] expects
+         only a single UID and not a UID set.
+
+
+
+Crispin                     Standards Track                     [Page 3]
+
+RFC 4315                IMAP - UIDPLUS Extension           December 2005
+
+
+      UIDs are assigned in strictly ascending order in the mailbox
+      (refer to [IMAP], section 2.3.1.1) and UID ranges are as in
+      [IMAP]; in particular, note that a range of 12:10 is exactly
+      equivalent to 10:12 and refers to the sequence 10,11,12.
+
+      This response code is returned in a tagged OK response to the
+      APPEND command.
+
+   COPYUID
+
+      Followed by the UIDVALIDITY of the destination mailbox, a UID set
+      containing the UIDs of the message(s) in the source mailbox that
+      were copied to the destination mailbox and containing the UIDs
+      assigned to the copied message(s) in the destination mailbox,
+      indicates that the message(s) have been copied to the destination
+      mailbox with the stated UID(s).
+
+      The source UID set is in the order the message(s) were copied; the
+      destination UID set corresponds to the source UID set and is in
+      the same order.  Neither of the UID sets may contain extraneous
+      UIDs or the symbol "*".
+
+      UIDs are assigned in strictly ascending order in the mailbox
+      (refer to [IMAP], section 2.3.1.1) and UID ranges are as in
+      [IMAP]; in particular, note that a range of 12:10 is exactly
+      equivalent to 10:12 and refers to the sequence 10,11,12.
+
+      This response code is returned in a tagged OK response to the COPY
+      command.
+
+   UIDNOTSTICKY
+
+      The selected mailbox is supported by a mail store that does not
+      support persistent UIDs; that is, UIDVALIDITY will be different
+      each time the mailbox is selected.  Consequently, APPEND or COPY
+      to this mailbox will not return an APPENDUID or COPYUID response
+      code.
+
+      This response code is returned in an untagged NO response to the
+      SELECT command.
+
+         Note: servers SHOULD NOT have any UIDNOTSTICKY mail stores.
+         This facility exists to support legacy mail stores in which it
+         is technically infeasible to support persistent UIDs.  This
+         should be avoided when designing new mail stores.
+
+
+
+
+
+
+Crispin                     Standards Track                     [Page 4]
+
+RFC 4315                IMAP - UIDPLUS Extension           December 2005
+
+
+   Example:    C: A003 APPEND saved-messages (\Seen) {297}
+               C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
+               C: From: Fred Foobar <foobar@example.com>
+               C: Subject: afternoon meeting
+               C: To: mooch@example.com
+               C: Message-Id: <B27397-0100000@example.com>
+               C: MIME-Version: 1.0
+               C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+               C:
+               C: Hello Joe, do you think we can meet at 3:30 tomorrow?
+               C:
+               S: A003 OK [APPENDUID 38505 3955] APPEND completed
+               C: A004 COPY 2:4 meeting
+               S: A004 OK [COPYUID 38505 304,319:320 3956:3958] Done
+               C: A005 UID COPY 305:310 meeting
+               S: A005 OK No matching messages, so nothing copied
+               C: A006 COPY 2 funny
+               S: A006 OK Done
+               C: A007 SELECT funny
+               S: * 1 EXISTS
+               S: * 1 RECENT
+               S: * OK [UNSEEN 1] Message 1 is first unseen
+               S: * OK [UIDVALIDITY 3857529045] Validity session-only
+               S: * OK [UIDNEXT 2] Predicted next UID
+               S: * NO [UIDNOTSTICKY] Non-persistent UIDs
+               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+               S: * OK [PERMANENTFLAGS (\Deleted \Seen)] Limited
+               S: A007 OK [READ-WRITE] SELECT completed
+
+   In this example, A003 and A004 demonstrate successful appending and
+   copying to a mailbox that returns the UIDs assigned to the messages.
+   A005 is an example in which no messages were copied; this is because
+   in A003, we see that message 2 had UID 304, and message 3 had UID
+   319; therefore, UIDs 305 through 310 do not exist (refer to section
+   2.3.1.1 of [IMAP] for further explanation).  A006 is an example of a
+   message being copied that did not return a COPYUID; and, as expected,
+   A007 shows that the mail store containing that mailbox does not
+   support persistent UIDs.
+
+4.  Formal Syntax
+
+   Formal syntax is defined using ABNF [ABNF], which extends the ABNF
+   rules defined in [IMAP].  The IMAP4 ABNF should be imported before
+   attempting to validate these rules.
+
+   append-uid      = uniqueid
+
+   capability      =/ "UIDPLUS"
+
+
+
+Crispin                     Standards Track                     [Page 5]
+
+RFC 4315                IMAP - UIDPLUS Extension           December 2005
+
+
+   command-select  =/ uid-expunge
+
+   resp-code-apnd  = "APPENDUID" SP nz-number SP append-uid
+
+   resp-code-copy  = "COPYUID" SP nz-number SP uid-set SP uid-set
+
+   resp-text-code  =/ resp-code-apnd / resp-code-copy / "UIDNOTSTICKY"
+                     ; incorporated before the expansion rule of
+                     ;  atom [SP 1*<any TEXT-CHAR except "]">]
+                     ; that appears in [IMAP]
+
+   uid-expunge     = "UID" SP "EXPUNGE" SP sequence-set
+
+   uid-set         = (uniqueid / uid-range) *("," uid-set)
+
+   uid-range       = (uniqueid ":" uniqueid)
+                     ; two uniqueid values and all values
+                     ; between these two regards of order.
+                     ; Example: 2:4 and 4:2 are equivalent.
+
+   Servers that support [MULTIAPPEND] will have the following extension
+   to the above rules:
+
+   append-uid      =/ uid-set
+                     ; only permitted if client uses [MULTIAPPEND]
+                     ; to append multiple messages.
+
+5.  Security Considerations
+
+   The COPYUID and APPENDUID response codes return information about the
+   mailbox, which may be considered sensitive if the mailbox has
+   permissions set that permit the client to COPY or APPEND to the
+   mailbox, but not SELECT or EXAMINE it.
+
+   Consequently, these response codes SHOULD NOT be issued if the client
+   does not have access to SELECT or EXAMINE the mailbox.
+
+6.  IANA Considerations
+
+   This document constitutes registration of the UIDPLUS capability in
+   the imap4-capabilities registry, replacing [RFC2359].
+
+7.  Normative References
+
+   [ABNF]        Crocker, D. and P. Overell, "Augmented BNF for Syntax
+                 Specifications: ABNF", RFC 4234, October 2005.
+
+
+
+
+
+Crispin                     Standards Track                     [Page 6]
+
+RFC 4315                IMAP - UIDPLUS Extension           December 2005
+
+
+   [IMAP]        Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
+                 VERSION 4rev1", RFC 3501, March 2003.
+
+   [KEYWORDS]    Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) -
+                 MULTIAPPEND Extension", RFC 3502, March 2003.
+
+8.  Informative References
+
+   [RFC2359]     Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June
+                 1998.
+
+9.  Changes from RFC 2359
+
+   This document obsoletes [RFC2359].  However, it is based upon that
+   document, and takes substantial text from it (albeit with numerous
+   clarifications in wording).
+
+   [RFC2359] implied that a server must always return COPYUID/APPENDUID
+   data; thus suggesting that in such cases the server should return
+   arbitrary data if the destination mailbox did not support persistent
+   UIDs.  This document adds the UIDNOTSTICKY response code to indicate
+   that a mailbox does not support persistent UIDs, and stipulates that
+   a UIDPLUS server does not return COPYUID/APPENDUID data when the COPY
+   (or APPEND) destination mailbox has UIDNOTSTICKY status.
+
+Author's Address
+
+   Mark R. Crispin
+   Networks and Distributed Computing
+   University of Washington
+   4545 15th Avenue NE
+   Seattle, WA  98105-4527
+
+   Phone: (206) 543-5762
+   EMail: MRC@CAC.Washington.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                     [Page 7]
+
+RFC 4315                IMAP - UIDPLUS Extension           December 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Crispin                     Standards Track                     [Page 8]
+
diff --git a/docs/rfcs/rfc4466.txt b/docs/rfcs/rfc4466.txt
new file mode 100644
index 0000000..dfde168
--- /dev/null
+++ b/docs/rfcs/rfc4466.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                        A. Melnikov
+Request for Comments: 4466                                    Isode Ltd.
+Updates: 2088, 2342, 3501, 3502, 3516                           C. Daboo
+Category: Standards Track                                     April 2006
+
+
+                   Collected Extensions to IMAP4 ABNF
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   Over the years, many documents from IMAPEXT and LEMONADE working
+   groups, as well as many individual documents, have added syntactic
+   extensions to many base IMAP commands described in RFC 3501.  For
+   ease of reference, this document collects most of such ABNF changes
+   in one place.
+
+   This document also suggests a set of standard patterns for adding
+   options and extensions to several existing IMAP commands defined in
+   RFC 3501.  The patterns provide for compatibility between existing
+   and future extensions.
+
+   This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.
+   It also includes part of the errata to RFC 3501.  This document
+   doesn't specify any semantic changes to the listed RFCs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov & Daboo            Standards Track                     [Page 1]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Purpose of This Document ...................................2
+      1.2. Conventions Used in This Document ..........................3
+   2. IMAP ABNF Extensions ............................................3
+      2.1. Optional Parameters with the SELECT/EXAMINE Commands .......3
+      2.2. Extended CREATE Command ....................................4
+      2.3. Extended RENAME Command ....................................5
+      2.4. Extensions to FETCH and UID FETCH Commands .................6
+      2.5. Extensions to STORE and UID STORE Commands .................6
+      2.6. Extensions to SEARCH Command ...............................7
+           2.6.1. Extended SEARCH Command .............................7
+           2.6.2. ESEARCH untagged response ...........................8
+      2.7. Extensions to APPEND Command ...............................8
+   3. Formal Syntax ...................................................9
+   4. Security Considerations ........................................14
+   5. Normative References ...........................................15
+   6. Acknowledgements ...............................................15
+
+1.  Introduction
+
+1.1.  Purpose of This Document
+
+   This document serves several purposes:
+
+      1.  rationalize and generalize ABNF for some existing IMAP
+          extensions;
+      2.  collect the ABNF in one place in order to minimize cross
+          references between documents;
+      3.  define building blocks for future extensions so that they can
+          be used together in a compatible way.
+
+   It is expected that a future revision of this document will be
+   incorporated into a revision of RFC 3501.
+
+   This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.
+   It also includes part of the errata to RFC 3501.  This document
+   doesn't specify any semantic changes to the listed RFCs.
+
+   The ABNF in section 6 of RFC 2342 got rewritten to conform to the
+   ABNF syntax as defined in RFC 4234 and to reference new non-terminals
+   from RFC 3501.  It was also restructured to allow for better
+   readability.  There were no changes "on the wire".
+
+   Section 2 extends ABNF for SELECT, EXAMINE, CREATE, RENAME, FETCH/UID
+   FETCH, STORE/UID STORE, SEARCH, and APPEND commands in a consistent
+   manner.  Extensions to all the commands but APPEND have the same
+
+
+
+Melnikov & Daboo            Standards Track                     [Page 2]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+   structure.  Extensibility for the APPEND command was done slightly
+   differently in order to preserve backward compatibility with existing
+   extensions.
+
+   Section 2 also defines a new ESEARCH response, whose purpose is to
+   define a better version of the SEARCH response defined in RFC 3501.
+
+   Section 3 defines the collected ABNF that replaces pieces of ABNF in
+   the aforementioned RFCs.  The collected ABNF got generalized to allow
+   for easier future extensibility.
+
+1.2.  Conventions Used in This Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server, respectively.
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+   in this document are to be interpreted as defined in "Key words for
+   use in RFCs to Indicate Requirement Levels" [KEYWORDS].
+
+2.  IMAP ABNF Extensions
+
+   This section is not normative.  It provides some background on the
+   intended use of different extensions and it gives some guidance about
+   how future extensions should extend the described commands.
+
+2.1.  Optional Parameters with the SELECT/EXAMINE Commands
+
+   This document adds the ability to include one or more parameters with
+   the IMAP SELECT (section 6.3.1 of [IMAP4]) or EXAMINE (section 6.3.2
+   of [IMAP4]) commands, to turn on or off certain standard behaviors,
+   or to add new optional behaviors required for a particular extension.
+
+   There are two possible modes of operation:
+
+   o  A global state change where a single use of the optional parameter
+      will affect the session state from that time on, irrespective of
+      subsequent SELECT/EXAMINE commands.
+
+   o  A per-mailbox state change that will affect the session only for
+      the duration of the new selected state.  A subsequent
+      SELECT/EXAMINE without the optional parameter will cancel its
+      effect for the newly selected mailbox.
+
+   Optional parameters to the SELECT or EXAMINE commands are added as a
+   parenthesized list of attribute/value pairs, and appear after the
+   mailbox name in the standard SELECT or EXAMINE command.  The order of
+   individual parameters is arbitrary.  A parameter value is optional
+
+
+
+Melnikov & Daboo            Standards Track                     [Page 3]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+   and may consist of atoms, strings, or lists in a specific order.  If
+   the parameter value is present, it always appears in parentheses (*).
+   Any parameter not defined by extensions that the server supports must
+   be rejected with a BAD response.
+
+      Example:
+
+              C: a SELECT INBOX (ANNOTATE)
+              S: ...
+              S: a OK SELECT complete
+
+      In the above example, a single parameter is used with the SELECT
+      command.
+
+      Example:
+
+              C: a EXAMINE INBOX (ANNOTATE RESPONSES ("UID Responses")
+                 CONDSTORE)
+              S: ...
+              S: a OK EXAMINE complete
+
+      In the above example, three parameters are used with the EXAMINE
+      command.  The second parameter consists of two items: an atom
+      "RESPONSES" followed by a quoted string.
+
+      Example:
+
+              C: a SELECT INBOX (BLURDYBLOOP)
+              S: a BAD Unknown parameter in SELECT command
+
+      In the above example, a parameter not supported by the server is
+      used.  This results in the BAD response from the server.
+
+   (*) - if a parameter has a mandatory value, which can always be
+   represented as a number or a sequence-set, the parameter value does
+   not need the enclosing ().  See ABNF for more details.
+
+2.2.  Extended CREATE Command
+
+   Arguments:  mailbox name
+               OPTIONAL list of CREATE parameters
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - create completed
+               NO - create failure: cannot create mailbox with
+                    that name
+               BAD - argument(s) invalid
+
+
+
+Melnikov & Daboo            Standards Track                     [Page 4]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+   This document adds the ability to include one or more parameters with
+   the IMAP CREATE command (see section 6.3.3 of [IMAP4]), to turn on or
+   off certain standard behaviors, or to add new optional behaviors
+   required for a particular extension.  No CREATE parameters are
+   defined in this document.
+
+   Optional parameters to the CREATE command are added as a
+   parenthesized list of attribute/value pairs after the mailbox name.
+   The order of individual parameters is arbitrary.  A parameter value
+   is optional and may consist of atoms, strings, or lists in a specific
+   order.  If the parameter value is present, it always appears in
+   parentheses (*).  Any parameter not defined by extensions that the
+   server supports must be rejected with a BAD response.
+
+   (*) - if a parameter has a mandatory value, which can always be
+   represented as a number or a sequence-set, the parameter value does
+   not need the enclosing ().  See ABNF for more details.
+
+2.3.  Extended RENAME Command
+
+   Arguments:  existing mailbox name
+               new mailbox name
+               OPTIONAL list of RENAME parameters
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - rename completed
+               NO - rename failure: cannot rename mailbox with
+                    that name, cannot rename to mailbox with
+                    that name, etc.
+               BAD - argument(s) invalid
+
+   This document adds the ability to include one or more parameters with
+   the IMAP RENAME command (see section 6.3.5 of [IMAP4]), to turn on or
+   off certain standard behaviors, or to add new optional behaviors
+   required for a particular extension.  No RENAME parameters are
+   defined in this document.
+
+   Optional parameters to the RENAME command are added as a
+   parenthesized list of attribute/value pairs after the new mailbox
+   name.  The order of individual parameters is arbitrary.  A parameter
+   value is optional and may consist of atoms, strings, or lists in a
+   specific order.  If the parameter value is present, it always appears
+   in parentheses (*).  Any parameter not defined by extensions that the
+   server supports must be rejected with a BAD response.
+
+
+
+
+
+
+Melnikov & Daboo            Standards Track                     [Page 5]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+   (*) - if a parameter has a mandatory value, which can always be
+   represented as a number or a sequence-set, the parameter value does
+   not need the enclosing ().  See ABNF for more details.
+
+2.4.  Extensions to FETCH and UID FETCH Commands
+
+   Arguments:  sequence set
+               message data item names or macro
+               OPTIONAL fetch modifiers
+
+   Responses:  untagged responses: FETCH
+
+   Result:     OK - fetch completed
+               NO - fetch error: cannot fetch that data
+               BAD - command unknown or arguments invalid
+
+   This document extends the syntax of the FETCH and UID FETCH commands
+   (see section 6.4.5 of [IMAP4]) to include optional FETCH modifiers.
+   No fetch modifiers are defined in this document.
+
+   The order of individual modifiers is arbitrary.  Each modifier is an
+   attribute/value pair.  A modifier value is optional and may consist
+   of atoms and/or strings and/or lists in a specific order.  If the
+   modifier value is present, it always appears in parentheses (*).  Any
+   modifiers not defined by extensions that the server supports must be
+   rejected with a BAD response.
+
+   (*) - if a modifier has a mandatory value, which can always be
+   represented as a number or a sequence-set, the modifier value does
+   not need the enclosing ().  See ABNF for more details.
+
+2.5.  Extensions to STORE and UID STORE Commands
+
+   Arguments:  message set
+               OPTIONAL store modifiers
+               message data item name
+               value for message data item
+
+   Responses:  untagged responses: FETCH
+
+   Result:     OK - store completed
+               NO - store error: cannot store that data
+               BAD - command unknown or arguments invalid
+
+   This document extends the syntax of the STORE and UID STORE commands
+   (see section 6.4.6 of [IMAP4]) to include optional STORE modifiers.
+   No store modifiers are defined in this document.
+
+
+
+
+Melnikov & Daboo            Standards Track                     [Page 6]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+   The order of individual modifiers is arbitrary.  Each modifier is an
+   attribute/value pair.  A modifier value is optional and may consist
+   of atoms and/or strings and/or lists in a specific order.  If the
+   modifier value is present, it always appears in parentheses (*).  Any
+   modifiers not defined by extensions that the server supports must be
+   rejected with a BAD response.
+
+   (*) - if a modifier has a mandatory value, which can always be
+   represented as a number or a sequence-set, the modifier value does
+   not need the enclosing ().  See ABNF for more details.
+
+2.6.  Extensions to SEARCH Command
+
+2.6.1.  Extended SEARCH Command
+
+   Arguments:  OPTIONAL result specifier
+               OPTIONAL [CHARSET] specification
+               searching criteria (one or more)
+
+   Responses:  REQUIRED untagged response: SEARCH (*)
+
+   Result:     OK - search completed
+               NO - search error: cannot search that [CHARSET] or
+                    criteria
+               BAD - command unknown or arguments invalid
+
+   This section updates definition of the SEARCH command described in
+   section 6.4.4 of [IMAP4].
+
+   The SEARCH command is extended to allow for result options.  This
+   document does not define any result options.
+
+   The order of individual options is arbitrary.  Individual options may
+   contain parameters enclosed in parentheses (**).  If an option has
+   parameters, they consist of atoms and/or strings and/or lists in a
+   specific order.  Any options not defined by extensions that the
+   server supports must be rejected with a BAD response.
+
+   (*) - An extension to the SEARCH command may require another untagged
+   response, or no untagged response to be returned.  Section 2.6.2
+   defines a new ESEARCH untagged response that replaces the SEARCH
+   untagged response.  Note that for a given extended SEARCH command the
+   SEARCH and ESEARCH responses SHOULD be mutually exclusive, i.e., only
+   one of them should be returned.
+
+   (**) - if an option has a mandatory parameter, which can always be
+   represented as a number or a sequence-set, the option parameter does
+   not need the enclosing ().  See ABNF for more details.
+
+
+
+Melnikov & Daboo            Standards Track                     [Page 7]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+2.6.2.  ESEARCH untagged response
+
+   Contents:   one or more search-return-data pairs
+
+   The ESEARCH response SHOULD be sent as a result of an extended SEARCH
+   or UID SEARCH command specified in section 2.6.1.
+
+   The ESEARCH response starts with an optional search correlator.  If
+   it is missing, then the response was not caused by a particular IMAP
+   command, whereas if it is present, it contains the tag of the command
+   that caused the response to be returned.
+
+   The search correlator is followed by an optional UID indicator.  If
+   this indicator is present, all data in the ESEARCH response refers to
+   UIDs, otherwise all returned data refers to message numbers.
+
+   The rest of the ESEARCH response contains one or more search data
+   pairs.  Each pair starts with unique return item name, followed by a
+   space and the corresponding data.  Search data pairs may be returned
+   in any order.  Unless specified otherwise by an extension, any return
+   item name SHOULD appear only once in an ESEARCH response.
+
+   Example:    S: * ESEARCH UID COUNT 5 ALL 4:19,21,28
+
+   Example:    S: * ESEARCH (TAG "a567") UID COUNT 5 ALL 4:19,21,28
+
+   Example:    S: * ESEARCH COUNT 5 ALL 1:17,21
+
+2.7.  Extensions to APPEND Command
+
+   The IMAP BINARY extension [BINARY] extends the APPEND command to
+   allow a client to append data containing NULs by using the <literal8>
+   syntax.  The ABNF was rewritten to allow for easier extensibility by
+   IMAP extensions.  This document hasn't specified any semantical
+   changes to the [BINARY] extension.
+
+   In addition, the non-terminal "literal8" defined in [BINARY] got
+   extended to allow for non-synchronizing literals if both [BINARY] and
+   [LITERAL+] extensions are supported by the server.
+
+   The IMAP MULTIAPPEND extension [MULTIAPPEND] extends the APPEND
+   command to allow a client to append multiple messages atomically.
+   This document defines a common syntax for the APPEND command that
+   takes into consideration syntactic extensions defined by both
+   [BINARY] and [MULTIAPPEND] extensions.
+
+
+
+
+
+
+Melnikov & Daboo            Standards Track                     [Page 8]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+3.  Formal Syntax
+
+   The following syntax specification uses the Augmented Backus-Naur
+   Form (ABNF) notation as specified in [ABNF].
+
+   Non-terminals referenced but not defined below are as defined by
+   [IMAP4].
+
+   Except as noted otherwise, all alphabetic characters are case-
+   insensitive.  The use of uppercase or lowercase characters to define
+   token strings is for editorial clarity only.  Implementations MUST
+   accept these strings in a case-insensitive fashion.
+
+   append          = "APPEND" SP mailbox 1*append-message
+                     ;; only a single append-message may appear
+                     ;; if MULTIAPPEND [MULTIAPPEND] capability
+                     ;; is not present
+
+   append-message  = append-opts SP append-data
+
+   append-ext      = append-ext-name SP append-ext-value
+                     ;; This non-terminal define extensions to
+                     ;; to message metadata.
+
+   append-ext-name = tagged-ext-label
+
+   append-ext-value= tagged-ext-val
+                     ;; This non-terminal shows recommended syntax
+                     ;; for future extensions.
+
+
+   append-data     = literal / literal8 / append-data-ext
+
+   append-data-ext = tagged-ext
+                     ;; This non-terminal shows recommended syntax
+                     ;; for future extensions,
+                     ;; i.e., a mandatory label followed
+                     ;; by parameters.
+
+   append-opts     = [SP flag-list] [SP date-time] *(SP append-ext)
+                     ;; message metadata
+
+   charset         = atom / quoted
+                     ;; Exact syntax is defined in [CHARSET].
+
+   create          = "CREATE" SP mailbox
+                     [create-params]
+                     ;; Use of INBOX gives a NO error.
+
+
+
+Melnikov & Daboo            Standards Track                     [Page 9]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+   create-params   = SP "(" create-param *( SP create-param) ")"
+
+   create-param-name = tagged-ext-label
+
+   create-param      = create-param-name [SP create-param-value]
+
+   create-param-value= tagged-ext-val
+                     ;; This non-terminal shows recommended syntax
+                     ;; for future extensions.
+
+
+   esearch-response  = "ESEARCH" [search-correlator] [SP "UID"]
+                        *(SP search-return-data)
+                      ;; Note that SEARCH and ESEARCH responses
+                      ;; SHOULD be mutually exclusive,
+                      ;; i.e., only one of the response types
+                      ;; should be
+                      ;; returned as a result of a command.
+
+
+   examine         = "EXAMINE" SP mailbox [select-params]
+                     ;; modifies the original IMAP EXAMINE command
+                     ;; to accept optional parameters
+
+   fetch           = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
+                     "FAST" / fetch-att /
+                     "(" fetch-att *(SP fetch-att) ")")
+                     [fetch-modifiers]
+                     ;; modifies the original IMAP4 FETCH command to
+                     ;; accept optional modifiers
+
+   fetch-modifiers = SP "(" fetch-modifier *(SP fetch-modifier) ")"
+
+   fetch-modifier  = fetch-modifier-name [ SP fetch-modif-params ]
+
+   fetch-modif-params  = tagged-ext-val
+                     ;; This non-terminal shows recommended syntax
+                     ;; for future extensions.
+
+   fetch-modifier-name = tagged-ext-label
+
+   literal8        = "~{" number ["+"] "}" CRLF *OCTET
+                      ;; A string that might contain NULs.
+                      ;; <number> represents the number of OCTETs
+                      ;; in the response string.
+                      ;; The "+" is only allowed when both LITERAL+ and
+                      ;; BINARY extensions are supported by the server.
+
+
+
+
+Melnikov & Daboo            Standards Track                    [Page 10]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+   mailbox-data      =/ Namespace-Response /
+                        esearch-response
+
+   Namespace         = nil / "(" 1*Namespace-Descr ")"
+
+   Namespace-Command = "NAMESPACE"
+
+   Namespace-Descr   = "(" string SP
+                          (DQUOTE QUOTED-CHAR DQUOTE / nil)
+                           *(Namespace-Response-Extension) ")"
+
+   Namespace-Response-Extension = SP string SP
+                     "(" string *(SP string) ")"
+
+   Namespace-Response = "NAMESPACE" SP Namespace
+                        SP Namespace SP Namespace
+         ;; This response is currently only allowed
+         ;; if the IMAP server supports [NAMESPACE].
+         ;; The first Namespace is the Personal Namespace(s)
+         ;; The second Namespace is the Other Users' Namespace(s)
+         ;; The third Namespace is the Shared Namespace(s)
+
+   rename          = "RENAME" SP mailbox SP mailbox
+                     [rename-params]
+                     ;; Use of INBOX as a destination gives
+                     ;; a NO error, unless rename-params
+                     ;; is not empty.
+
+   rename-params     = SP "(" rename-param *( SP rename-param) ")"
+
+   rename-param      = rename-param-name [SP rename-param-value]
+
+   rename-param-name = tagged-ext-label
+
+   rename-param-value= tagged-ext-val
+                     ;; This non-terminal shows recommended syntax
+                     ;; for future extensions.
+
+
+   response-data   = "*" SP response-payload CRLF
+
+   response-payload= resp-cond-state / resp-cond-bye /
+                     mailbox-data / message-data / capability-data
+
+   search          = "SEARCH" [search-return-opts]
+                     SP search-program
+
+   search-correlator  = SP "(" "TAG" SP tag-string ")"
+
+
+
+Melnikov & Daboo            Standards Track                    [Page 11]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+   search-program     = ["CHARSET" SP charset SP]
+                        search-key *(SP search-key)
+                        ;; CHARSET argument to SEARCH MUST be
+                        ;; registered with IANA.
+
+   search-return-data = search-modifier-name SP search-return-value
+                        ;; Note that not every SEARCH return option
+                        ;; is required to have the corresponding
+                        ;; ESEARCH return data.
+
+   search-return-opts = SP "RETURN" SP "(" [search-return-opt
+                        *(SP search-return-opt)] ")"
+
+   search-return-opt = search-modifier-name [SP search-mod-params]
+
+   search-return-value = tagged-ext-val
+                        ;; Data for the returned search option.
+                        ;; A single "nz-number"/"number" value
+                        ;; can be returned as an atom (i.e., without
+                        ;; quoting).  A sequence-set can be returned
+                        ;; as an atom as well.
+
+   search-modifier-name = tagged-ext-label
+
+   search-mod-params = tagged-ext-val
+                     ;; This non-terminal shows recommended syntax
+                     ;; for future extensions.
+
+
+   select          = "SELECT" SP mailbox [select-params]
+                     ;; modifies the original IMAP SELECT command to
+                     ;; accept optional parameters
+
+   select-params   = SP "(" select-param *(SP select-param) ")"
+
+   select-param    = select-param-name [SP select-param-value]
+                     ;; a parameter to SELECT may contain one or
+                     ;; more atoms and/or strings and/or lists.
+
+   select-param-name= tagged-ext-label
+
+   select-param-value= tagged-ext-val
+                     ;; This non-terminal shows recommended syntax
+                     ;; for future extensions.
+
+
+   status-att-list = status-att-val *(SP status-att-val)
+                     ;; Redefines status-att-list from RFC 3501.
+
+
+
+Melnikov & Daboo            Standards Track                    [Page 12]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+                     ;; status-att-val is defined in RFC 3501 errata
+
+   status-att-val  = ("MESSAGES" SP number) /
+                     ("RECENT" SP number) /
+                     ("UIDNEXT" SP nz-number) /
+                     ("UIDVALIDITY" SP nz-number) /
+                     ("UNSEEN" SP number)
+                     ;; Extensions to the STATUS responses
+                     ;; should extend this production.
+                     ;; Extensions should use the generic
+                     ;; syntax defined by tagged-ext.
+
+   store           = "STORE" SP sequence-set [store-modifiers]
+                     SP store-att-flags
+                     ;; extend [IMAP4] STORE command syntax
+                     ;; to allow for optional store-modifiers
+
+   store-modifiers =  SP "(" store-modifier *(SP store-modifier)
+                       ")"
+
+   store-modifier  = store-modifier-name [SP store-modif-params]
+
+   store-modif-params = tagged-ext-val
+                     ;; This non-terminal shows recommended syntax
+                     ;; for future extensions.
+
+   store-modifier-name = tagged-ext-label
+
+   tag-string         = string
+                        ;; tag of the command that caused
+                        ;; the ESEARCH response, sent as
+                        ;; a string.
+
+   tagged-ext          = tagged-ext-label SP tagged-ext-val
+                          ;; recommended overarching syntax for
+                          ;; extensions
+
+   tagged-ext-label    = tagged-label-fchar *tagged-label-char
+                         ;; Is a valid RFC 3501 "atom".
+
+   tagged-label-fchar  = ALPHA / "-" / "_" / "."
+
+   tagged-label-char   = tagged-label-fchar / DIGIT / ":"
+
+
+
+
+
+
+
+
+Melnikov & Daboo            Standards Track                    [Page 13]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+   tagged-ext-comp     = astring /
+                         tagged-ext-comp *(SP tagged-ext-comp) /
+                         "(" tagged-ext-comp ")"
+                          ;; Extensions that follow this general
+                          ;; syntax should use nstring instead of
+                          ;; astring when appropriate in the context
+                          ;; of the extension.
+                          ;; Note that a message set or a "number"
+                          ;; can always be represented as an "atom".
+                          ;; An URL should be represented as
+                          ;; a "quoted" string.
+
+   tagged-ext-simple   = sequence-set / number
+
+   tagged-ext-val      = tagged-ext-simple /
+                         "(" [tagged-ext-comp] ")"
+
+4.  Security Considerations
+
+   This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.
+   The updated documents must be consulted for security considerations
+   for the extensions that they define.
+
+   As a protocol gets more complex, parser bugs become more common
+   including buffer overflow, denial of service, and other common
+   security coding errors.  To the extent that this document makes the
+   parser more complex, it makes this situation worse.  To the extent
+   that this document makes the parser more consistent and thus simpler,
+   the situation is improved.  The impact will depend on how many
+   deployed IMAP extensions are consistent with this document.
+   Implementers are encouraged to take care of these issues when
+   extending existing implementations.  Future IMAP extensions should
+   strive for consistency and simplicity to the greatest extent
+   possible.
+
+   Extensions to IMAP commands that are permitted in NOT AUTHENTICATED
+   state are more sensitive to these security issues due to the larger
+   possible attacker community prior to authentication, and the fact
+   that some IMAP servers run with elevated privileges in that state.
+   This document does not extend any commands permitted in NOT
+   AUTHENTICATED state.  Future IMAP extensions to commands permitted in
+   NOT AUTHENTICATED state should favor simplicity over consistency or
+   extensibility.
+
+
+
+
+
+
+
+
+Melnikov & Daboo            Standards Track                    [Page 14]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+5.  Normative References
+
+   [KEYWORDS]    Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [IMAP4]       Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
+                 VERSION 4rev1", RFC 3501, March 2003.
+
+   [ABNF]        Crocker, D., Ed., and P. Overell, "Augmented BNF for
+                 Syntax Specifications: ABNF", RFC 4234, October 2005.
+
+   [CHARSET]     Freed, N. and J. Postel, "IANA Charset Registration
+                 Procedures", BCP 19, RFC 2978, October 2000.
+
+   [MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) -
+                 MULTIAPPEND Extension", RFC 3502, March 2003.
+
+   [NAMESPACE]   Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
+                 May 1998.
+
+   [LITERAL+]    Myers, J., "IMAP4 non-synchronizing literals", RFC
+                 2088, January 1997.
+
+   [BINARY]      Nerenberg, L., "IMAP4 Binary Content Extension", RFC
+                 3516, April 2003.
+
+6.  Acknowledgements
+
+   This documents is based on ideas proposed by Pete Resnick, Mark
+   Crispin, Ken Murchison, Philip Guenther, Randall Gellens, and Lyndon
+   Nerenberg.
+
+   However, all errors and omissions must be attributed to the authors
+   of the document.
+
+   Thanks to Philip Guenther, Dave Cridland, Mark Crispin, Chris Newman,
+   Elwyn Davies, and Barry Leiba for comments and corrections.
+
+   literal8 syntax was taken from RFC 3516.
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov & Daboo            Standards Track                    [Page 15]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+Authors' Addresses
+
+   Alexey Melnikov
+   Isode Limited
+   5 Castle Business Village
+   36 Station Road
+   Hampton, Middlesex, TW12 2BX
+   UK
+
+   EMail: Alexey.Melnikov@isode.com
+
+
+   Cyrus Daboo
+
+   EMail: cyrus@daboo.name
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov & Daboo            Standards Track                    [Page 16]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Melnikov & Daboo            Standards Track                    [Page 17]
+
diff --git a/docs/rfcs/rfc4467.txt b/docs/rfcs/rfc4467.txt
new file mode 100644
index 0000000..83b6516
--- /dev/null
+++ b/docs/rfcs/rfc4467.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                         M. Crispin
+Request for Comments: 4467                      University of Washington
+Updates: 3501                                                   May 2006
+Category: Standards Track
+
+
+      Internet Message Access Protocol (IMAP) - URLAUTH Extension
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes the URLAUTH extension to the Internet Message
+   Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL)
+   (RFC 2192).  This extension provides a means by which an IMAP client
+   can use URLs carrying authorization to access limited message data on
+   the IMAP server.
+
+   An IMAP server that supports this extension indicates this with a
+   capability name of "URLAUTH".
+
+1.  Introduction
+
+   In [IMAPURL], a URL of the form imap://fred@example.com/INBOX/;uid=20
+   requires authorization as userid "fred".  However, [IMAPURL] implies
+   that it only supports authentication and confuses the concepts of
+   authentication and authorization.
+
+   The URLAUTH extension defines an authorization mechanism for IMAP
+   URLs to replace [IMAPURL]'s authentication-only mechanism.  URLAUTH
+   conveys authorization in the URL string itself and reuses a portion
+   of the syntax of the [IMAPURL] authentication mechanism to convey the
+   authorization identity (which also defines the default namespace in
+   [IMAP]).
+
+   The URLAUTH extension provides a means by which an authorized user of
+   an IMAP server can create URLAUTH-authorized IMAP URLs.  A URLAUTH-
+   authorized URL conveys authorization (not authentication) to the data
+
+
+
+Crispin                     Standards Track                     [Page 1]
+
+RFC 4467                IMAP - URLAUTH Extension                May 2006
+
+
+   addressed by that URL.  This URL can be used in another IMAP session
+   to access specific content on the IMAP server, without otherwise
+   providing authorization to any other data (such as other data in the
+   mailbox specified in the URL) owned by the authorizing user.
+
+   Conceptually, a URLAUTH-authorized URL can be thought of as a "pawn
+   ticket" that carries no authentication information and can be
+   redeemed by whomever presents it.  However, unlike a pawn ticket,
+   URLAUTH has optional mechanisms to restrict the usage of a URLAUTH-
+   authorized URL.  Using these mechanisms, URLAUTH-authorized URLs can
+   be usable by:
+
+      . anonymous (the "pawn ticket" model)
+      . authenticated users only
+      . a specific authenticated user only
+      . message submission acting on behalf of a specific user only
+
+   There is also a mechanism for expiration.
+
+   A URLAUTH-authorized URL can be used in the argument to the BURL
+   command in message composition, as described in [BURL], for such
+   purposes as allowing a client (with limited memory or other
+   resources) to submit a message forward or to resend from an IMAP
+   mailbox without requiring the client to fetch that message data.
+
+   The URLAUTH is generated using an authorization mechanism name and an
+   authorization token, which is generated using a secret mailbox access
+   key.  An IMAP client can request that the server generate and assign
+   a new mailbox access key (thus effectively revoking all current URLs
+   using URLAUTH with the old mailbox access key) but cannot set the
+   mailbox access key to a key of its own choosing.
+
+1.1.  Conventions Used in this Document
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+   in this document are to be interpreted as defined in [KEYWORDS].
+
+   The formal syntax uses the Augmented Backus-Naur Form (ABNF) notation
+   including the core rules defined in Appendix A of [ABNF].
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server, respectively.  If a single "C:" or "S:" label applies to
+   multiple lines, then the line breaks between those lines are for
+   editorial clarity only and are not part of the actual protocol
+   exchange.
+
+
+
+
+
+
+Crispin                     Standards Track                     [Page 2]
+
+RFC 4467                IMAP - URLAUTH Extension                May 2006
+
+
+2.  Concepts
+
+2.1.  URLAUTH
+
+   The URLAUTH is a component, appended at the end of a URL, that
+   conveys authorization to access the data addressed by that URL.  It
+   contains an authorized access identifier, an authorization mechanism
+   name, and an authorization token.  The authorization token is
+   generated from the URL, the authorized access identifier, the
+   authorization mechanism name, and a mailbox access key.
+
+2.2.  Mailbox Access Key
+
+   The mailbox access key is a random string with at least 128 bits of
+   entropy.  It is generated by software (not by the human user) and
+   MUST be unpredictable.
+
+   Each user has a table of mailboxes and an associated mailbox access
+   key for each mailbox.  Consequently, the mailbox access key is per-
+   user and per-mailbox.  In other words, two users sharing the same
+   mailbox each have a different mailbox access key for that mailbox,
+   and each mailbox accessed by a single user also has a different
+   mailbox access key.
+
+2.3.  Authorized Access Identifier
+
+   The authorized access identifier restricts use of the URLAUTH
+   authorized URL to certain users authorized on the server, as
+   described in section 3.
+
+2.4.  Authorization Mechanism
+
+   The authorization mechanism is the algorithm by which the URLAUTH is
+   generated and subsequently verified, using the mailbox access key.
+
+2.4.1.  INTERNAL Authorization Mechanism
+
+   This specification defines the INTERNAL mechanism, which uses a token
+   generation algorithm of the server's choosing and does not involve
+   disclosure of the mailbox access key to the client.
+
+      Note: The token generation algorithm chosen by the server
+      implementation should be modern and reasonably secure.  At the
+      time of the writing of this document, an [HMAC] such as HMAC-SHA1
+      is recommended.
+
+
+
+
+
+
+Crispin                     Standards Track                     [Page 3]
+
+RFC 4467                IMAP - URLAUTH Extension                May 2006
+
+
+      If it becomes necessary to change the token generation algorithm
+      of the INTERNAL mechanism (e.g., because an attack against the
+      current algorithm has been discovered), all currently existing
+      URLAUTH-authorized URLs are invalidated by the change in
+      algorithm.  Since this would be an unpleasant surprise to
+      applications that depend upon the validity of a URLAUTH-authorized
+      URL, and there is no good way to do a bulk update of existing
+      deployed URLs, it is best to avoid this situation by using a
+      secure algorithm as opposed to one that is "good enough".
+
+      Server implementations SHOULD consider the possibility of changing
+      the algorithm.  In some cases, it may be desirable to implement
+      the change of algorithm in a way that newly-generated tokens use
+      the new algorithm, but that for a limited period of time tokens
+      using either the new or old algorithm can be validated.
+      Consequently, the server SHOULD incorporate some means of
+      identifying the token generation algorithm within the token.
+
+   Although this specification is extensible for other mechanisms, none
+   are defined in this document.  In addition to the mechanism name
+   itself, other mechanisms may have mechanism-specific data, which is
+   to be interpreted according to the definition of that mechanism.
+
+2.5.  Authorization Token
+
+   The authorization token is a deterministic string of at least 128
+   bits that an entity with knowledge of the secret mailbox access key
+   and URL authorization mechanism can use to verify the URL.
+
+3.  IMAP URL Extensions
+
+   [IMAPURL] is extended by allowing the addition of
+   ";EXPIRE=<datetime>" and ";URLAUTH=<access>:<mech>:<token>" to IMAP
+   URLs that refer to a specific message or message parts.
+
+   The URLAUTH is comprised of ";URLAUTH=<access>:<mech>:<token>" and
+   MUST be at the end of the URL.
+
+   URLAUTH does not apply to, and MUST NOT be used with, any IMAP URL
+   that refers to an entire IMAP server, a list of mailboxes, an entire
+   IMAP mailbox, or IMAP search results.
+
+   When ";EXPIRE=<datetime>" is used, this indicates the latest date and
+   time that the URL is valid.  After that date and time, the URL has
+   expired, and server implementations MUST reject the URL.  If
+   ";EXPIRE=<datetime>" is not used, the URL has no expiration, but
+   still can be revoked as discussed below.
+
+
+
+
+Crispin                     Standards Track                     [Page 4]
+
+RFC 4467                IMAP - URLAUTH Extension                May 2006
+
+
+   The URLAUTH takes the form ";URLAUTH=<access>:<mech>:<token>".  It is
+   composed of three parts.  The <access> portion provides the
+   authorized access identifiers, which may constrain the operations and
+   users that are permitted to use this URL.  The <mech> portion
+   provides the authorization mechanism used by the IMAP server to
+   generate the authorization token that follows.  The <token> portion
+   provides the authorization token.
+
+   The "submit+" access identifier prefix, followed by a userid,
+   indicates that only a userid authorized as a message submission
+   entity on behalf of the specified userid is permitted to use this
+   URL.  The IMAP server does not validate the specified userid but does
+   validate that the IMAP session has an authorization identity that is
+   authorized as a message submission entity.  The authorized message
+   submission entity MUST validate the userid prior to contacting the
+   IMAP server.
+
+   The "user+" access identifier prefix, followed by a userid, indicates
+   that use of this URL is limited to IMAP sessions that are logged in
+   as the specified userid (that is, have authorization identity as that
+   userid).
+
+      Note: If a SASL mechanism that provides both authorization and
+      authentication identifiers is used to authenticate to the IMAP
+      server, the "user+" access identifier MUST match the authorization
+      identifier.
+
+   The "authuser" access identifier indicates that use of this URL is
+   limited to IMAP sessions that are logged in as an authorized user
+   (that is, have authorization identity as an authorized user) of that
+   IMAP server.  Use of this URL is prohibited to anonymous IMAP
+   sessions.
+
+   The "anonymous" access identifier indicates that use of this URL is
+   not restricted by session authorization identity; that is, any IMAP
+   session in authenticated or selected state (as defined in [IMAP]),
+   including anonymous sessions, may issue a URLFETCH using this URL.
+
+   The authorization token is represented as an ASCII-encoded
+   hexadecimal string, which is used to authorize the URL.  The length
+   and the calculation of the authorization token depends upon the
+   mechanism used; but, in all cases, the authorization token is at
+   least 128 bits (and therefore at least 32 hexadecimal digits).
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                     [Page 5]
+
+RFC 4467                IMAP - URLAUTH Extension                May 2006
+
+
+4.  Discussion of URLAUTH Authorization Issues
+
+   In [IMAPURL], the userid before the "@" in the URL has two purposes:
+
+      1) It provides context for user-specific mailbox paths such as
+         "INBOX".
+
+      2) It specifies that resolution of the URL requires logging in as
+         that user and limits use of that URL to only that user.
+
+   An obvious limitation of using the same field for both purposes is
+   that the URL can only be resolved by the mailbox owner.
+
+   URLAUTH overrides the second purpose of the userid in the IMAP URL
+   and by default permits the URL to be resolved by any user permitted
+   by the access identifier.
+
+   The "user+<userid>" access identifier limits resolution of that URL
+   to a particular userid, whereas the "submit+<userid>" access
+   identifier is more general and simply requires that the session be
+   authorized by a user that has been granted a "submit" role within the
+   authentication system.  Use of either of these access identifiers
+   makes it impossible for an attacker, spying on the session, to use
+   the same URL, either directly or by submission to a message
+   submission entity.
+
+   The "authuser" and "anonymous" access identifiers do not have this
+   level of protection and should be used with caution.  These access
+   identifiers are primarily useful for public export of data from an
+   IMAP server, without requiring that it be copied to a web or
+   anonymous FTP server.  Refer to the Security Considerations for more
+   details.
+
+5.  Generation of URLAUTH-Authorized URLs
+
+   A URLAUTH-authorized URL is generated from an initial URL as follows:
+
+   An initial URL is built, ending with ";URLAUTH=<access>" but without
+   the ":<mech>:<token>" components.  An authorization mechanism is
+   selected and used to calculate the authorization token, with the
+   initial URL as the data and a secret known to the IMAP server as the
+   key.  The URLAUTH-authorized URL is generated by taking the initial
+   URL and appending ":", the URL authorization mechanism name, ":", and
+   the ASCII-encoded hexadecimal representation of the authorization
+   token.
+
+
+
+
+
+
+Crispin                     Standards Track                     [Page 6]
+
+RFC 4467                IMAP - URLAUTH Extension                May 2006
+
+
+      Note: ASCII-encoded hexadecimal is used instead of BASE64 because
+      a BASE64 representation may have "=" padding characters, which
+      would be problematic in a URL.
+
+   In the INTERNAL mechanism, the mailbox access key for that mailbox is
+   the secret known to the IMAP server, and a server-selected algorithm
+   is used as described in section 2.4.1.
+
+6.  Validation of URLAUTH-authorized URLs
+
+   A URLAUTH-authorized URL is validated as follows:
+
+   The URL is split at the ":" that separates "<access>" from
+   "<mech>:<token>" in the ";URLAUTH=<access>:<mech>:<token>" portion of
+   the URL.  The "<mech>:<token>" portion is first parsed and saved as
+   the authorization mechanism and the authorization token.  The URL is
+   truncated, discarding the ":" described above, to create a "rump URL"
+   (the URL minus the ":" and the "<mech>:<token>" portion).  The rump
+   URL is then analyzed to identify the mailbox.
+
+   If the mailbox cannot be identified, an authorization token is
+   calculated on the rump URL, using random "plausible" keys (selected
+   by the server) as needed, before returning a validation failure.
+   This prevents timing attacks aimed at identifying mailbox names.
+
+   If the mailbox can be identified, the authorization token is
+   calculated on the rump URL and a secret known to the IMAP server
+   using the given URL authorization mechanism.  Validation is
+   successful if, and only if, the calculated authorization token for
+   that mechanism matches the authorization token supplied in
+   ";URLAUTH=<access>:<mech>:<token>".
+
+   Removal of the ":<mech>:<token>" portion of the URL MUST be the only
+   operation applied to the URLAUTH-authorized URL to get the rump URL.
+   In particular, URL percent escape decoding and case-folding
+   (including to the domain part of the URL) MUST NOT occur.
+
+   In the INTERNAL mechanism, the mailbox access key for that mailbox is
+   used as the secret known to the IMAP server, and the same server-
+   selected algorithm used for generating URLs is used to calculate the
+   authorization token for verification.
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                     [Page 7]
+
+RFC 4467                IMAP - URLAUTH Extension                May 2006
+
+
+7.  Additional Commands
+
+   These commands are extensions to the [IMAP] base protocol.
+
+   The section headings of these commands are intended to correspond
+   with where they would be located in the base protocol document if
+   they were part of that document.
+
+BASE.6.3.RESETKEY.  RESETKEY Command
+
+   Arguments:  optional mailbox name
+               optional mechanism name(s)
+
+   Responses:  none other than in result
+
+   Result:     OK - RESETKEY completed, URLMECH containing new data
+               NO - RESETKEY error: can't change key of that mailbox
+               BAD - command unknown or arguments invalid
+
+   The RESETKEY command has two forms.
+
+   The first form accepts a mailbox name as an argument and generates a
+   new mailbox access key for the given mailbox in the user's mailbox
+   access key table, replacing any previous mailbox access key (and
+   revoking any URLs that were authorized with a URLAUTH using that key)
+   in that table.  By default, the mailbox access key is generated for
+   the INTERNAL mechanism; other mechanisms can be specified with the
+   optional mechanism argument.
+
+   The second form, with no arguments, removes all mailbox access keys
+   in the user's mailbox access key table, revoking all URLs currently
+   authorized using URLAUTH by the user.
+
+   Any current IMAP session logged in as the user that has the mailbox
+   selected will receive an untagged OK response with the URLMECH status
+   response code (see section BASE.7.1.URLMECH for more details about
+   the URLMECH status response code).
+
+   Example:
+
+      C: a31 RESETKEY
+      S: a31 OK All keys removed
+      C: a32 RESETKEY INBOX
+      S: a32 OK [URLMECH INTERNAL] mechs
+      C: a33 RESETKEY INBOX XSAMPLE
+      S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done
+
+
+
+
+
+Crispin                     Standards Track                     [Page 8]
+
+RFC 4467                IMAP - URLAUTH Extension                May 2006
+
+
+BASE.6.3.GENURLAUTH.  GENURLAUTH Command
+
+      Argument:   one or more URL/mechanism pairs
+
+      Response:   untagged response: GENURLAUTH
+
+      Result:     OK - GENURLAUTH completed
+                  NO - GENURLAUTH error: can't generate a URLAUTH
+                  BAD - command unknown or arguments invalid
+
+   The GENURLAUTH command requests that the server generate a URLAUTH-
+   authorized URL for each of the given URLs using the given URL
+   authorization mechanism.
+
+   The server MUST validate each supplied URL as follows:
+
+      (1) The mailbox component of the URL MUST refer to an existing
+          mailbox.
+
+      (2) The server component of the URL MUST contain a valid userid
+          that identifies the owner of the mailbox access key table that
+          will be used to generate the URLAUTH-authorized URL.  As a
+          consequence, the iserver rule of [IMAPURL] is modified so that
+          iuserauth is mandatory.
+
+             Note: the server component of the URL is generally the
+             logged in userid and server.  If not, then the logged in
+             userid and server MUST have owner-type access to the
+             mailbox access key table owned by the userid and server
+             indicated by the server component of the URL.
+
+      (3) There is a valid access identifier that, in the case of
+          "submit+" and "user+", will contain a valid userid.  This
+          userid is not necessarily the same as the owner userid
+          described in (2).
+
+      (4) The server MAY also verify that the iuid and/or isection
+          components (if present) are valid.
+
+   If any of the above checks fail, the server MUST return a tagged BAD
+   response with the following exception.  If an invalid userid is
+   supplied as the mailbox access key owner and/or as part of the access
+   identifier, the server MAY issue a tagged OK response with a
+   generated mailbox key that always fails validation when used with a
+   URLFETCH command.  This exception prevents an attacker from
+   validating userids.
+
+
+
+
+
+Crispin                     Standards Track                     [Page 9]
+
+RFC 4467                IMAP - URLAUTH Extension                May 2006
+
+
+   If there is currently no mailbox access key for the given mailbox in
+   the owner's mailbox access key table, one is automatically generated.
+   That is, it is not necessary to use RESETKEY prior to first-time use
+   of GENURLAUTH.
+
+   If the command is successful, a GENURLAUTH response code is returned
+   listing the requested URLs as URLAUTH-authorized URLs.
+
+   Examples:
+
+      C: a775 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
+         ;section=1.2" INTERNAL
+      S: a775 BAD missing access identifier in supplied URL
+      C: a776 GENURLAUTH "imap://example.com/Shared/;uid=20/
+         ;section=1.2;urlauth=submit+fred" INTERNAL
+      S: a776 BAD missing owner username in supplied URL
+      C: a777 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
+         ;section=1.2;urlauth=submit+fred" INTERNAL
+      S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
+         ;urlauth=submit+fred:internal:91354a473744909de610943775f92038"
+      S: a777 OK GENURLAUTH completed
+
+BASE.6.3.URLFETCH.  URLFETCH Command
+
+      Argument:   one or more URLs
+
+      Response:   untagged response: URLFETCH
+
+      Result:     OK - urlfetch completed
+                  NO - urlfetch failed due to server internal error
+                  BAD - command unknown or arguments invalid
+
+   The URLFETCH command requests that the server return the text data
+   associated with the specified IMAP URLs, as described in [IMAPURL]
+   and extended by this document.  The data is returned for all
+   validated URLs, regardless of whether or not the session would
+   otherwise be able to access the mailbox containing that data via
+   SELECT or EXAMINE.
+
+      Note: This command does not require that the URL refer to the
+      selected mailbox; nor does it require that any mailbox be
+      selected.  It also does not in any way interfere with any selected
+      mailbox.
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 10]
+
+RFC 4467                IMAP - URLAUTH Extension                May 2006
+
+
+   The URLFETCH command effectively executes with the access of the
+   userid in the server component of the URL (which is generally the
+   userid that issued the GENURLAUTH).  By itself, the URLAUTH does NOT
+   grant access to the data; once validated, it grants whatever access
+   to the data is held by the userid in the server component of the URL.
+   That access may have changed since the GENURLAUTH was done.
+
+   The URLFETCH command MUST return an untagged URLFETCH response and a
+   tagged OK response to any URLFETCH command that is syntactically
+   valid.  A NO response indicates a server internal failure that may be
+   resolved on later retry.
+
+      Note: The possibility of a NO response is to accommodate
+      implementations that would otherwise have to issue an untagged BYE
+      with a fatal error due to an inability to respond to a valid
+      request.  In an ideal world, a server SHOULD NOT issue a NO
+      response.
+
+   The server MUST return NIL for any IMAP URL that references an entire
+   IMAP server, a list of mailboxes, an entire IMAP mailbox, or IMAP
+   search results.
+
+   Example:
+
+      Note: For clarity, this example uses the LOGIN command, which
+      SHOULD NOT be used over a non-encrypted communication path.
+
+      This example is of a submit server, obtaining a message segment
+      for a message that it has already validated was submitted by
+      "fred".
+
+      S: * OK [CAPABILITY IMAP4REV1 URLAUTH] example.com IMAP server
+      C: a001 LOGIN submitserver secret
+      S: a001 OK submitserver logged in
+      C: a002 URLFETCH "imap://joe@example.com/INBOX/;uid=20/
+         ;section=1.2;urlauth=submit+fred:internal
+         :91354a473744909de610943775f92038"
+      S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
+         ;urlauth=submit+fred:internal
+         :91354a473744909de610943775f92038" {28}
+      S: Si vis pacem, para bellum.
+      S:
+      S: a002 OK URLFETCH completed
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 11]
+
+RFC 4467                IMAP - URLAUTH Extension                May 2006
+
+
+8.  Additional Responses
+
+   These responses are extensions to the [IMAP] base protocol.
+
+   The section headings of these responses are intended to correspond
+   with where they would be located in the base protocol document if
+   they were part of that document.
+
+BASE.7.1.URLMECH.  URLMECH Status Response Code
+
+   The URLMECH status response code is followed by a list of URL
+   authorization mechanism names.  Mechanism names other than INTERNAL
+   may be appended with an "=" and BASE64-encoded form of mechanism-
+   specific data.
+
+   This status response code is returned in an untagged OK response in
+   response to a RESETKEY, SELECT, or EXAMINE command.  In the case of
+   the RESETKEY command, this status response code can be sent in the
+   tagged OK response instead of requiring a separate untagged OK
+   response.
+
+   Example:
+
+      C: a33 RESETKEY INBOX XSAMPLE
+      S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done
+
+   In this example, the server supports the INTERNAL mechanism and an
+   experimental mechanism called XSAMPLE, which also holds some
+   mechanism-specific data (the name "XSAMPLE" is for illustrative
+   purposes only).
+
+BASE.7.4.GENURLAUTH.   GENURLAUTH Response
+
+   Contents:   One or more URLs
+
+   The GENURLAUTH response returns the URLAUTH-authorized URL(s)
+   requested by a GENURLAUTH command.
+
+   Example:
+
+      C: a777 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
+         ;section=1.2;urlauth=submit+fred" INTERNAL
+      S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
+         ;urlauth=submit+fred:internal:91354a473744909de610943775f92038"
+      S: a777 OK GENURLAUTH completed
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 12]
+
+RFC 4467                IMAP - URLAUTH Extension                May 2006
+
+
+BASE.7.4.URLFETCH.  URLFETCH Response
+
+   Contents:   One or more URL/nstring pairs
+
+   The URLFETCH response returns the message text data associated with
+   one or more IMAP URLs, as described in [IMAPURL] and extended by this
+   document.  This response occurs as the result of a URLFETCH command.
+
+   The returned data string is NIL if the URL is invalid for any reason
+   (including validation failure).  If the URL is valid, but the IMAP
+   fetch of the body part returned NIL (this should not happen), the
+   returned data string should be the empty string ("") and not NIL.
+
+      Note: This command does not require that the URL refer to the
+      selected mailbox; nor does it require that any mailbox be
+      selected.  It also does not in any way interfere with any selected
+      mailbox.
+
+   Example:
+
+      C: a002 URLFETCH "imap://joe@example.com/INBOX/;uid=20/
+         ;section=1.2;urlauth=submit+fred:internal
+         :91354a473744909de610943775f92038"
+      S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
+         ;urlauth=submit+fred:internal
+         :91354a473744909de610943775f92038" {28}
+      S: Si vis pacem, para bellum.
+      S:
+      S: a002 OK URLFETCH completed
+
+9.  Formal Syntax
+
+   The following syntax specification uses the Augmented Backus-Naur
+   Form (ABNF) notation as specified in [ABNF].
+
+   The following modifications are made to the Formal Syntax in [IMAP]:
+
+resetkey        = "RESETKEY" [SP mailbox *(SP mechanism)]
+
+capability      =/ "URLAUTH"
+
+command-auth    =/ resetkey / genurlauth / urlfetch
+
+resp-text-code  =/ "URLMECH" SP "INTERNAL" *(SP mechanism ["=" base64])
+
+genurlauth      = "GENURLAUTH" 1*(SP url-rump SP mechanism)
+
+genurlauth-data = "*" SP "GENURLAUTH" 1*(SP url-full)
+
+
+
+Crispin                     Standards Track                    [Page 13]
+
+RFC 4467                IMAP - URLAUTH Extension                May 2006
+
+
+url-full        = astring
+                     ; contains authimapurlfull as defined below
+
+url-rump        = astring
+                     ; contains authimapurlrump as defined below
+
+urlfetch        = "URLFETCH" 1*(SP url-full)
+
+urlfetch-data   = "*" SP "URLFETCH" 1*(SP url-full SP nstring)
+
+   The following extensions are made to the Formal Syntax in [IMAPURL]:
+
+authimapurl     = "imap://" enc-user [iauth] "@" hostport "/"
+                     imessagepart
+                     ; replaces "imapurl" and "iserver" rules for
+                     ; URLAUTH authorized URLs
+
+authimapurlfull = authimapurl iurlauth
+
+authimapurlrump = authimapurl iurlauth-rump
+
+enc-urlauth     = 32*HEXDIG
+
+enc-user        = 1*achar
+                     ; same as "enc_user" in RFC 2192
+
+iurlauth        = iurlauth-rump ":" mechanism ":" enc-urlauth
+
+iurlauth-rump   = [expire] ";URLAUTH=" access
+
+access          = ("submit+" enc-user) / ("user+" enc-user) /
+                    "authuser" / "anonymous"
+
+expire          = ";EXPIRE=" date-time
+                      ; date-time defined in [DATETIME]
+
+mechanism       = "INTERNAL" / 1*(ALPHA / DIGIT / "-" / ".")
+                     ; case-insensitive
+                     ; new mechanisms MUST be registered with IANA
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 14]
+
+RFC 4467                IMAP - URLAUTH Extension                May 2006
+
+
+10.  Security Considerations
+
+   Security considerations are discussed throughout this memo.
+
+   The mailbox access key SHOULD have at least 128 bits of entropy
+   (refer to [RANDOM] for more details) and MUST be unpredictable.
+
+   The server implementation of the INTERNAL mechanism SHOULD consider
+   the possibility of needing to change the token generation algorithm,
+   and SHOULD incorporate some means of identifying the token generation
+   algorithm within the token.
+
+   The URLMECH status response code may expose sensitive data in the
+   mechanism-specific data for mechanisms other than INTERNAL.  A server
+   implementation MUST implement a configuration that will not return a
+   URLMECH status response code unless some mechanism is provided that
+   protects the session from snooping, such as a TLS or SASL security
+   layer that provides confidentiality protection.
+
+   The calculation of an authorization token with a "plausible" key if
+   the mailbox can not be identified is necessary to avoid attacks in
+   which the server is probed to see if a particular mailbox exists on
+   the server by measuring the amount of time taken to reject a known
+   bad name versus some other name.
+
+   To protect against a computational denial-of-service attack, a server
+   MAY impose progressively longer delays on multiple URL requests that
+   fail validation.
+
+   The decision to use the "authuser" access identifier should be made
+   with caution.  An "authuser" access identifier can be used by any
+   authorized user of the IMAP server; therefore, use of this access
+   identifier should be limited to content that may be disclosed to any
+   authorized user of the IMAP server.
+
+   The decision to use the "anonymous" access identifier should be made
+   with extreme caution.  An "anonymous" access identifier can be used
+   by anyone; therefore, use of this access identifier should be limited
+   to content that may be disclosed to anyone.  Many IMAP servers do not
+   permit anonymous access; in this case, the "anonymous" access
+   identifier is equivalent to "authuser", but this MUST NOT be relied
+   upon.
+
+   Although this specification does not prohibit the theoretical
+   capability to generate a URL with a server component other than the
+   logged in userid and server, this capability should only be provided
+
+
+
+
+
+Crispin                     Standards Track                    [Page 15]
+
+RFC 4467                IMAP - URLAUTH Extension                May 2006
+
+
+   when the logged in userid/server has been authorized as equivalent to
+   the server component userid/server, or otherwise has access to that
+   userid/server mailbox access key table.
+
+11.  IANA Considerations
+
+   This document constitutes registration of the URLAUTH capability in
+   the imap4-capabilities registry.
+
+   URLAUTH authorization mechanisms are registered by publishing a
+   standards track or IESG-approved experimental RFC.  The registry is
+   currently located at:
+
+http://www.iana.org/assignments/urlauth-authorization-mechanism-registry
+
+   This registry is case-insensitive.
+
+   This document constitutes registration of the INTERNAL URLAUTH
+   authorization mechanism.
+
+   IMAP URLAUTH Authorization Mechanism Registry
+
+      Mechanism Name           Reference
+      --------------           ---------
+      INTERNAL                 [RFC4467]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 16]
+
+RFC 4467                IMAP - URLAUTH Extension                May 2006
+
+
+12.  Normative References
+
+   [ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 4234, October 2005.
+
+   [BURL]     Newman, C., "Message Submission BURL Extension", RFC 4468,
+              May 2006.
+
+   [DATETIME] Klyne, G. and C. Newman, "Date and Time on the Internet:
+              Timestamps", RFC 3339, July 2002.
+
+   [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
+              4rev1", RFC 3501, March 2003.
+
+   [IMAPURL]  Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
+
+   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+13.  Informative References
+
+   [HMAC]     Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104, February
+              1997.
+
+   [RANDOM]   Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+              "Randomness Requirements for Security", BCP 106, RFC 4086,
+              June 2005.
+
+Author's Address
+
+   Mark R. Crispin
+   Networks and Distributed Computing
+   University of Washington
+   4545 15th Avenue NE
+   Seattle, WA  98105-4527
+
+   Phone: (206) 543-5762
+   EMail: MRC@CAC.Washington.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 17]
+
+RFC 4467                IMAP - URLAUTH Extension                May 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 18]
+
diff --git a/docs/rfcs/rfc4469.txt b/docs/rfcs/rfc4469.txt
new file mode 100644
index 0000000..da36551
--- /dev/null
+++ b/docs/rfcs/rfc4469.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                         P. Resnick
+Request for Comments: 4469                         QUALCOMM Incorporated
+Updates: 3501, 3502                                           April 2006
+Category: Standards Track
+
+
+       Internet Message Access Protocol (IMAP) CATENATE Extension
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The CATENATE extension to the Internet Message Access Protocol (IMAP)
+   extends the APPEND command to allow clients to create messages on the
+   IMAP server that may contain a combination of new data along with
+   parts of (or entire) messages already on the server.  Using this
+   extension, the client can catenate parts of an already existing
+   message onto a new message without having to first download the data
+   and then upload it back to the server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                     [Page 1]
+
+RFC 4469                IMAP CATENATE Extension               April 2006
+
+
+1.  Introduction
+
+   The CATENATE extension to the Internet Message Access Protocol (IMAP)
+   [1] allows the client to create a message on the server that can
+   include the text of messages (or parts of messages) that already
+   exist on the server without having to FETCH them and APPEND them back
+   to the server.  The CATENATE extension extends the APPEND command so
+   that, instead of a single message literal, the command can take as
+   arguments any combination of message literals (as described in IMAP
+   [1]) and message URLs (as described in the IMAP URL Scheme [2]
+   specification).  The server takes all the pieces and catenates them
+   into the output message.  The CATENATE extension can also coexist
+   with the MULTIAPPEND extension [3] to APPEND multiple messages in a
+   single command.
+
+   There are some obvious uses for the CATENATE extension.  The
+   motivating use case was to provide a way for a resource-constrained
+   client to compose a message for subsequent submission that contains
+   data that already exists in that client's IMAP store.  Because the
+   client does not have to download and re-upload potentially large
+   message parts, bandwidth and processing limitations do not have as
+   much impact.  In addition, since the client can create a message in
+   its own IMAP store, the command also addresses the desire of the
+   client to archive a copy of a sent message without having to upload
+   the message twice.  (Mechanisms for sending the message are outside
+   the scope of this document.)
+
+   The extended APPEND command can also be used to copy parts of a
+   message to another mailbox for archival purposes while getting rid of
+   undesired parts.  In environments where server storage is limited, a
+   client could get rid of large message parts by copying over only the
+   necessary parts and then deleting the original message.  The
+   mechanism could also be used to add data to a message (such as
+   prepending message header fields) or to include other data by making
+   a copy of the original and catenating the new data.
+
+2.  The CATENATE Capability
+
+   A server that supports this extension returns "CATENATE" as one of
+   the responses to the CAPABILITY command.
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                     [Page 2]
+
+RFC 4469                IMAP CATENATE Extension               April 2006
+
+
+3.  The APPEND Command
+
+   Arguments:  mailbox name
+               (The following can be repeated in the presence of the
+               MULTIAPPEND extension [3])
+               OPTIONAL flag parenthesized list
+               OPTIONAL date/time string
+               a single message literal or one or more message parts to
+               catenate, specified as:
+                           message literal
+                           or
+                           message (or message part) URL
+
+   Responses:  OPTIONAL NO responses: BADURL, TOOBIG
+
+   Result:     OK -  append completed
+               NO -  append error: can't append to that mailbox, error
+                     in flags or date/time or message text, or can't
+                     fetch that data
+               BAD - command unknown or arguments invalid
+
+   The APPEND command concatenates all the message parts and appends
+   them as a new message to the end of the specified mailbox.  The
+   parenthesized flag list and date/time string set the flags and the
+   internal date, respectively, as described in IMAP [1].  The
+   subsequent command parameters specify the message parts that are
+   appended sequentially to the output message.
+
+   If the original form of APPEND is used, a message literal follows the
+   optional flag list and date/time string, which is appended as
+   described in IMAP [1].  If the extended form is used, "CATENATE" and
+   a parenthesized list of message literals and message URLs follows,
+   each of which is appended to the new message.  If a message literal
+   is specified (indicated by "TEXT"), the octets following the count
+   are appended.  If a message URL is specified (indicated by "URL"),
+   the octets of the body part pointed to by that URL are appended, as
+   if the literal returned in a FETCH BODY response were put in place of
+   the message part specifier.  The APPEND command does not cause the
+   \Seen flag to be set for any catenated body part.  The APPEND command
+   does not change the selected mailbox.
+
+   In the extended APPEND command, the string following "URL" is an IMAP
+   URL [2] and is interpreted according to the rules of [2].  The
+   present document only describes the behavior of the command using
+   IMAP URLs that refer to specific messages or message parts on the
+   current IMAP server from the current authenticated IMAP session.
+   Because of that, only relative IMAP message or message part URLs
+   (i.e., those having no scheme or <iserver>) are used.  The base URL
+
+
+
+Resnick                     Standards Track                     [Page 3]
+
+RFC 4469                IMAP CATENATE Extension               April 2006
+
+
+   for evaluating the relative URL is considered "imap://user@server/",
+   where "user" is the user name of the currently authenticated user and
+   "server" is the domain name of the current server.  When in the
+   selected state, the base URL is considered
+   "imap://user@server/mailbox", where "mailbox" is the encoded name of
+   the currently selected mailbox.  Additionally, since the APPEND
+   command is valid in the authenticated state of an IMAP session, no
+   further LOGIN or AUTHENTICATE command is performed for URLs specified
+   in the extended APPEND command.
+
+      Note: Use of an absolute IMAP URL or any URL that refers to
+      anything other than a message or message part from the current
+      authenticated IMAP session is outside the scope of this document
+      and would require an extension to this specification, and a server
+      implementing only this specification would return NO to such a
+      request.
+
+   The client is responsible for making sure that the catenated message
+   is in the format of an Internet Message Format (RFC 2822) [4] or
+   Multipurpose Internet Mail Extension (MIME) [5] message.  In
+   particular, when a URL is catenated, the server copies octets,
+   unchanged, from the indicated message or message part to the
+   catenated message.  It does no data conversion (e.g., MIME transfer
+   encodings) nor any verification that the data is appropriate for the
+   MIME part of the message into which it is inserted.  The client is
+   also responsible for inserting appropriate MIME boundaries between
+   body parts, and writing MIME Content-Type and Content-Transfer-
+   Encoding lines as needed in the appropriate places.
+
+   Responses behave just as the original APPEND command described in
+   IMAP [1].  If the server implements the IMAP UIDPLUS extension [6],
+   it will also return an APPENDUID response code in the tagged OK
+   response.  Two response codes are provided in Section 4 that can be
+   used in the tagged NO response if the APPEND command fails.
+
+4.  Response Codes
+
+   When a APPEND command fails, it may return a response code that
+   describes a reason for the failure.
+
+4.1.  BADURL Response
+
+   The BADURL response code is returned if the APPEND fails to process
+   one of the specified URLs.  Possible reasons for this are bad URL
+   syntax, unrecognized URL schema, invalid message UID, or invalid body
+   part.  The BADURL response code contains the first URL specified as a
+   parameter to the APPEND command that has caused the operation to
+   fail.
+
+
+
+Resnick                     Standards Track                     [Page 4]
+
+RFC 4469                IMAP CATENATE Extension               April 2006
+
+
+4.2.  TOOBIG Response
+
+   The TOOBIG response code is returned if the resulting message will
+   exceed the 4-GB IMAP message limit.  This might happen, for example,
+   if the client specifies 3 URLs for 2-GB messages.  Note that even if
+   the server doesn't return TOOBIG, it still has to be defensive
+   against misbehaving or malicious clients that try to construct a
+   message over the 4-GB limit.  The server may also wish to return the
+   TOOBIG response code if the resulting message exceeds a server-
+   specific message size limit.
+
+5.  Formal Syntax
+
+   The following syntax specification uses the Augmented Backus-Naur
+   Form (ABNF) [7] notation.  Elements not defined here can be found in
+   the formal syntax of the ABNF [7], IMAP [1], and IMAP ABNF extensions
+   [8] specifications.  Note that capability and resp-text-code are
+   extended from the IMAP [1] specification and append-data is extended
+   from the IMAP ABNF extensions [8] specification.
+
+   append-data =/ "CATENATE" SP "(" cat-part *(SP cat-part) ")"
+
+   cat-part = text-literal / url
+
+   text-literal = "TEXT" SP literal
+
+   url = "URL" SP astring
+
+   resp-text-code =/ toobig-response-code / badurl-response-code
+
+   toobig-response-code = "TOOBIG"
+
+   badurl-response-code = "BADURL" SP url-resp-text
+
+   url-resp-text = 1*(%x01-09 /
+                      %x0B-0C /
+                      %x0E-5B /
+                      %x5D-FE) ; Any TEXT-CHAR except "]"
+
+   capability =/ "CATENATE"
+
+   The astring in the definition of url and the url-resp-text in the
+   definition of badurl-response-code each contain an imapurl as defined
+   by [2].
+
+
+
+
+
+
+
+Resnick                     Standards Track                     [Page 5]
+
+RFC 4469                IMAP CATENATE Extension               April 2006
+
+
+6.  Acknowledgements
+
+   Thanks to the members of the LEMONADE working group for their input.
+   Special thanks to Alexey Melnikov for the examples.
+
+7.  Security Considerations
+
+   The CATENATE extension does not raise any security considerations
+   that are not present for the base protocol or in the use of IMAP
+   URLs, and these issues are discussed in the IMAP [1] and IMAP URL [2]
+   documents.
+
+8.  IANA Considerations
+
+   IMAP4 capabilities are registered by publishing a standards track or
+   IESG approved experimental RFC.  The registry is currently located at
+   <http://www.iana.org/assignments/imap4-capabilities>.  This document
+   defines the CATENATE IMAP capability.  The IANA has added this
+   capability to the registry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                     [Page 6]
+
+RFC 4469                IMAP CATENATE Extension               April 2006
+
+
+Appendix A.  Examples
+
+   Lines not starting with "C: " or "S: " are continuations of the
+   previous lines.
+
+   The original message in examples 1 and 2 below (UID = 20) has the
+   following structure:
+
+
+      multipart/mixed MIME message with two body parts:
+
+      1.  text/plain
+
+      2.  application/x-zip-compressed
+
+   Example 1: The following example demonstrates how a CATENATE client
+   can replace an attachment in a draft message, without the need to
+   download it to the client and upload it back.
+
+   C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
+    (URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=HEADER"
+    TEXT {42}
+   S: + Ready for literal data
+   C:
+   C: --------------030308070208000400050907
+   C:  URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1.MIME"
+    URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1" TEXT {42}
+   S: + Ready for literal data
+   C:
+   C: --------------030308070208000400050907
+   C:  URL "/Drafts;UIDVALIDITY=385759045/;UID=30" TEXT {44}
+   S: + Ready for literal data
+   C:
+   C: --------------030308070208000400050907--
+   C: )
+   S: A003 OK catenate append completed
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                     [Page 7]
+
+RFC 4469                IMAP CATENATE Extension               April 2006
+
+
+   Example 2: The following example demonstrates how the CATENATE
+   extension can be used to replace edited text in a draft message, as
+   well as header fields for the top level message part (e.g., Subject
+   has changed).  The previous version of the draft is marked as
+   \Deleted.  Note that the server also supports the UIDPLUS extension,
+   so the APPENDUID response code is returned in the successful OK
+   response to the APPEND command.
+
+   C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE (TEXT {738}
+   S: + Ready for literal data
+   C: Return-Path: <bar@example.org>
+   C: Received: from [127.0.0.2]
+   C:           by rufus.example.org via TCP (internal) with ESMTPA;
+   C:           Thu, 11 Nov 2004 16:57:07 +0000
+   C: Message-ID: <419399E1.6000505@example.org>
+   C: Date: Thu, 12 Nov 2004 16:57:05 +0000
+   C: From: Bob Ar <bar@example.org>
+   C: X-Accept-Language: en-us, en
+   C: MIME-Version: 1.0
+   C: To: foo@example.net
+   C: Subject: About our holiday trip
+   C: Content-Type: multipart/mixed;
+   C:               boundary="------------030308070208000400050907"
+   C:
+   C: --------------030308070208000400050907
+   C: Content-Type: text/plain; charset=us-ascii; format=flowed
+   C: Content-Transfer-Encoding: 7bit
+   C:
+   C: Our travel agent has sent the updated schedule.
+   C:
+   C: Cheers,
+   C: Bob
+   C: --------------030308070208000400050907
+   C:  URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2.MIME"
+    URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2" TEXT {44}
+   S: + Ready for literal data
+   C:
+   C: --------------030308070208000400050907--
+   C: )
+   S: A003 OK [APPENDUID 385759045 45] append Completed
+   C: A004 UID STORE 20 +FLAGS.SILENT (\Deleted)
+   S: A004 OK STORE completed
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                     [Page 8]
+
+RFC 4469                IMAP CATENATE Extension               April 2006
+
+
+   Example 3: The following example demonstrates how the CATENATE
+   extension can be used to strip attachments.  Below, a PowerPoint
+   attachment was replaced by a small text part explaining that the
+   attachment was stripped.
+
+   C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
+    (URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=HEADER"
+    TEXT {42}
+   S: + Ready for literal data
+   C:
+   C: --------------030308070208000400050903
+   C:  URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1.MIME"
+    URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1" TEXT {255}
+   S: + Ready for literal data
+   C:
+   C: --------------030308070208000400050903
+   C: Content-type: text/plain; charset="us-ascii"
+   C: Content-transfer-encoding: 7bit
+   C:
+   C: This body part contained a Power Point presentation that was
+   C: deleted upon your request.
+   C: --------------030308070208000400050903--
+   C: )
+   S: A003 OK append Completed
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                     [Page 9]
+
+RFC 4469                IMAP CATENATE Extension               April 2006
+
+
+   Example 4: The following example demonstrates a failed APPEND
+   command.  The server returns the BADURL response code to indicate
+   that one of the provided URLs is invalid.  This example also
+   demonstrates how the CATENATE extension can be used to construct a
+   digest of several messages.
+
+   C: A003 APPEND Sent (\Seen $MDNSent) CATENATE (TEXT {541}
+   S: + Ready for literal data
+   C: Return-Path: <foo@example.org>
+   C: Received: from [127.0.0.2]
+   C:           by rufus.example.org via TCP (internal) with ESMTPA;
+   C:           Thu, 11 Nov 2004 16:57:07 +0000
+   C: Message-ID: <419399E1.6000505@example.org>
+   C: Date: Thu, 21 Nov 2004 16:57:05 +0000
+   C: From: Farren Oo <foo@example.org>
+   C: X-Accept-Language: en-us, en
+   C: MIME-Version: 1.0
+   C: To: bar@example.org
+   C: Subject: Digest of the mailing list for today
+   C: Content-Type: multipart/digest;
+   C:               boundary="------------030308070208000400050904"
+   C:
+   C: --------------030308070208000400050904
+   C:  URL "/INBOX;UIDVALIDITY=785799047/;UID=11467" TEXT {42}
+   S: + Ready for literal data
+   C:
+   C: --------------030308070208000400050904
+   C:  URL "/INBOX;UIDVALIDITY=785799047/;UID=113330/;section=1.5.9"
+    TEXT {42}
+   S: + Ready for literal data
+   C:
+   C: --------------030308070208000400050904
+   C:  URL "/INBOX;UIDVALIDITY=785799047/;UID=11916" TEXT {44}
+   S: + Ready for literal data
+   C:
+   C: --------------030308070208000400050904--
+   C: )
+   S: A003 NO [BADURL "/INBOX;UIDVALIDITY=785799047/;UID=113330;
+   section=1.5.9"] CATENATE append has failed, one message expunged
+
+   Note that the server could have validated the URLs as they were
+   received and therefore could have returned the tagged NO response
+   with BADURL response-code in place of any continuation request after
+   the URL was received.
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 10]
+
+RFC 4469                IMAP CATENATE Extension               April 2006
+
+
+9.  Normative References
+
+   [1]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
+        RFC 3501, March 2003.
+
+   [2]  Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
+
+   [3]  Crispin, M., "Internet Message Access Protocol (IMAP) -
+        MULTIAPPEND Extension", RFC 3502, March 2003.
+
+   [4]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.
+
+   [5]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+        Extensions (MIME) Part One: Format of Internet Message Bodies",
+        RFC 2045, November 1996.
+
+   [6]  Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS
+        extension", RFC 4315, December 2005.
+
+   [7]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+        Specifications: ABNF", RFC 4234, October 2005.
+
+   [8]  Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF",
+        RFC 4466, April 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 11]
+
+RFC 4469                IMAP CATENATE Extension               April 2006
+
+
+Author's Address
+
+   Peter W. Resnick
+   QUALCOMM Incorporated
+   5775 Morehouse Drive
+   San Diego, CA  92121-1714
+   US
+
+   Phone: +1 858 651 4478
+   EMail: presnick@qualcomm.com
+   URI:   http://www.qualcomm.com/~presnick/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 12]
+
+RFC 4469                IMAP CATENATE Extension               April 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Resnick                     Standards Track                    [Page 13]
+
diff --git a/docs/rfcs/rfc4549.txt b/docs/rfcs/rfc4549.txt
new file mode 100644
index 0000000..8430ee1
--- /dev/null
+++ b/docs/rfcs/rfc4549.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Network Working Group                                   A. Melnikov, Ed.
+Request for Comments: 4549                                    Isode Ltd.
+Category: Informational                                        June 2006
+
+
+       Synchronization Operations for Disconnected IMAP4 Clients
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document attempts to address some of the issues involved in
+   building a disconnected IMAP4 client.  In particular, it deals with
+   the issues of what might be called the "driver" portion of the
+   synchronization tool: the portion of the code responsible for issuing
+   the correct set of IMAP4 commands to synchronize the disconnected
+   client in the way that is most likely to make the human who uses the
+   disconnected client happy.
+
+   This note describes different strategies that can be used by
+   disconnected clients and shows how to use IMAP protocol in order to
+   minimize the time of the synchronization process.
+
+   This note also lists IMAP extensions that a server should implement
+   in order to provide better synchronization facilities to disconnected
+   clients.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov                     Informational                      [Page 1]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Conventions Used in This Document ..........................3
+   2. Design Principles ...............................................3
+   3. Overall Picture of Synchronization ..............................4
+   4. Mailbox Synchronization Steps and Strategies ....................7
+      4.1. Checking UID Validity ......................................7
+      4.2. Synchronizing Local Changes with the Server ................8
+           4.2.1. Uploading Messages to the Mailbox ...................8
+           4.2.2. Optimizing "move" and "copy" Operations .............9
+           4.2.3. Replaying Local Flag Changes .......................14
+           4.2.4. Processing Mailbox Compression (EXPUNGE) Requests ..15
+           4.2.5. Closing a Mailbox ..................................17
+      4.3. Details of "Normal" Synchronization of a Single Mailbox ...18
+           4.3.1. Discovering New Messages and Changes to Old
+                  Messages ...........................................18
+           4.3.2. Searching for "Interesting" Messages. ..............20
+           4.3.3. Populating Cache with "Interesting" Messages. ......21
+           4.3.4. User-Initiated Synchronization .....................22
+      4.4. Special Case: Descriptor-Only Synchronization .............22
+      4.5. Special Case: Fast New-Only Synchronization ...............23
+      4.6. Special Case: Blind FETCH .................................23
+   5. Implementation Considerations ..................................24
+      5.1. Error Recovery during Playback ............................26
+      5.2. Quality of Implementation Issues ..........................28
+      5.3. Optimizations .............................................28
+   6. IMAP Extensions That May Help ..................................30
+      6.1. CONDSTORE Extension .......................................30
+   7. Security Considerations ........................................33
+   8. References .....................................................33
+      8.1. Normative References ......................................33
+      8.2. Informative References ....................................34
+   9. Acknowledgements ...............................................34
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov                     Informational                      [Page 2]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+1.  Introduction
+
+   Several recommendations presented in this document are generally
+   applicable to all types of IMAP clients.  However, this document
+   tries to concentrate on disconnected mail clients [IMAP-MODEL].  It
+   also suggests some IMAP extensions* that should be implemented by
+   IMAP servers in order to make the life of disconnected clients
+   easier.  In particular, the [UIDPLUS] extension was specifically
+   designed to streamline certain disconnected operations, like
+   expunging, uploading, and copying messages (see Sections 4.2.1,
+   4.2.2.1, and 4.2.4).
+
+   Readers of this document are also strongly advised to read RFC 2683
+   [RFC2683].
+
+   * Note that the functionality provided by the base IMAP protocol
+     [IMAP4] is sufficient to perform basic synchronization.
+
+1.1.  Conventions Used in This Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server, respectively.  Long lines in examples are broken for
+   editorial clarity.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [KEYWORDS].
+
+   Let's call an IMAP command idempotent if the result of executing the
+   command twice sequentially is the same as the result of executing the
+   command just once.
+
+2.  Design Principles
+
+   All mailbox state or content information stored on the disconnected
+   client should be viewed strictly as a cache of the state of the
+   server.  The "master" state remains on the server, just as it would
+   with an interactive IMAP4 client.  The one exception to this rule is
+   that information about the state of the disconnected client's cache
+   (the state includes flag changes while offline and during scheduled
+   message uploads) remains on the disconnected client: that is, the
+   IMAP4 server is not responsible for remembering the state of the
+   disconnected IMAP4 client.
+
+   We assume that a disconnected client is a client that, for whatever
+   reason, wants to minimize the length of time that it is "on the
+   phone" to the IMAP4 server.  Often this will be because the client is
+   using a dialup connection, possibly with very low bandwidth, but
+
+
+
+Melnikov                     Informational                      [Page 3]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   sometimes it might just be that the human is in a hurry to catch an
+   airplane, or some other event beyond our control.  Whatever the
+   reason, we assume that we must make efficient use of the network
+   connection, both in the usual sense (not generating spurious traffic)
+   and in the sense that we would prefer not to have the connection
+   sitting idle while the client and/or the server is performing
+   strictly local computation or I/O.  Another, perhaps simpler way of
+   stating this is that we assume that network connections are
+   "expensive".
+
+   Practical experience with disconnected mail systems has shown that
+   there is no single synchronization strategy that is appropriate for
+   all cases.  Different humans have different preferences, and the same
+   human's preference will vary depending both on external circumstance
+   (how much of a hurry the human is in today) and on the value that the
+   human places on the messages being transferred.  The point here is
+   that there is no way that the synchronization program can guess
+   exactly what the human wants to do, so the human will have to provide
+   some guidance.
+
+   Taken together, the preceding two principles lead to the conclusion
+   that the synchronization program must make its decisions based on
+   some kind of guidance provided by the human, by selecting the
+   appropriate options in the user interface or through some sort of
+   configuration file.  Almost certainly, it should not pause for I/O
+   with the human in the middle of the synchronization process.  The
+   human will almost certainly have several different configurations for
+   the synchronization program, for different circumstances.
+
+   Since a disconnected client has no way of knowing what changes might
+   have occurred to the mailbox while it was disconnected, message
+   numbers are not useful to a disconnected client.  All disconnected
+   client operations should be performed using UIDs, so that the client
+   can be sure that it and the server are talking about the same
+   messages during the synchronization process.
+
+3.  Overall Picture of Synchronization
+
+   The basic strategy for synchronization is outlined below.  Note that
+   the real strategy may vary from one application to another or may
+   depend on a synchronization mode.
+
+   a) Process any "actions" that were pending on the client that were
+      not associated with any mailbox.  (In particular sending messages
+      composed offline with SMTP.  This is not part of IMAP
+      synchronization, but it is mentioned here for completeness.)
+
+
+
+
+
+Melnikov                     Informational                      [Page 4]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   b) Fetch the current list of "interesting" mailboxes.  (The
+      disconnected client should allow the user to skip this step
+      completely.)
+
+   c) "Client-to-server synchronization": for each IMAP "action" that
+      was pending on the client, do the following:
+
+      1) If the action implies opening a new mailbox (any operation that
+         operates on messages), open the mailbox.  Check its UID
+         validity value (see Section 4.1 for more details) returned in
+         the UIDVALIDITY response code.  If the UIDVALIDITY value
+         returned by the server differs, the client MUST empty the local
+         cache of the mailbox and remove any pending "actions" that
+         refer to UIDs in that mailbox (and consider them failed).  Note
+         that this doesn't affect actions performed on client-generated
+         fake UIDs (see Section 5).
+
+      2) Perform the action.  If the action is to delete a mailbox
+         (DELETE), make sure that the mailbox is closed first (see also
+         Section 3.4.12 of [RFC2683]).
+
+   d) "Server-to-client synchronization": for each mailbox that requires
+      synchronization, do the following:
+
+      1) Check the mailbox UIDVALIDITY (see Section 4.1 for more
+         details) with SELECT/EXAMINE/STATUS.
+
+         If UIDVALIDITY value returned by the server differs, the client
+         MUST
+
+         * empty the local cache of that mailbox;
+         * remove any pending "actions" that refer to UIDs in that
+           mailbox and consider them failed; and
+         * skip step 2-II.
+
+      2) Fetch the current "descriptors";
+
+         I)  Discover new messages.
+
+         II) Discover changes to old messages.
+
+      3) Fetch the bodies of any "interesting" messages that the client
+         doesn't already have.
+
+   e) Close all open mailboxes not required for further operations (if
+      staying online) or disconnect all open connections (if going
+      offline).
+
+
+
+
+Melnikov                     Informational                      [Page 5]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   Terms used:
+
+   "Actions" are queued requests that were made by the human to the
+   client's Mail User Agent (MUA) software while the client was
+   disconnected.
+
+   We define "descriptors" as a set of IMAP4 FETCH data items.
+   Conceptually, a message's descriptor is that set of information that
+   allows the synchronization program to decide what protocol actions
+   are necessary to bring the local cache to the desired state for this
+   message; since this decision is really up to the human, this
+   information probably includes at least a few header fields intended
+   for human consumption.  Exactly what will constitute a descriptor
+   depends on the client implementation.  At a minimum, the descriptor
+   contains the message's UID and FLAGS.  Other likely candidates are
+   the RFC822.SIZE, RFC822.HEADER, BODYSTRUCTURE, or ENVELOPE data
+   items.
+
+   Comments:
+
+   1) The list of actions should be ordered.  For example, if the human
+      deletes message A1 in mailbox A, then expunges mailbox A, and then
+      deletes message A2 in mailbox A, the human will expect that
+      message A1 is gone and that message A2 is still present but is now
+      deleted.
+
+      By processing all the actions before proceeding with
+      synchronization, we avoid having to compensate for the local MUA's
+      changes to the server's state.  That is, once we have processed
+      all the pending actions, the steps that the client must take to
+      synchronize itself will be the same no matter where the changes to
+      the server's state originated.
+
+   2) Steps a and b can be performed in parallel.  Alternatively, step a
+      can be performed after d.
+
+   3) On step b, the set of "interesting" mailboxes pretty much has to
+      be determined by the human.  What mailboxes belong to this set may
+      vary between different IMAP4 sessions with the same server,
+      client, and human.  An interesting mailbox can be a mailbox
+      returned by LSUB command (see Section 6.3.9 of [IMAP4]).  The
+      special mailbox "INBOX" SHOULD be in the default set of mailboxes
+      that the client considers interesting.  However, providing the
+      ability to ignore INBOX for a particular session or client may be
+      valuable for some mail filtering strategies.
+
+
+
+
+
+
+Melnikov                     Informational                      [Page 6]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   4) On step d-2-II, the client also finds out about changes to the
+      flags of messages that the client already has in its local cache,
+      and about messages in the local cache that no longer exist on the
+      server (i.e., messages that have been expunged).
+
+   5) "Interesting" messages are those messages that the synchronization
+      program thinks the human wants to have cached locally, based on
+      the configuration and the data retrieved in step b.
+
+   6) A disconnected IMAP client is a special case of an IMAP client, so
+      it MUST be able to handle any "unexpected" unsolicited responses,
+      like EXISTS and EXPUNGE, at any time.  The disconnected client MAY
+      ignore EXPUNGE response during "client-to-server" synchronization
+      phase (step c).
+
+   The rest of this discussion will focus primarily on the
+   synchronization issues for a single mailbox.
+
+4.  Mailbox Synchronization Steps and Strategies
+
+4.1.  Checking UID Validity
+
+   The "UID validity" of a mailbox is a number returned in an
+   UIDVALIDITY response code in an OK untagged response at mailbox
+   selection time.  The UID validity value changes between sessions when
+   UIDs fail to persist between sessions.
+
+   Whenever the client selects a mailbox, the client must compare the
+   returned UID validity value with the value stored in the local cache.
+   If the UID validity values differ, the UIDs in the client's cache are
+   no longer valid.  The client MUST then empty the local cache of that
+   mailbox and remove any pending "actions" that refer to UIDs in that
+   mailbox.  The client MAY also issue a warning to the human.  The
+   client MUST NOT cancel any scheduled uploads (i.e., APPENDs) for the
+   mailbox.
+
+   Note that UIDVALIDITY is not only returned on a mailbox selection.
+   The COPYUID and APPENDUID response codes defined in the [UIDPLUS]
+   extension (see also 4.2.2) and the UIDVALIDITY STATUS response data
+   item also contain a UIDVALIDITY value for some other mailbox.  The
+   client SHOULD behave as described in the previous paragraph (but it
+   should act on the other mailbox's cache), no matter how it obtained
+   the UIDVALIDITY value.
+
+
+
+
+
+
+
+
+Melnikov                     Informational                      [Page 7]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+4.2.  Synchronizing Local Changes with the Server
+
+4.2.1.  Uploading Messages to the Mailbox
+
+   Two of the most common examples of operations resulting in message
+   uploads are:
+
+   1) Saving a draft message
+
+   2) Copying a message between remote mailboxes on two different IMAP
+      servers or a local mailbox and a remote mailbox.
+
+   Message upload is performed with the APPEND command.  A message
+   scheduled to be uploaded has no UID associated with it, as all UIDs
+   are assigned by the server.  The APPEND command will effectively
+   associate a UID with the uploaded message that can be stored in the
+   local cache for future reference.  However, [IMAP4] doesn't describe
+   a simple mechanism to discover the message UID by just performing the
+   APPEND command.  In order to discover the UID, the client can do one
+   of the following:
+
+   1) Remove the uploaded message from cache.  Then, use the mechanism
+      described in 4.3 to fetch the information about the uploaded
+      message as if it had been uploaded by some other client.
+
+   2) Try to fetch header information as described in 4.2.2 in order to
+      find a message that corresponds to the uploaded message.  One
+      strategy for doing this is described in 4.2.2.
+
+   Case 1 describes a not particularly smart client.
+
+      C: A003 APPEND Drafts (\Seen $MDNSent) {310}
+      S: + Ready for literal data
+      C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
+      C: From: Fred Foobar <foobar@blt.example.COM>
+      C: Subject: afternoon meeting
+      C: To: mooch@owatagu.siam.edu
+      C: Message-Id: <B27397-0100000@blt.example.COM>
+      C: MIME-Version: 1.0
+      C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+      C:
+      C: Hello Joe, do you think we can meet at 3:30 tomorrow?
+      C:
+      S: A003 OK APPEND Completed
+
+   Fortunately, there is a simpler way to discover the message UID in
+   the presence of the [UIDPLUS] extension:
+
+
+
+
+Melnikov                     Informational                      [Page 8]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+      C: A003 APPEND Drafts (\Seen $MDNSent) {310}
+      S: + Ready for literal data
+      C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
+      C: From: Fred Foobar <foobar@blt.example.COM>
+      C: Subject: afternoon meeting
+      C: To: mooch@owatagu.siam.edu
+      C: Message-Id: <B27397-0100000@blt.example.COM>
+      C: MIME-Version: 1.0
+      C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+      C:
+      C: Hello Joe, do you think we can meet at 3:30 tomorrow?
+      C:
+      S: A003 OK [APPENDUID 1022843275 77712] APPEND completed
+
+   The UID of the appended message is the second parameter of APPENDUID
+   response code.
+
+4.2.2.  Optimizing "move" and "copy" Operations
+
+   Practical experience with IMAP and other mailbox access protocols
+   that support multiple mailboxes suggests that moving a message from
+   one mailbox to another is an extremely common operation.
+
+4.2.2.1.  Moving a Message between Two Mailboxes on the Same Server
+
+   In IMAP4, a "move" operation between two mailboxes on the same server
+   is really a combination of a COPY operation and a STORE +FLAGS
+   (\Deleted) operation.  This makes good protocol sense for IMAP, but
+   it leaves a simple-minded disconnected client in the silly position
+   of deleting and possibly expunging its cached copy of a message, then
+   fetching an identical copy via the network.
+
+   However, the presence of the UIDPLUS extension in the server can
+   help:
+
+      C: A001 UID COPY 567,414 "Interesting Messages"
+      S: A001 OK [COPYUID 1022843275 414,567 5:6] Completed
+
+   This tells the client that the message with UID 414 in the current
+   mailbox was successfully copied to the mailbox "Interesting Messages"
+   and was given the UID 5, and that the message with UID 567 was given
+   the UID 6.
+
+   In the absence of UIDPLUS extension support in the server, the
+   following trick can be used.  By including the Message-ID: header and
+   the INTERNALDATE data item as part of the descriptor, the client can
+   check the descriptor of a "new" message against messages that are
+   already in its cache and avoid fetching the extra copy.  Of course,
+
+
+
+Melnikov                     Informational                      [Page 9]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   it's possible that the cost of checking to see if the message is
+   already in the local cache may exceed the cost of just fetching it,
+   so this technique should not be used blindly.  If the MUA implements
+   a "move" command, it makes special provisions to use this technique
+   when it knows that a copy/delete sequence is the result of a "move"
+   command.
+
+   Note that servers are not required (although they are strongly
+   encouraged with "SHOULD language") to preserve INTERNALDATE when
+   copying messages.
+
+   Also note that since it's theoretically possible for this algorithm
+   to find the wrong message (given sufficiently malignant Message-ID
+   headers), implementers should provide a way to disable this
+   optimization, both permanently and on a message-by-message basis.
+
+   Example 1: Copying a message in the absence of UIDPLUS extension.
+
+   At some point in time the client has fetched the source message and
+   some information was cached:
+
+      C: C021 UID FETCH <uids> (BODY.PEEK[] INTERNALDATE FLAGS)
+      ...
+      S: * 27 FETCH (UID 123 INTERNALDATE "31-May-2002 05:26:59 -0600"
+          FLAGS (\Draft $MDNSent) BODY[] {1036}
+      S: ...
+      S: Message-Id: <20040903110856.22a127cd@chardonnay>
+      S: ...
+      S: ...message body...
+      S: )
+      ...
+      S: C021 OK fetch completed
+
+   Later on, the client decides to copy the message:
+
+      C: C035 UID COPY 123 "Interesting Messages"
+      S: C035 OK Completed
+
+   As the server hasn't provided the COPYUID response code, the client
+   tries the optimization described above:
+
+      C: C036 SELECT "Interesting Messages"
+      ...
+      C: C037 UID SEARCH ON 31-May-2002 HEADER
+          "Message-Id" "20040903110856.22a127cd@chardonnay"
+      S: SEARCH 12368
+      S: C037 OK completed
+
+
+
+
+Melnikov                     Informational                     [Page 10]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   Note that if the server has returned multiple UIDs in the SEARCH
+   response, the client MUST NOT use any of the returned UID.
+
+4.2.2.2.  Moving a Message from a Remote Mailbox to a Local
+
+   Moving a message from a remote mailbox to a local is done with FETCH
+   (that includes FLAGS and INTERNALDATE) followed by UID STORE <uid>
+   +FLAGS.SILENT (\Deleted):
+
+      C: A003 UID FETCH 123 (BODY.PEEK[] INTERNALDATE FLAGS)
+      S: * 27 FETCH (UID 123 INTERNALDATE "31-May-2002 05:26:59 -0600"
+          FLAGS (\Seen $MDNSent) BODY[]
+      S: ...message body...
+      S: )
+      S: A003 OK UID FETCH completed
+      C: A004 UID STORE <uid> +FLAGS.SILENT (\Deleted)
+      S: A004 STORE completed
+
+   Note that there is no reason to fetch the message during
+   synchronization if it's already in the client's cache.  Also, the
+   client SHOULD preserve delivery date in the local cache.
+
+4.2.2.3.  Moving a Message from a Local Mailbox to a Remote
+
+   Moving a message from a local mailbox to a remote is done with
+   APPEND:
+
+   C: A003 APPEND Drafts (\Seen $MDNSent) "31-May-2002 05:26:59 -0600"
+       {310}
+   S: + Ready for literal data
+   C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
+   C: From: Fred Foobar <foobar@blt.example.COM>
+   C: Subject: afternoon meeting
+   C: To: mooch@owatagu.siam.edu
+   C: Message-Id: <B27397-0100000@blt.example.COM>
+   C: MIME-Version: 1.0
+   C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+   C:
+   C: Hello Joe, do you think we can meet at 3:30 tomorrow?
+   C:
+   S: A003 OK [APPENDUID 1022843275 77712] completed
+
+   The client SHOULD specify the delivery date from the local cache in
+   the APPEND.
+
+   If the [LITERAL+] extension is available, the client can save a
+   round-trip*:
+
+
+
+
+Melnikov                     Informational                     [Page 11]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   C: A003 APPEND Drafts (\Seen $MDNSent) "31-May-2002 05:26:59 -0600"
+       {310+}
+   C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
+   C: From: Fred Foobar <foobar@blt.example.COM>
+   C: Subject: afternoon meeting
+   C: To: mooch@owatagu.siam.edu
+   C: Message-Id: <B27397-0100000@blt.example.COM>
+   C: MIME-Version: 1.0
+   C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+   C:
+   C: Hello Joe, do you think we can meet at 3:30 tomorrow?
+   C:
+   S: A003 OK [APPENDUID 1022843275 77712] completed
+
+   * Note that there is a risk that the server will reject the message
+     due to its size.  If this happens, the client will waste bandwidth
+     transferring the whole message.  If the client wouldn't have used
+     the LITERAL+, this could have been avoided:
+
+   C: A003 APPEND Drafts (\Seen $MDNSent) "31-May-2004 05:26:59 -0600"
+       {16777215}
+   S: A003 NO Sorry, message is too big
+
+4.2.2.4.  Moving a Message between Two Mailboxes on Different Servers
+
+   Moving a message between two mailbox on two different servers is a
+   combination of the operations described in 4.2.2.2 followed by the
+   operations described in 4.2.2.3.
+
+4.2.2.5.  Uploading Multiple Messages to a Remote Mailbox with
+          MULTIAPPEND
+
+   When there is a need to upload multiple messages to a remote mailbox
+   (e.g., as per 4.2.2.3), the presence of certain IMAP extensions may
+   significantly improve performance.  One of them is [MULTIAPPEND].
+
+   For some mail stores, opening a mailbox for appending might be
+   expensive.  [MULTIAPPEND] tells the server to open the mailbox once
+   (instead of opening and closing it "n" times per "n" messages to be
+   uploaded) and to keep it open while a group of messages is being
+   uploaded to the server.
+
+   Also, if the server supports both [MULTIAPPEND] and [LITERAL+]
+   extensions, the entire upload is accomplished in a single
+   command/response round-trip.
+
+
+
+
+
+
+Melnikov                     Informational                     [Page 12]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   Note: Client implementers should be aware that [MULTIAPPEND] performs
+   append of multiple messages atomically.  This means, for example, if
+   there is not enough space to save "n"-th message (or the message has
+   invalid structure and is rejected by the server) after successful
+   upload of "n-1" messages, the whole upload operation fails, and no
+   message will be saved in the mailbox.  Although this behavior might
+   be desirable in certain situations, it might not be what you want.
+   Otherwise, the client should use the regular APPEND command (Section
+   4.2.2.3), possibly utilizing the [LITERAL+] extension.  See also
+   Section 5.1 for discussions about error recovery.
+
+   Note: MULTIAPPEND can be used together with the UIDPLUS extension in
+   a way similar to what was described in Section 4.2.1.  [MULTIAPPEND]
+   extends the syntax of the APPENDUID response code to allow for
+   multiple message UIDs in the second parameter.
+
+   Example 2:
+
+   This example demonstrates the use of MULTIAPPEND together with
+   UIDPLUS (synchronization points where the client waits for
+   confirmations from the server are marked with "<--->"):
+
+   C: A003 APPEND Jan-2002 (\Seen $MDNSent) "31-May-2002 05:26:59 -0600"
+       {310}
+   <--->
+   S: + Ready for literal data
+   C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
+   C: From: Fred Foobar <foobar@blt.example.COM>
+   C: Subject: afternoon meeting
+   C: To: mooch@owatagu.siam.edu
+   C: Message-Id: <B27397-0100000@blt.example.COM>
+   C: MIME-Version: 1.0
+   C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+   C:
+   C: Hello Joe, do you think we can meet at 3:30 tomorrow?
+   C:  (\Seen) " 1-Jun-2002 22:43:04 -0800" {286}
+   <--->
+   S: + Ready for literal data
+   C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST)
+   C: From: Joe Mooch <mooch@OWaTaGu.siam.EDU>
+   C: Subject: Re: afternoon meeting
+   C: To: foobar@blt.example.com
+   C: Message-Id: <a0434793874930@OWaTaGu.siam.EDU>
+   C: MIME-Version: 1.0
+   C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+   C:
+   C: 3:30 is fine with me.
+   C:
+
+
+
+Melnikov                     Informational                     [Page 13]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   S: A003 OK [APPENDUID 1022843275 77712,77713] completed
+
+   The upload takes 3 round-trips.
+
+   Example 3:
+
+   In this example, Example 2 was modified for the case when the server
+   supports MULTIAPPEND, LITERAL+, and UIDPLUS.  The upload takes only 1
+   round-trip.
+
+   C: A003 APPEND Jan-2002 (\Seen $MDNSent) "31-May-2002 05:26:59 -0600"
+       {310+}
+   C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
+   C: From: Fred Foobar <foobar@blt.example.COM>
+   C: Subject: afternoon meeting
+   C: To: mooch@owatagu.siam.edu
+   C: Message-Id: <B27397-0100000@blt.example.COM>
+   C: MIME-Version: 1.0
+   C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+   C:
+   C: Hello Joe, do you think we can meet at 3:30 tomorrow?
+   C:  (\Seen) " 1-Jun-2002 22:43:04 -0800" {286+}
+   C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST)
+   C: From: Joe Mooch <mooch@OWaTaGu.siam.EDU>
+   C: Subject: Re: afternoon meeting
+   C: To: foobar@blt.example.com
+   C: Message-Id: <a0434793874930@OWaTaGu.siam.EDU>
+   C: MIME-Version: 1.0
+   C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+   C:
+   C: 3:30 is fine with me.
+   C:
+   S: A003 OK [APPENDUID 1022843275 77712,77713] completed
+
+4.2.3.  Replaying Local Flag Changes
+
+   The disconnected client uses the STORE command to synchronize local
+   flag state with the server.  The disconnected client SHOULD use
+   +FLAGS.SILENT or -FLAGS.SILENT in order to set or unset flags
+   modified by the user while offline.  The FLAGS form MUST NOT be used,
+   as there is a risk that this will overwrite flags on the server that
+   have been changed by some other client.
+
+   Example 4:
+
+   For the message with UID 15, the disconnected client stores the
+   following flags \Seen and $Highest.  The flags were modified on the
+   server by some other client: \Seen, \Answered, and $Highest.  While
+
+
+
+Melnikov                     Informational                     [Page 14]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   offline, the user requested that the $Highest flags be removed and
+   that the \Deleted flag be added.  The flag synchronization sequence
+   for the message should look like:
+
+      C: A001 UID STORE 15 +FLAGS.SILENT (\Deleted)
+      S: A001 STORE completed
+      C: A002 UID STORE 15 -FLAGS.SILENT ($Highest)
+      S: A002 STORE completed
+
+   If the disconnected client is able to store an additional binary
+   state information (or a piece of information that can take a value
+   from a predefined set of values) in the local cache of an IMAP
+   mailbox or in a local mailbox (e.g., message priority), and if the
+   server supports storing of arbitrary keywords, the client MUST use
+   keywords to store this state on the server.
+
+   Example 5:
+
+   Imagine a speculative mail client that can mark a message as one of
+   work-related ($Work), personal ($Personal), or spam ($Spam).  In
+   order to mark a message as personal, the client issues:
+
+      C: A001 UID STORE 15 +FLAGS.SILENT ($Personal)
+      S: A001 STORE completed
+      C: A002 UID STORE 15 -FLAGS.SILENT ($Work $Spam)
+      S: A002 STORE completed
+
+   In order to mark the message as not work, not personal and not spam,
+   the client issues:
+
+      C: A003 UID STORE 15 -FLAGS.SILENT ($Personal $Work $Spam)
+      S: A003 STORE completed
+
+4.2.4.  Processing Mailbox Compression (EXPUNGE) Requests
+
+   A naive disconnected client implementation that supports compressing
+   a mailbox while offline may decide to issue an EXPUNGE command to the
+   server in order to expunge messages marked \Deleted.  The problem
+   with this command during synchronization is that it permanently
+   erases all messages with the \Deleted flag set, i.e., even those
+   messages that were marked as \Deleted on the server while the user
+   was offline.  Doing this might result in an unpleasant surprise for
+   the user.
+
+   Fortunately the [UIDPLUS] extension can help in this case as well.
+   The extension introduces UID EXPUNGE command, that, unlike EXPUNGE,
+   takes a UID set parameter, that lists UIDs of all messages that can
+   be expunged.  When processing this command the server erases only
+
+
+
+Melnikov                     Informational                     [Page 15]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   messages with \Deleted flag listed in the UID list.  Thus, messages
+   not listed in the UID set will not be expunged even if they have the
+   \Deleted flag set.
+
+   Example 6:
+
+   While the user was offline, 3 messages with UIDs 7, 27, and 65 were
+   marked \Deleted when the user requested to compress the open mailbox.
+   Another client marked a message \Deleted on the server (UID 34).
+   During synchronization, the disconnected client issues:
+
+      C: A001 UID EXPUNGE 7,27,65
+      S: * ... EXPUNGE
+      S: * ... EXPUNGE
+      S: * ... EXPUNGE
+      S: A001 UID EXPUNGE completed
+
+   If another client issues UID SEARCH DELETED command (to find all
+   messages with the \Deleted flag) before and after the UID EXPUNGE, it
+   will get:
+
+   Before:
+
+      C: B001 UID SEARCH DELETED
+      S: * SEARCH 65 34 27 7
+      S: B001 UID SEARCH completed
+
+   After:
+
+      C: B002 UID SEARCH DELETED
+      S: * SEARCH 34
+      S: B002 UID SEARCH completed
+
+   In the absence of the [UIDPLUS] extension, the following sequence of
+   commands can be used as an approximation.  Note: It's possible for
+   another client to mark additional messages as deleted while this
+   sequence is being performed.  In this case, these additional messages
+   will be expunged as well.
+
+   1) Find all messages marked \Deleted on the server.
+
+      C: A001 UID SEARCH DELETED
+      S: * SEARCH 65 34 27 7
+      S: A001 UID SEARCH completed
+
+   2) Find all messages that must not be erased (for the previous
+      example the list will consist of the message with UID 34).
+
+
+
+
+Melnikov                     Informational                     [Page 16]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   3) Temporarily remove \Deleted flag on all messages found in step 2.
+
+      C: A002 UID STORE 34 -FLAGS.SILENT (\Deleted)
+      S: A002 UID STORE completed
+
+   4) Expunge the mailbox.
+
+      C: A003 EXPUNGE
+      S: * 20 EXPUNGE
+      S: * 7 EXPUNGE
+      S: * 1 EXPUNGE
+      S: A003 EXPUNGE completed
+
+      Here, the message with UID 7 has message number 1, with UID 27 has
+      message number 7, and with UID 65 has message number 20.
+
+   5) Restore \Deleted flag on all messages found when performing step
+      2.
+
+      C: A004 UID STORE 34 +FLAGS.SILENT (\Deleted)
+      S: A004 UID STORE completed
+
+4.2.5.  Closing a Mailbox
+
+   When the disconnected client has to close a mailbox, it should not
+   use the CLOSE command, because CLOSE does a silent EXPUNGE.  (Section
+   4.2.4 explains why EXPUNGE should not be used by a disconnected
+   client.)  It is safe to use CLOSE only if the mailbox was opened with
+   EXAMINE.
+
+   If the mailbox was opened with SELECT, the client can use one of the
+   following commands to implicitly close the mailbox and prevent the
+   silent expunge:
+
+   1) UNSELECT - This is a command described in [UNSELECT] that works as
+      CLOSE, but doesn't cause the silent EXPUNGE.  This command is
+      supported by the server if it reports UNSELECT in its CAPABILITY
+      list.
+
+   2) SELECT <another_mailbox> - SELECT causes implicit CLOSE without
+      EXPUNGE.
+
+   3) If the client intends to issue LOGOUT after closing the mailbox,
+      it may just issue LOGOUT, because LOGOUT causes implicit CLOSE
+      without EXPUNGE as well.
+
+   4) SELECT <non_existing_mailbox> - If the client knows a mailbox that
+      doesn't exist or can't be selected, it MAY SELECT it.
+
+
+
+Melnikov                     Informational                     [Page 17]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   If the client opened the mailbox with SELECT and just wants to avoid
+   implicit EXPUNGE without closing the mailbox, it may also use the
+   following:
+
+   5) EXAMINE <mailbox> - Reselect the same mailbox in read-only mode.
+
+4.3.  Details of "Normal" Synchronization of a Single Mailbox
+
+   The most common form of synchronization is where the human trusts the
+   integrity of the client's copy of the state of a particular mailbox
+   and simply wants to bring the client's cache up to date so that it
+   accurately reflects the mailbox's current state on the server.
+
+4.3.1.  Discovering New Messages and Changes to Old Messages
+
+   Let <lastseenuid> represent the highest UID that the client knows
+   about in this mailbox.  Since UIDs are allocated in strictly
+   ascending order, this is simply the UID of the last message in the
+   mailbox that the client knows about.  Let <lastseenuid+1> represent
+   <lastseenuid>'s UID plus one.  Let <descriptors> represent a list
+   consisting of all the FETCH data item items that the implementation
+   considers part of the descriptor; at a minimum this is just the FLAGS
+   data item, but it usually also includes BODYSTRUCTURE and
+   RFC822.SIZE.  At this step, <descriptors> SHOULD NOT include RFC822.
+
+   With no further information, the client can issue the following two
+   commands:
+
+      tag1 UID FETCH <lastseenuid+1>:* <descriptors>
+      tag2 UID FETCH 1:<lastseenuid> FLAGS
+
+   The first command will request some information about "new" messages
+   (i.e., messages received by the server since the last
+   synchronization).  It will also allow the client to build a message
+   number to UID map (only for new messages).  The second command allows
+   the client to
+
+      1) update cached flags for old messages;
+
+      2) find out which old messages got expunged; and
+
+      3) build a mapping between message numbers and UIDs (for old
+         messages).
+
+   The order here is significant.  We want the server to start returning
+   the list of new message descriptors as fast as it can, so that the
+   client can start issuing more FETCH commands, so we start out by
+   asking for the descriptors of all the messages we know the client
+
+
+
+Melnikov                     Informational                     [Page 18]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   cannot possibly have cached yet.  The second command fetches the
+   information we need to determine what changes may have occurred to
+   messages that the client already has cached.  Note that the former
+   command should only be issued if the UIDNEXT value cached by the
+   client differs from the one returned by the server.  Once the client
+   has issued these two commands, there's nothing more the client can do
+   with this mailbox until the responses to the first command start
+   arriving.  A clever synchronization program might use this time to
+   fetch its local cache state from disk or to start the process of
+   synchronizing another mailbox.
+
+   The following is an example of the first FETCH:
+
+   C: A011 UID fetch 131:* (FLAGS BODYSTRUCTURE INTERNALDATE
+       RFC822.SIZE)
+
+   Note 1: The first FETCH may result in the server's sending a huge
+   volume of data.  A smart disconnected client should use message
+   ranges (see also Section 3.2.1.2 of [RFC2683]), so that the user is
+   able to execute a different operation between fetching information
+   for a group of new messages.
+
+   Example 7:
+
+   Knowing the new UIDNEXT returned by the server on SELECT or EXAMINE
+   (<uidnext>), the client can split the UID range
+   <lastseenuid+1>:<uidnext> into groups, e.g., 100 messages.  After
+   that, the client can issue:
+
+      C: A011 UID fetch <lastseenuid+1>:<lastseenuid+100>
+          (FLAGS BODYSTRUCTURE INTERNALDATE RFC822.SIZE)
+      ...
+      C: A012 UID fetch <lastseenuid+101>:<lastseenuid+200>
+          (FLAGS BODYSTRUCTURE INTERNALDATE RFC822.SIZE)
+      ...
+      ...
+      C: A0FF UID fetch <lastseenuid+901>:<uidnext>
+          (FLAGS BODYSTRUCTURE INTERNALDATE RFC822.SIZE)
+
+   Note that unless a SEARCH command is issued, it is impossible to
+   determine how many messages will fall into a subrange, as UIDs are
+   not necessarily contiguous.
+
+   Note 2: The client SHOULD ignore any unsolicited EXPUNGE responses
+   received during the first FETCH command.  EXPUNGE responses contain
+   message numbers that are useless to a client that doesn't have the
+   message-number-to-UID translation table.
+
+
+
+
+Melnikov                     Informational                     [Page 19]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   The second FETCH command will result in zero or more untagged fetch
+   responses.  Each response will have a corresponding UID FETCH data
+   item.  All messages that didn't have a matching untagged FETCH
+   response MUST be removed from the local cache.
+
+   For example, if the <lastseenuid> had a value 15000 and the local
+   cache contained 3 messages with the UIDs 12, 777, and 14999,
+   respectively, then after receiving the following responses from the
+   server, the client must remove the message with UID 14999 from its
+   local cache.
+
+      S: * 1 FETCH (UID 12 FLAGS (\Seen))
+      S: * 2 FETCH (UID 777 FLAGS (\Answered \Deleted))
+
+   Note 3: If the client is not interested in flag changes (i.e., the
+   client only wants to know which old messages are still on the
+   server), the second FETCH command can be substituted with:
+
+      tag2 UID SEARCH UID 1:<lastseenuid>
+
+   This command will generate less traffic.  However, an implementor
+   should be aware that in order to build the mapping table from message
+   numbers to UIDs, the output of the SEARCH command MUST be sorted
+   first, because there is no requirement for a server to return UIDs in
+   SEARCH response in any particular order.
+
+4.3.2.  Searching for "Interesting" Messages.
+
+   This step is performed entirely on the client (from the information
+   received in the step described in 4.3.1), entirely on the server, or
+   on some combination of both.  The decision on what is an
+   "interesting" message is up to the client software and the human.
+   One easy criterion that should probably be implemented in any client
+   is whether the message is "too big" for automatic retrieval, where
+   "too big" is a parameter defined in the client's configuration.
+
+   Another commonly used criterion is the age of a message.  For
+   example, the client may choose to download only messages received in
+   the last week (in this case, <date> would be today's date minus 7
+   days):
+
+      tag3 UID SEARCH UID <uidset> SINCE <date>
+
+   Keep in mind that a date search disregards time and time zone.  The
+   client can avoid doing this search if it specified INTERNALDATE in
+   <descriptors> on the step described in 4.3.1.  If the client did, it
+   can perform the local search on its message cache.
+
+
+
+
+Melnikov                     Informational                     [Page 20]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   At this step, the client also decides what kind of information about
+   a particular message to fetch from the server.  In particular, even
+   for a message that is considered "too big", the client MAY choose to
+   fetch some part(s) of it.  For example, if the message is a
+   multipart/mixed containing a text part and a MPEG attachment, there
+   is no reason for the client not to fetch the text part.  The decision
+   of which part should or should not be fetched can be based on the
+   information received in the BODYSTRUCTURE FETCH response data item
+   (i.e., if BODYSTRUCTURE was included in <descriptors> on the step
+   described in 4.3.1).
+
+4.3.3.  Populating Cache with "Interesting" Messages.
+
+   Once the client has found out which messages are "interesting", it
+   can start issuing appropriate FETCH commands for "interesting"
+   messages or parts thereof.
+
+   Note that fetching a message into the disconnected client's local
+   cache does NOT imply that the human has (or even will) read the
+   message.  Thus, the synchronization program for a disconnected client
+   should always be careful to use the .PEEK variants of the FETCH data
+   items that implicitly set the \Seen flag.
+
+   Once the last descriptor has arrived and the last FETCH command has
+   been issued, the client simply needs to process the incoming fetch
+   items and use them to update the local message cache.
+
+   In order to avoid deadlock problems, the client must give processing
+   of received messages priority over issuing new FETCH commands during
+   this synchronization process.  This may necessitate temporary local
+   queuing of FETCH requests that cannot be issued without causing a
+   deadlock.  In order to achieve the best use of the "expensive"
+   network connection, the client will almost certainly need to pay
+   careful attention to any flow-control information that it can obtain
+   from the underlying transport connection (usually a TCP connection).
+
+   Note: The requirement stated in the previous paragraph might result
+   in an unpleasant user experience, if followed blindly.  For example,
+   the user might be unwilling to wait for the client to finish
+   synchronization before starting to process the user's requests.  A
+   smart disconnected client should allow the user to perform requested
+   operations in between IMAP commands that are part of the
+   synchronization process.  See also Note 1 in Section 4.3.1.
+
+
+
+
+
+
+
+
+Melnikov                     Informational                     [Page 21]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   Example 8:
+
+   After fetching a message BODYSTRUCTURE, the client discovers a
+   complex MIME message.  Then, it decides to fetch MIME headers of the
+   nested MIME messages and some body parts.
+
+   C: A011 UID fetch 11 (BODYSTRUCTURE)
+   S: ...
+   C: A012 UID fetch 11 (BODY[HEADER] BODY[1.MIME] BODY[1.1.MIME]
+       BODY[1.2.MIME] BODY[2.MIME] BODY[3.MIME] BODY[4.MIME]
+       BODY[5.MIME] BODY[6.MIME] BODY[7.MIME] BODY[8.MIME] BODY[9.MIME]
+       BODY[10.MIME] BODY[11.MIME] BODY[12.MIME] BODY[13.MIME]
+       BODY[14.MIME] BODY[15.MIME] BODY[16.MIME] BODY[17.MIME]
+       BODY[18.MIME] BODY[19.MIME] BODY[20.MIME] BODY[21.MIME])
+   S: ...
+   C: A013 UID fetch 11 (BODY[1.1] BODY[1.2])
+   S: ...
+   C: A014 UID fetch 11 (BODY[3] BODY[4] BODY[5] BODY[6] BODY[7] BODY[8]
+       BODY[9] BODY[10] BODY[11] BODY[13] BODY[14] BODY[15] BODY[16]
+       BODY[21])
+   S: ...
+
+4.3.4.  User-Initiated Synchronization
+
+   After the client has finished the main synchronization process as
+   described in Sections 4.3.1-4.3.3, the user may optionally request
+   additional synchronization steps while the client is still online.
+   This is not any different from the process described in Sections
+   4.3.2 and 4.3.3.
+
+   Typical examples are:
+
+    1) fetch all messages selected in UI.
+    2) fetch all messages marked as \Flagged on the server.
+
+4.4.  Special Case: Descriptor-Only Synchronization
+
+   For some mailboxes, fetching the descriptors might be the entire
+   synchronization step.  Practical experience with IMAP has shown that
+   a certain class of mailboxes (e.g., "archival" mailboxes) are used
+   primarily for long-term storage of important messages that the human
+   wants to have instantly available on demand but does not want
+   cluttering up the disconnected client's cache at any other time.
+   Messages in this kind of mailbox would be fetched exclusively by
+   explicit actions queued by the local MUA.  Thus, the only
+   synchronization desirable on this kind of mailbox is fetching enough
+   descriptor information for the user to be able to identify messages
+   for subsequent download.
+
+
+
+Melnikov                     Informational                     [Page 22]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   Special mailboxes that receive messages from a high volume, low
+   priority mailing list might also be in this category, at least when
+   the human is in a hurry.
+
+4.5.  Special Case: Fast New-Only Synchronization
+
+   In some cases, the human might be in such a hurry that he or she
+   doesn't care about changes to old messages, just about new messages.
+   In this case, the client can skip the UID FETCH command that obtains
+   the flags and UIDs for old messages (1:<lastseenuid>).
+
+4.6.  Special Case: Blind FETCH
+
+   In some cases, the human may know (for whatever reason) that he or
+   she always wants to fetch any new messages in a particular mailbox,
+   unconditionally.  In this case, the client can just fetch the
+   messages themselves, rather than just the descriptors, by using a
+   command like:
+
+      tag1 UID FETCH <lastseenuid+1>:* (FLAGS BODY.PEEK[])
+
+   Note that this example ignores the fact that the messages can be
+   arbitrary long.  The disconnected client MUST always check for
+   message size before downloading, unless explicitly told otherwise.  A
+   well-behaved client should instead use something like the following:
+
+   1) Issue "tag1 UID FETCH <lastseenuid+1>:* (FLAGS RFC822.SIZE)".
+
+   2) From the message sizes returned in step 1, construct UID set
+      <required_messages>.
+
+   3) Issue "tag2 UID FETCH <required_messages> (BODY.PEEK[])".
+
+   or
+
+   1) Issue "tag1 UID FETCH <lastseenuid+1>:* (FLAGS)".
+
+   2) Construct UID set <old_uids> from the responses of step 1.
+
+   3) Issue "tag2 SEARCH UID <old_uids> SMALLER <message_limit>".
+      Construct UID set <required_messages> from the result of the
+      SEARCH command.
+
+   4) Issue "tag3 UID FETCH <required_messages> (BODY.PEEK[])".
+
+
+
+
+
+
+
+Melnikov                     Informational                     [Page 23]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   or
+
+   1) Issue "tag1 UID FETCH <lastseenuid+1>:* (FLAGS
+      BODY.PEEK[]<0.<length>>)", where <length> should be replaced with
+      the maximal message size the client is willing to download.
+
+      Note: In response to such a command, the server will only return
+      partial data if the message is longer than <length>.  It will
+      return the full message data for any message whose size is smaller
+      than or equal to <length>.  In the former case, the client will
+      not be able to extract the full MIME structure of the message from
+      the truncated data, so the client should include BODYSTRUCTURE in
+      the UID FETCH command as well.
+
+5.  Implementation Considerations
+
+   Below are listed some common implementation pitfalls that should be
+   considered when implementing a disconnected client.
+
+   1) Implementing fake UIDs on the client.
+
+      A message scheduled to be uploaded has no UID, as UIDs are
+      selected by the server.  The client may implement fake UIDs
+      internally in order to reference not-yet-uploaded messages in
+      further operations.  (For example, a message could be scheduled to
+      be uploaded, but subsequently marked as deleted or copied to
+      another mailbox).  Here, the client MUST NOT under any
+      circumstances send these fake UIDs to the server.  Also, client
+      implementers should be reminded that according to [IMAP4] a UID is
+      a 32-bit unsigned integer excluding 0.  So, both 4294967295 and
+      2147483648 are valid UIDs, and 0 and -1 are both invalid.  Some
+      disconnected mail clients have been known to send negative numbers
+      (e.g., "-1") as message UIDs to servers during synchronization.
+
+      Situation 1: The user starts composing a new message, edits it,
+      saves it, continues to edit it, and saves it again.
+
+      A disconnected client may record in its replay log (log of
+      operations to be replayed on the server during synchronization)
+      the sequence of operations as shown below.  For the purpose of
+      this situation, we assume that all draft messages are stored in
+      the mailbox called Drafts on an IMAP server.  We will also use the
+      following conventions:  <old_uid> is the UID of the intermediate
+      version of the draft when it was saved for the first time.  This
+      is a fake UID generated on the client.  <new_uid> is the UID of
+      the final version of the draft.  This is another fake UID
+      generated on the client.
+
+
+
+
+Melnikov                     Informational                     [Page 24]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+      1) APPEND Drafts (\Seen $MDNSent \Drafts) {<nnn>}
+         ...first version of the message follows...
+
+      2) APPEND Drafts (\Seen $MDNSent \Drafts) {<mmm>}
+         ...final version of the message follows...
+
+      3) STORE <old_uid> +FLAGS (\Deleted)
+
+      Step 1 corresponds to the first attempt to save the draft message,
+      step 2 corresponds to the second attempt to save the draft
+      message, and step 3 deletes the first version of the draft message
+      saved in step 1.
+
+      A naive disconnected client may send the command in step 3 without
+      replacing the fake client generated <old_uid> with the value
+      returned by the server in step 1.  A server will probably reject
+      this command, which will make the client believe that the
+      synchronization sequence has failed.
+
+   2) Section 5.1 discusses common implementation errors related to
+      error recovery during playback.
+
+   3) Don't assume that the disconnected client is the only client used
+      by the user.
+
+      Situation 2: Some clients may use the \Deleted flag as an
+      indicator that the message should not appear in the user's view.
+      Usage of the \Deleted flag for this purpose is not safe, as other
+      clients (e.g., online clients) might EXPUNGE the mailbox at any
+      time.
+
+   4) Beware of data dependencies between synchronization operations.
+
+      It might be very tempting for a client writer to perform some
+      optimizations on the playback log.  Such optimizations might
+      include removing redundant operations (for example, see
+      optimization 2 in Section 5.3), or their reordering.
+
+      It is not always safe to reorder or remove redundant operations
+      during synchronization because some operations may have
+      dependencies (as Situation 3 demonstrates).  So, if in doubt,
+      don't do this.
+
+      Situation 3: The user copies a message out of a mailbox and then
+      deletes the mailbox.
+
+
+
+
+
+
+Melnikov                     Informational                     [Page 25]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+         C: A001 SELECT Old-Mail
+         S: ...
+         C: A002 UID COPY 111 ToDo
+         S: A002 OK [COPYUID 1022843345 111 94] Copy completed
+         ...
+         C: A015 CLOSE
+         S: A015 OK Completed
+         C: A016 DELETE Old-Mail
+         S: A016 OK Mailbox deletion completed successfully
+
+      If the client performs DELETE (tag A016) first and COPY (tag A002)
+      second, then the COPY fails.  Also, the message that the user so
+      carefully copied into another mailbox has been lost.
+
+5.1.  Error Recovery during Playback
+
+   Error recovery during synchronization is one of the trickiest parts
+   to get right.  Below, we will discuss certain error conditions and
+   suggest possible choices for handling them.
+
+   1) Lost connection to the server.
+
+      The client MUST remember the current position in the playback
+      (replay) log and replay it starting from the interrupted operation
+      (the last command issued by the client, but not acknowledged by
+      the server) the next time it successfully connects to the same
+      server.  If the connection was lost while executing a non-
+      idempotent IMAP command (see the definition in Section 1), then
+      when the client is reconnected, it MUST make sure that the
+      interrupted command was indeed not executed.  If it wasn't
+      executed, the client must restart playback from the interrupted
+      command, otherwise from the following command.
+
+      Upon reconnect, care must be taken in order to properly reapply
+      logical operations that are represented by multiple IMAP commands,
+      e.g., UID EXPUNGE emulation when UID EXPUNGE is not supported by
+      the server (see Section 4.2.4).
+
+      Once the client detects that the connection to the server was
+      lost, it MUST stop replaying its log.  There are existing
+      disconnected clients that, to the great annoyance of users, pop up
+      an error dialog for each and every playback operation that fails.
+
+   2) Copying/appending messages to a mailbox that doesn't exist.  (The
+      server advertises this condition by sending the TRYCREATE response
+      code in the tagged NO response to the APPEND or COPY command.)
+
+
+
+
+
+Melnikov                     Informational                     [Page 26]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+      The user should be advised about the situation and be given one of
+      the following choices:
+
+      a) Try to recreate a mailbox.
+      b) Copy/upload messages to another mailbox.
+      c) Skip copy/upload.
+      d) Abort replay.
+
+   3) Copying messages from a mailbox that doesn't exist, or renaming or
+      getting/changing ACLs [ACL] on a mailbox that doesn't exist:
+
+      a) Skip operation.
+      b) Abort replay.
+
+   4) Deleting mailboxes or deleting/expunging messages that no longer
+      exist.
+
+      This is actually is not an error and should be ignored by the
+      client.
+
+   5) Performing operations on messages that no longer exist.
+
+      a) Skip operation.
+      b) Abort replay.
+
+      In the case of changing flags on an expunged message, the client
+      should silently ignore the error.
+
+   Note 1: Several synchronization operations map to multiple IMAP
+   commands (for example, "move" described in 4.2.2).  The client must
+   guarantee atomicity of each such multistep operation.  For example,
+   when performing a "move" between two mailboxes on the same server, if
+   the server is unable to copy messages, the client MUST NOT attempt to
+   set the \Deleted flag on the messages being copied, let alone expunge
+   them.  However, the client MAY consider that move operation to have
+   succeeded even if the server was unable to set the \Deleted flag on
+   copied messages.
+
+   Note 2: Many synchronization operations have data dependencies.  A
+   failed operation must cause all dependent operations to fail as well.
+   The client should check this and MUST NOT try to perform all
+   dependent operations blindly (unless the user corrected the original
+   problem).  For example, a message may be scheduled to be appended to
+   a mailbox on the server and later on the appended message may be
+   copied to another mailbox.  If the APPEND operation fails, the client
+   must not attempt to COPY the failed message later on.  (See also
+   Section 5, Situation 3).
+
+
+
+
+Melnikov                     Informational                     [Page 27]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+5.2.  Quality of Implementation Issues
+
+   Below, some quality of implementation issues are listed for
+   disconnected clients.  They will help to write a disconnected client
+   that works correctly, performs synchronization as quickly as possible
+   (and thus can make the user happier as well as save her some money),
+   and minimizes the server load:
+
+   1) Don't lose information.
+
+      No matter how smart your client is in other areas, if it loses
+      information, users will get very upset.
+
+   2) Don't do work unless explicitly asked.  Be flexible.  Ask all
+      questions BEFORE starting synchronization, if possible.
+
+   3) Minimize traffic.
+
+      The client MUST NOT issue a command if the client already received
+      the required information from the server.
+
+      The client MUST make use of UIDPLUS extension if it is supported
+      by the server.
+
+      See also optimization 1 in Section 5.3.
+
+   4) Minimize the number of round-trips.
+
+      Round-trips kill performance, especially on links with high
+      latency.  Sections 4.2.2.5 and 5.2 give some advice on how to
+      minimize the number of round-trips.
+
+      See also optimization 1 in Section 5.3.
+
+5.3.  Optimizations
+
+   Some useful optimizations are described in this section.  A
+   disconnected client that supports the recommendations listed below
+   will give the user a more pleasant experience.
+
+   1) The initial OK or PREAUTH responses may contain the CAPABILITY
+      response code as described in Section 7.1 of [IMAP4].  This
+      response code gives the same information as returned by the
+      CAPABILITY command*.  A disconnected client that pays attention to
+      this response code can avoid sending CAPABILITY command and will
+      save a round-trip.
+
+
+
+
+
+Melnikov                     Informational                     [Page 28]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+      * Note: Some servers report in the CAPABILITY response code
+        extensions that are only relevant in unauthenticated state or in
+        all states.  Such servers usually send another CAPABILITY
+        response code upon successful authentication using LOGIN or
+        AUTHENTICATE command (that negotiates no security layer; see
+        Section 6.2.2 of [IMAP4]).  The CAPABILITY response code sent
+        upon successful LOGIN/AUTHENTICATE might be different from the
+        CAPABILITY response code in the initial OK response, as
+        extensions only relevant for unauthenticated state will not be
+        advertised, and some additional extensions available only in
+        authenticated and/or selected state will be.
+
+   Example 9:
+
+   S: * OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS
+       AUTH=DIGEST-MD5 AUTH=SRP] imap.example.com ready
+   C: 2 authenticate DIGEST-MD5
+   S: 2 OK [CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS SCAN
+       SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND]
+       User authenticated (no layer)
+
+   2) An advanced disconnected client may choose to optimize its replay
+      log.  For example, there might be some operations that are
+      redundant (the list is not complete):
+
+      a) an EXPUNGE followed by another EXPUNGE or CLOSE;
+      b) changing flags (other than the \Deleted flag) on a message that
+         gets immediately expunged;
+      c) opening and closing the same mailbox.
+
+   When optimizing, be careful about data dependencies between commands.
+   For example, if the client is wishing to optimize (see case b, above)
+
+      tag1 UID STORE <uid1> +FLAGS (\Deleted)
+      ...
+      tag2 UID STORE <uid1> +FLAGS (\Flagged)
+      ...
+      tag3 UID COPY <uid1> "Backup"
+      ...
+      tag4 UID EXPUNGE <uid1>
+
+   it can't remove the second UID STORE command because the message is
+   being copied before it gets expunged.
+
+   In general, it might be a good idea to keep mailboxes open during
+   synchronization (see case c above), if possible.  This can be more
+   easily achieved in conjunction with optimization 3 described below.
+
+
+
+
+Melnikov                     Informational                     [Page 29]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   3) Perform some synchronization steps in parallel, if possible.
+
+      Several synchronization steps don't depend on each other and thus
+      can be performed in parallel.  Because the server machine is
+      usually more powerful than the client machine and can perform some
+      operations in parallel, this may speed up the total time of
+      synchronization.
+
+      In order to achieve such parallelization, the client will have to
+      open more than one connection to the same server.  Client writers
+      should not forget about non-trivial cost associated with
+      establishing a TCP connection and performing an authentication.
+      The disconnected client MUST NOT use one connection per mailbox.
+      In most cases, it is sufficient to have two connections.  The
+      disconnected client SHOULD avoid selecting the same mailbox in
+      more than one connection; see Section 3.1.1 of [RFC2683] for more
+      details.
+
+      Any mailbox synchronization MUST start with checking the
+      UIDVALIDITY as described in Section 4.1 of this document.  The
+      client MAY use STATUS command to check UID Validity of a non-
+      selected mailbox.  This is preferable to opening many connections
+      to the same server to perform synchronization of multiple
+      mailboxes simultaneously.  As described in Section 5.3.10 of
+      [IMAP4], this SHOULD NOT be used on the selected mailbox.
+
+6.  IMAP Extensions That May Help
+
+   The following extensions can save traffic and/or the number of
+   round-trips:
+
+   1) The use of [UIDPLUS] is discussed in Sections 4.1, 4.2.1, 4.2.2.1
+      and 4.2.4.
+
+   2) The use of the MULTIAPPEND and LITERAL+ extensions for uploading
+      messages is discussed in Section 4.2.2.5.
+
+   3) Use the CONDSTORE extension (see Section 6.1) for quick flag
+      resynchronization.
+
+6.1.  CONDSTORE Extension
+
+   An advanced disconnected mail client should use the [CONDSTORE]
+   extension when it is supported by the server.  The client must cache
+   the value from HIGHESTMODSEQ OK response code received on mailbox
+   opening and update it whenever the server sends MODSEQ FETCH data
+   items.
+
+
+
+
+Melnikov                     Informational                     [Page 30]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+   If the client receives NOMODSEQ OK untagged response instead of
+   HIGHESTMODSEQ, it MUST remove the last known HIGHESTMODSEQ value from
+   its cache and follow the more general instructions in Section 3.
+
+   When the client opens the mailbox for synchronization, it first
+   compares UIDVALIDITY as described in step d-1 in Section 3.  If the
+   cached UIDVALIDITY value matches the one returned by the server, the
+   client MUST compare the cached value of HIGHESTMODSEQ with the one
+   returned by the server.  If the cached HIGHESTMODSEQ value also
+   matches the one returned by the server, then the client MUST NOT
+   fetch flags for cached messages, as they hasn't changed.  If the
+   value on the server is higher than the cached one, the client MAY use
+   "SEARCH MODSEQ <cached-value>" to find all messages with flags
+   changed since the last time the client was online and had the mailbox
+   opened.  Alternatively, the client MAY use "FETCH 1:* (FLAGS)
+   (CHANGEDSINCE <cached-value>)".  The latter operation combines
+   searching for changed messages and fetching new information.
+
+   In all cases, the client still needs to fetch information about new
+   messages (if requested by the user) as well as discover which
+   messages have been expunged.
+
+   Step d ("Server-to-client synchronization") in Section 4 in the
+   presence of the CONDSTORE extension is amended as follows:
+
+   d) "Server-to-client synchronization" - For each mailbox that
+      requires synchronization, do the following:
+
+      1a) Check the mailbox UIDVALIDITY (see section 4.1 for more
+          details) with SELECT/EXAMINE/STATUS.
+
+          If the UIDVALIDITY value returned by the server differs, the
+          client MUST
+
+          * empty the local cache of that mailbox;
+          * "forget" the cached HIGHESTMODSEQ value for the mailbox;
+          * remove any pending "actions" that refer to UIDs in that
+            mailbox (note that this doesn't affect actions performed on
+            client-generated fake UIDs; see Section 5); and
+          * skip steps 1b and 2-II;
+
+      1b) Check the mailbox HIGHESTMODSEQ.  If the cached value is the
+          same as the one returned by the server, skip fetching message
+          flags on step 2-II, i.e., the client only has to find out
+          which messages got expunged.
+
+
+
+
+
+
+Melnikov                     Informational                     [Page 31]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+      2) Fetch the current "descriptors".
+
+         I)  Discover new messages.
+
+         II) Discover changes to old messages and flags for new messages
+             using
+             "FETCH 1:* (FLAGS) (CHANGEDSINCE <cached-value>)" or
+             "SEARCH MODSEQ <cached-value>".
+
+             Discover expunged messages; for example, using
+             "UID SEARCH 1:<lastseenuid>".  (All messages not returned
+             in this command are expunged.)
+
+      3) Fetch the bodies of any "interesting" messages that the client
+         doesn't already have.
+
+         Example 10:
+
+         The UIDVALIDITY value is the same, but the HIGHESTMODSEQ value
+         has changed on the server while the client was offline.
+
+      C: A142 SELECT INBOX
+      S: * 172 EXISTS
+      S: * 1 RECENT
+      S: * OK [UNSEEN 12] Message 12 is first unseen
+      S: * OK [UIDVALIDITY 3857529045] UIDs valid
+      S: * OK [UIDNEXT 201] Predicted next UID
+      S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+      S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
+      S: * OK [HIGHESTMODSEQ 20010715194045007]
+      S: A142 OK [READ-WRITE] SELECT completed
+
+   After that, either:
+
+      C: A143 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 20010715194032001)
+      S: * 2 FETCH (UID 6 MODSEQ (20010715205008000) FLAGS (\Deleted))
+      S: * 5 FETCH (UID 9 MODSEQ (20010715195517000) FLAGS ($NoJunk
+          $AutoJunk $MDNSent))
+         ...
+      S: A143 OK FETCH completed
+
+   or:
+
+
+
+
+
+
+
+
+
+Melnikov                     Informational                     [Page 32]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+      C: A143 UID SEARCH MODSEQ 20010715194032001 UID 1:20
+      S: * SEARCH 6 9 11 12 18 19 20 23 (MODSEQ 20010917162500)
+      S: A143 OK Search complete
+      C: A144 UID SEARCH 1:20
+      S: * SEARCH 6 9 ...
+      S: A144 OK FETCH completed
+
+7.  Security Considerations
+
+   It is believed that this document does not raise any new security
+   concerns that are not already present in the base [IMAP4] protocol,
+   and these issues are discussed in [IMAP4].  Additional security
+   considerations may be found in different extensions mentioned in this
+   document; in particular, in [UIDPLUS], [LITERAL+], [CONDSTORE],
+   [MULTIAPPEND], and [UNSELECT].
+
+   Implementers are also reminded about the importance of thorough
+   testing.
+
+8.  References
+
+8.1.  Normative References
+
+   [KEYWORDS]    Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [IMAP4]       Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
+                 VERSION 4rev1", RFC 3501, March 2003.
+
+   [UIDPLUS]     Crispin, M., "Internet Message Access Protocol (IMAP) -
+                 UIDPLUS extension", RFC 4315, December 2005.
+
+   [LITERAL+]    Myers, J., "IMAP4 non-synchronizing literals", RFC
+                 2088, January 1997.
+
+   [CONDSTORE]   Melnikov, A. and S. Hole, "IMAP Extension for
+                 Conditional STORE Operation or Quick Flag Changes
+                 Resynchronization", RFC 4551, June 2006.
+
+   [MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) -
+                 MULTIAPPEND Extension", RFC 3502, March 2003.
+
+   [UNSELECT]    Melnikov, A., "Internet Message Access Protocol (IMAP)
+                 UNSELECT command", RFC 3691, February 2004.
+
+   [RFC2683]     Leiba, B., "IMAP4 Implementation Recommendations", RFC
+                 2683, September 1999.
+
+
+
+
+Melnikov                     Informational                     [Page 33]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+8.2.  Informative References
+
+   [ACL]         Melnikov, A., "IMAP4 Access Control List (ACL)
+                 Extension", RFC 4314, December 2005.
+
+   [IMAP-MODEL]  Crispin, M., "Distributed Electronic Mail Models in
+                 IMAP4", RFC 1733, December 1994.
+
+9.  Acknowledgements
+
+   This document is based on version 01 of the text written by Rob
+   Austein in November 1994.
+
+   The editor appreciates comments posted by Mark Crispin to the IMAP
+   mailing list and the comments/corrections/ideas received from Grant
+   Baillie, Cyrus Daboo, John G. Myers, Chris Newman, and Timo Sirainen.
+
+   The editor would also like to thank the developers of Netscape
+   Messenger and Mozilla mail clients for providing examples of
+   disconnected mail clients that served as a base for many
+   recommendations in this document.
+
+Editor's Address
+
+   Alexey Melnikov
+   Isode Limited
+   5 Castle Business Village
+   36 Station Road
+   Hampton, Middlesex
+   TW12 2BX
+   United Kingdom
+
+   Phone: +44 77 53759732
+   EMail: alexey.melnikov@isode.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov                     Informational                     [Page 34]
+
+RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Melnikov                     Informational                     [Page 35]
+
diff --git a/docs/rfcs/rfc4551.txt b/docs/rfcs/rfc4551.txt
new file mode 100644
index 0000000..894b510
--- /dev/null
+++ b/docs/rfcs/rfc4551.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group                                        A. Melnikov
+Request for Comments: 4551                                    Isode Ltd.
+Updates: 3501                                                    S. Hole
+Category: Standards Track                  ACI WorldWide/MessagingDirect
+                                                               June 2006
+
+
+             IMAP Extension for Conditional STORE Operation
+                or Quick Flag Changes Resynchronization
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
+   a common IMAP mailbox.  Examples include different clients working on
+   behalf of the same user, and multiple users accessing shared
+   mailboxes.  These clients need a mechanism to synchronize state
+   changes for messages within the mailbox.  They must be able to
+   guarantee that only one client can change message state (e.g.,
+   message flags) at any time.  An example of such an application is use
+   of an IMAP mailbox as a message queue with multiple dequeueing
+   clients.
+
+   The Conditional Store facility provides a protected update mechanism
+   for message state information that can detect and resolve conflicts
+   between multiple writing mail clients.
+
+   The Conditional Store facility also allows a client to quickly
+   resynchronize mailbox flag changes.
+
+   This document defines an extension to IMAP (RFC 3501).
+
+
+
+
+
+
+
+
+
+Melnikov & Hole             Standards Track                     [Page 1]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+Table of Contents
+
+   1.  Introduction and Overview ................................. 3
+   2.  Conventions Used in This Document ......................... 5
+   3.  IMAP Protocol Changes ..................................... 6
+   3.1. New OK untagged responses for SELECT and EXAMINE ......... 6
+   3.1.1. HIGHESTMODSEQ response code ............................ 6
+   3.1.2. NOMODSEQ response code ................................. 7
+   3.2. STORE and UID STORE Commands ............................. 7
+   3.3 FETCH and UID FETCH Commands ..............................13
+   3.3.1. CHANGEDSINCE FETCH modifier ............................13
+   3.3.2. MODSEQ message data item in FETCH Command ..............14
+   3.4. MODSEQ search criterion in SEARCH ........................16
+   3.5. Modified SEARCH untagged response ........................17
+   3.6. HIGHESTMODSEQ status data items ..........................17
+   3.7. CONDSTORE parameter to SELECT and EXAMINE ................18
+   3.8. Additional quality of implementation issues ..............18
+   4.  Formal Syntax .............................................19
+   5.  Server implementation considerations ......................21
+   6.  Security Considerations ...................................22
+   7.  IANA Considerations .......................................22
+   8.  References ................................................23
+   8.1. Normative References .....................................23
+   8.2. Informative References ...................................23
+   9.  Acknowledgements ..........................................23
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov & Hole             Standards Track                     [Page 2]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+1. Introduction and Overview
+
+   The Conditional STORE extension is present in any IMAP4
+   implementation that returns "CONDSTORE" as one of the supported
+   capabilities in the CAPABILITY command response.
+
+   An IMAP server that supports this extension MUST associate a positive
+   unsigned 64-bit value called a modification sequence (mod-sequence)
+   with every IMAP message.  This is an opaque value updated by the
+   server whenever a metadata item is modified.  The server MUST
+   guarantee that each STORE command performed on the same mailbox
+   (including simultaneous stores to different metadata items from
+   different connections) will get a different mod-sequence value.
+   Also, for any two successful STORE operations performed in the same
+   session on the same mailbox, the mod-sequence of the second completed
+   operation MUST be greater than the mod-sequence of the first
+   completed.  Note that the latter rule disallows the use of the system
+   clock as a mod-sequence, because if system time changes (e.g., an NTP
+   [NTP] client adjusting the time), the next generated value might be
+   less than the previous one.
+
+   Mod-sequences allow a client that supports the CONDSTORE extension to
+   determine if a message metadata has changed since some known moment.
+   Whenever the state of a flag changes (i.e., the flag is added where
+   previously it wasn't set, or the flag is removed and before it was
+   set) the value of the modification sequence for the message MUST be
+   updated.  Adding the flag when it is already present or removing when
+   it is not present SHOULD NOT change the mod-sequence.
+
+   When a message is appended to a mailbox (via the IMAP APPEND command,
+   COPY to the mailbox, or using an external mechanism) the server
+   generates a new modification sequence that is higher than the highest
+   modification sequence of all messages in the mailbox and assigns it
+   to the appended message.
+
+   The server MAY store separate (per-message) modification sequence
+   values for different metadata items.  If the server does so, per-
+   message mod-sequence is the highest mod-sequence of all metadata
+   items for the specified message.
+
+   The server that supports this extension is not required to be able to
+   store mod-sequences for every available mailbox.  Section 3.1.2
+   describes how the server may act if a particular mailbox doesn't
+   support the persistent storage of mod-sequences.
+
+
+
+
+
+
+
+Melnikov & Hole             Standards Track                     [Page 3]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+   This extension makes the following changes to the IMAP4 protocol:
+
+      a) adds UNCHANGEDSINCE STORE modifier.
+
+      b) adds the MODIFIED response code which should be used with an OK
+         response to the STORE command.  (It can also be used in a NO
+         response.)
+
+      c) adds a new MODSEQ message data item for use with the FETCH
+         command.
+
+      d) adds CHANGEDSINCE FETCH modifier.
+
+      e) adds a new MODSEQ search criterion.
+
+      f) extends the syntax of untagged SEARCH responses to include
+         mod-sequence.
+
+      g) adds new OK untagged responses for the SELECT and EXAMINE
+         commands.
+
+      h) defines an additional parameter to SELECT/EXAMINE commands.
+
+      i) adds the HIGHESTMODSEQ status data item to the STATUS command.
+
+   A client supporting CONDSTORE extension indicates its willingness to
+   receive mod-sequence updates in all untagged FETCH responses by
+   issuing:
+
+      -  a SELECT or EXAMINE command with the CONDSTORE parameter,
+      -  a STATUS (HIGHESTMODSEQ) command,
+      -  a FETCH or SEARCH command that includes the MODSEQ message data
+         item,
+      -  a FETCH command with the CHANGEDSINCE modifier, or
+      -  a STORE command with the UNCHANGEDSINCE modifier.
+
+   The server MUST include mod-sequence data in all subsequent untagged
+   FETCH responses (until the connection is closed), whether they were
+   caused by a regular STORE, a STORE with UNCHANGEDSINCE modifier, or
+   an external agent.
+
+   This document uses the term "CONDSTORE-aware client" to refer to a
+   client that announces its willingness to receive mod-sequence updates
+   as described above.  The term "CONDSTORE enabling command" will refer
+   any of the commands listed above.  A future extension to this
+   document may extend the list of CONDSTORE enabling commands.  A first
+   CONDSTORE enabling command executed in the session MUST cause the
+
+
+
+
+Melnikov & Hole             Standards Track                     [Page 4]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+   server to return HIGHESTMODSEQ (Section 3.1.1) unless the server has
+   sent NOMODSEQ (Section 3.1.2) response code when the currently
+   selected mailbox was selected.
+
+   The rest of this document describes the protocol changes more
+   rigorously.
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [KEYWORDS].
+
+   In examples, lines beginning with "S:" are sent by the IMAP server,
+   and lines beginning with "C:" are sent by the client.  Line breaks
+   may appear in example commands solely for editorial clarity; when
+   present in the actual message, they are represented by "CRLF".
+
+   Formal syntax is defined using ABNF [ABNF].
+
+   The term "metadata" or "metadata item" is used throughout this
+   document.  It refers to any system or user-defined keyword.  Future
+   documents may extend "metadata" to include other dynamic message
+   data.
+
+   Some IMAP mailboxes are private, accessible only to the owning user.
+   Other mailboxes are not, either because the owner has set an Access
+   Control List [ACL] that permits access by other users, or because it
+   is a shared mailbox.  Let's call a metadata item "shared" for the
+   mailbox if any changes to the metadata items are persistent and
+   visible to all other users accessing the mailbox.  Otherwise, the
+   metadata item is called "private".  Note that private metadata items
+   are still visible to all sessions accessing the mailbox as the same
+   user.  Also note that different mailboxes may have different metadata
+   items as shared.
+
+   See Section 1 for the definition of a "CONDSTORE-aware client" and a
+   "CONDSTORE enabling command".
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov & Hole             Standards Track                     [Page 5]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+3.  IMAP Protocol Changes
+
+3.1.  New OK Untagged Responses for SELECT and EXAMINE
+
+   This document adds two new response codes, HIGHESTMODSEQ and
+   NOMODSEQ.  One of those response codes MUST be returned in the OK
+   untagged response for a successful SELECT/EXAMINE command.
+
+   When opening a mailbox, the server must check if the mailbox supports
+   the persistent storage of mod-sequences.  If the mailbox supports the
+   persistent storage of mod-sequences and the mailbox open operation
+   succeeds, the server MUST send the OK untagged response including
+   HIGHESTMODSEQ response code.  If the persistent storage for the
+   mailbox is not supported, the server MUST send the OK untagged
+   response including NOMODSEQ response code instead.
+
+3.1.1.  HIGHESTMODSEQ Response Code
+
+   This document adds a new response code that is returned in the OK
+   untagged response for the SELECT and EXAMINE commands.  A server
+   supporting the persistent storage of mod-sequences for the mailbox
+   MUST send the OK untagged response including HIGHESTMODSEQ response
+   code with every successful SELECT or EXAMINE command:
+
+      OK [HIGHESTMODSEQ <mod-sequence-value>]
+
+      where <mod-sequence-value> is the highest mod-sequence value of
+      all messages in the mailbox.  When the server changes UIDVALIDITY
+      for a mailbox, it doesn't have to keep the same HIGHESTMODSEQ for
+      the mailbox.
+
+   A disconnected client can use the value of HIGHESTMODSEQ to check if
+   it has to refetch metadata from the server.  If the UIDVALIDITY value
+   has changed for the selected mailbox, the client MUST delete the
+   cached value of HIGHESTMODSEQ.  If UIDVALIDITY for the mailbox is the
+   same, and if the HIGHESTMODSEQ value stored in the client's cache is
+   less than the value returned by the server, then some metadata items
+   on the server have changed since the last synchronization, and the
+   client needs to update its cache.  The client MAY use SEARCH MODSEQ
+   (Section 3.4) to find out exactly which metadata items have changed.
+   Alternatively, the client MAY issue FETCH with the CHANGEDSINCE
+   modifier (Section 3.3.1) in order to fetch data for all messages that
+   have metadata items changed since some known modification sequence.
+
+   Example 1:
+
+      C: A142 SELECT INBOX
+      S: * 172 EXISTS
+
+
+
+Melnikov & Hole             Standards Track                     [Page 6]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+      S: * 1 RECENT
+      S: * OK [UNSEEN 12] Message 12 is first unseen
+      S: * OK [UIDVALIDITY 3857529045] UIDs valid
+      S: * OK [UIDNEXT 4392] Predicted next UID
+      S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+      S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
+      S: * OK [HIGHESTMODSEQ 715194045007]
+      S: A142 OK [READ-WRITE] SELECT completed
+
+3.1.2.  NOMODSEQ Response Code
+
+   A server that doesn't support the persistent storage of mod-sequences
+   for the mailbox MUST send the OK untagged response including NOMODSEQ
+   response code with every successful SELECT or EXAMINE command.  A
+   server that returned NOMODSEQ response code for a mailbox, which
+   subsequently receives one of the following commands while the mailbox
+   is selected:
+
+      -  a FETCH command with the CHANGEDSINCE modifier,
+      -  a FETCH or SEARCH command that includes the MODSEQ message data
+         item, or
+      -  a STORE command with the UNCHANGEDSINCE modifier
+
+   MUST reject any such command with the tagged BAD response.
+
+   Example 2:
+
+      C: A142 SELECT INBOX
+      S: * 172 EXISTS
+      S: * 1 RECENT
+      S: * OK [UNSEEN 12] Message 12 is first unseen
+      S: * OK [UIDVALIDITY 3857529045] UIDs valid
+      S: * OK [UIDNEXT 4392] Predicted next UID
+      S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+      S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
+      S: * OK [NOMODSEQ] Sorry, this mailbox format doesn't support
+           modsequences
+      S: A142 OK [READ-WRITE] SELECT completed
+
+3.2.  STORE and UID STORE Commands
+
+   This document defines the following STORE modifier (see Section 2.5
+   of [IMAPABNF]):
+
+   UNCHANGEDSINCE <mod-sequence>
+
+      For each message specified in the message set, the server performs
+      the following.  If the mod-sequence of any metadata item of the
+
+
+
+Melnikov & Hole             Standards Track                     [Page 7]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+      message is equal or less than the specified UNCHANGEDSINCE value,
+      then the requested operation (as described by the message data
+      item) is performed.  If the operation is successful, the server
+      MUST update the mod-sequence attribute of the message.  An
+      untagged FETCH response MUST be sent, even if the .SILENT suffix
+      is specified, and the response MUST include the MODSEQ message
+      data item.  This is required to update the client's cache with the
+      correct mod-sequence values.  See Section 3.3.2 for more details.
+
+      However, if the mod-sequence of any metadata item of the message
+      is greater than the specified UNCHANGEDSINCE value, then the
+      requested operation MUST NOT be performed.  In this case, the
+      mod-sequence attribute of the message is not updated, and the
+      message number (or unique identifier in the case of the UID STORE
+      command) is added to the list of messages that failed the
+      UNCHANGESINCE test.
+
+      When the server finished performing the operation on all the
+      messages in the message set, it checks for a non-empty list of
+      messages that failed the UNCHANGESINCE test.  If this list is
+      non-empty, the server MUST return in the tagged response a
+      MODIFIED response code.  The MODIFIED response code includes the
+      message set (for STORE) or set of UIDs (for UID STORE) of all
+      messages that failed the UNCHANGESINCE test.
+
+   Example 3:
+
+      All messages pass the UNCHANGESINCE test.
+
+      C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045)
+          +FLAGS.SILENT (\Deleted)
+      S: * 1 FETCH (UID 4 MODSEQ (12121231000))
+      S: * 2 FETCH (UID 6 MODSEQ (12121230852))
+      S: * 4 FETCH (UID 8 MODSEQ (12121130956))
+      S: a103 OK Conditional Store completed
+
+   Example 4:
+
+      C: a104 STORE * (UNCHANGEDSINCE 12121230045) +FLAGS.SILENT
+         (\Deleted $Processed)
+      S: * 50 FETCH (MODSEQ (12111230047))
+      S: a104 OK Store (conditional) completed
+
+   Example 5:
+
+      C: c101 STORE 1 (UNCHANGEDSINCE 12121230045) -FLAGS.SILENT
+         (\Deleted)
+      S: * OK [HIGHESTMODSEQ 12111230047]
+
+
+
+Melnikov & Hole             Standards Track                     [Page 8]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+      S: * 50 FETCH (MODSEQ (12111230048))
+      S: c101 OK Store (conditional) completed
+
+      HIGHESTMODSEQ response code was sent by the server presumably
+      because this was the first CONDSTORE enabling command.
+
+   Example 6:
+
+      In spite of the failure of the conditional STORE operation for
+      message 7, the server continues to process the conditional STORE
+      in order to find all messages that fail the test.
+
+      C: d105 STORE 7,5,9 (UNCHANGEDSINCE 320162338)
+          +FLAGS.SILENT (\Deleted)
+      S: * 5 FETCH (MODSEQ (320162350))
+      S: d105 OK [MODIFIED 7,9] Conditional STORE failed
+
+   Example 7:
+
+      Same as above, but the server follows the SHOULD recommendation in
+      Section 6.4.6 of [IMAP4].
+
+      C: d105 STORE 7,5,9 (UNCHANGEDSINCE 320162338)
+          +FLAGS.SILENT (\Deleted)
+      S: * 7 FETCH (MODSEQ (320162342) FLAGS (\Seen \Deleted))
+      S: * 5 FETCH (MODSEQ (320162350))
+      S: * 9 FETCH (MODSEQ (320162349) FLAGS (\Answered))
+      S: d105 OK [MODIFIED 7,9] Conditional STORE failed
+
+      Use of UNCHANGEDSINCE with a modification sequence of 0 always
+      fails if the metadata item exists.  A system flag MUST always be
+      considered existent, whether it was set or not.
+
+   Example 8:
+
+      C: a102 STORE 12 (UNCHANGEDSINCE 0)
+          +FLAGS.SILENT ($MDNSent)
+      S: a102 OK [MODIFIED 12] Conditional STORE failed
+
+      The client has tested the presence of the $MDNSent user-defined
+      keyword.
+
+   Note: A client trying to make an atomic change to the state of a
+   particular metadata item (or a set of metadata items) should be
+   prepared to deal with the case when the server returns the MODIFIED
+   response code if the state of the metadata item being watched hasn't
+   changed (but the state of some other metadata item has).  This is
+   necessary, because some servers don't store separate mod-sequences
+
+
+
+Melnikov & Hole             Standards Track                     [Page 9]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+   for different metadata items.  However, a server implementation
+   SHOULD avoid generating spurious MODIFIED responses for +FLAGS/-FLAGS
+   STORE operations, even when the server stores a single mod-sequence
+   per message.  Section 5 describes how this can be achieved.
+
+   Unless the server has included an unsolicited FETCH to update
+   client's knowledge about messages that have failed the UNCHANGEDSINCE
+   test, upon receipt of the MODIFIED response code, the client SHOULD
+   try to figure out if the required metadata items have indeed changed
+   by issuing FETCH or NOOP command.  It is RECOMMENDED that the server
+   avoids the need for the client to do that by sending an unsolicited
+   FETCH response (Examples 9 and 10).
+
+   If the required metadata items haven't changed, the client SHOULD
+   retry the command with the new mod-sequence.  The client SHOULD allow
+   for a configurable but reasonable number of retries (at least 2).
+
+   Example 9:
+
+      In the example below, the server returns the MODIFIED response
+      code without sending information describing why the STORE
+      UNCHANGEDSINCE operation has failed.
+
+      C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
+          +FLAGS.SILENT ($Processed)
+      S: * 100 FETCH (MODSEQ (303181230852))
+      S: * 102 FETCH (MODSEQ (303181230852))
+      ...
+      S: * 150 FETCH (MODSEQ (303181230852))
+      S: a106 OK [MODIFIED 101] Conditional STORE failed
+
+      The flag $Processed was set on the message 101...
+
+      C: a107 NOOP
+      S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed))
+      S: a107 OK
+
+      Or the flag hasn't changed, but another has (note that this server
+      behaviour is discouraged.  Server implementers should also see
+      Section 5)...
+
+      C: b107 NOOP
+      S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered))
+      S: b107 OK
+
+      ...and the client retries the operation for the message 101 with
+      the updated UNCHANGEDSINCE value
+
+
+
+
+Melnikov & Hole             Standards Track                    [Page 10]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+      C: b108 STORE 101 (UNCHANGEDSINCE 303011130956)
+          +FLAGS.SILENT ($Processed)
+      S: * 101 FETCH (MODSEQ (303181230852))
+      S: b108 OK Conditional Store completed
+
+   Example 10:
+
+      Same as above, but the server avoids the need for the client to
+      poll for changes.
+
+      The flag $Processed was set on the message 101 by another
+      client...
+
+      C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
+          +FLAGS.SILENT ($Processed)
+      S: * 100 FETCH (MODSEQ (303181230852))
+      S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed))
+      S: * 102 FETCH (MODSEQ (303181230852))
+      ...
+      S: * 150 FETCH (MODSEQ (303181230852))
+      S: a106 OK [MODIFIED 101] Conditional STORE failed
+
+      Or the flag hasn't changed, but another has (note that this server
+      behaviour is discouraged.  Server implementers should also see
+      Section 5)...
+
+      C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
+          +FLAGS.SILENT ($Processed)
+      S: * 100 FETCH (MODSEQ (303181230852))
+      S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered))
+      S: * 102 FETCH (MODSEQ (303181230852))
+      ...
+      S: * 150 FETCH (MODSEQ (303181230852))
+      S: a106 OK [MODIFIED 101] Conditional STORE failed
+
+      ...and the client retries the operation for the message 101 with
+      the updated UNCHANGEDSINCE value
+
+      C: b108 STORE 101 (UNCHANGEDSINCE 303011130956)
+          +FLAGS.SILENT ($Processed)
+      S: * 101 FETCH (MODSEQ (303181230852))
+      S: b108 OK Conditional Store completed
+
+      Or the flag hasn't changed, but another has (nice server
+      behaviour.  Server implementers should also see Section 5)...
+
+      C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
+          +FLAGS.SILENT ($Processed)
+
+
+
+Melnikov & Hole             Standards Track                    [Page 11]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+      S: * 100 FETCH (MODSEQ (303181230852))
+      S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed \Deleted
+           \Answered))
+      S: * 102 FETCH (MODSEQ (303181230852))
+      ...
+      S: * 150 FETCH (MODSEQ (303181230852))
+      S: a106 OK Conditional STORE completed
+
+   Example 11:
+
+      The following example is based on the example from the Section
+      4.2.3 of [RFC-2180] and demonstrates that the MODIFIED response
+      code may be also returned in the tagged NO response.
+
+      Client tries to conditionally STORE flags on a mixture of expunged
+      and non-expunged messages; one message fails the UNCHANGEDSINCE
+      test.
+
+      C: B001 STORE 1:7 (UNCHANGEDSINCE 320172338) +FLAGS (\SEEN)
+      S: * 1 FETCH (MODSEQ (320172342) FLAGS (\SEEN))
+      S: * 3 FETCH (MODSEQ (320172342) FLAGS (\SEEN))
+      S: B001 NO [MODIFIED 2] Some of the messages no longer exist.
+
+      C: B002 NOOP
+      S: * 4 EXPUNGE
+      S: * 4 EXPUNGE
+      S: * 4 EXPUNGE
+      S: * 4 EXPUNGE
+      S: * 2 FETCH (MODSEQ (320172340) FLAGS (\Deleted \Answered))
+      S: B002 OK NOOP Completed.
+
+      By receiving FETCH responses for messages 1 and 3, and EXPUNGE
+      responses that indicate that messages 4 through 7 have been
+      expunged, the client retries the operation only for the message 2.
+      The updated UNCHANGEDSINCE value is used.
+
+      C: b003 STORE 2 (UNCHANGEDSINCE 320172340) +FLAGS (\Seen)
+      S: * 2 FETCH (MODSEQ (320180050))
+      S: b003 OK Conditional Store completed
+
+   Note: If a message is specified multiple times in the message set,
+   and the server doesn't internally eliminate duplicates from the
+   message set, it MUST NOT fail the conditional STORE operation for the
+   second (or subsequent) occurrence of the message if the operation
+   completed successfully for the first occurrence.  For example, if the
+   client specifies:
+
+
+
+
+
+Melnikov & Hole             Standards Track                    [Page 12]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+         e105 STORE 7,3:9 (UNCHANGEDSINCE 12121230045)
+          +FLAGS.SILENT (\Deleted)
+
+   the server must not fail the operation for message 7 as part of
+   processing "3:9" if it succeeded when message 7 was processed the
+   first time.
+
+   Once the client specified the UNCHANGEDSINCE modifier in a STORE
+   command, the server MUST include the MODSEQ fetch response data items
+   in all subsequent unsolicited FETCH responses.
+
+   This document also changes the behaviour of the server when it has
+   performed a STORE or UID STORE command and the UNCHANGEDSINCE
+   modifier is not specified.  If the operation is successful for a
+   message, the server MUST update the mod-sequence attribute of the
+   message.  The server is REQUIRED to include the mod-sequence value
+   whenever it decides to send the unsolicited FETCH response to all
+   CONDSTORE-aware clients that have opened the mailbox containing the
+   message.
+
+   Server implementers should also see Section 3.8 for additional
+   quality of implementation issues related to the STORE command.
+
+3.3.  FETCH and UID FETCH Commands
+
+3.3.1.  CHANGEDSINCE FETCH Modifier
+
+   This document defines the following FETCH modifier (see Section 2.4
+   of [IMAPABNF]):
+
+   CHANGEDSINCE <mod-sequence>
+
+      CHANGEDSINCE FETCH modifier allows to create a further subset of
+      the list of messages described by sequence set.  The information
+      described by message data items is only returned for messages that
+      have mod-sequence bigger than <mod-sequence>.
+
+      When CHANGEDSINCE FETCH modifier is specified, it implicitly adds
+      MODSEQ FETCH message data item (Section 3.3.2).
+
+   Example 12:
+
+      C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345)
+      S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen))
+      S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted))
+      S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk
+           $MDNSent))
+      S: s100 OK FETCH completed
+
+
+
+Melnikov & Hole             Standards Track                    [Page 13]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+3.3.2.  MODSEQ Message Data Item in FETCH Command
+
+   This extension adds a MODSEQ message data item to the FETCH command.
+   The MODSEQ message data item allows clients to retrieve mod-sequence
+   values for a range of messages in the currently selected mailbox.
+
+   Once the client specified the MODSEQ message data item in a FETCH
+   request, the server MUST include the MODSEQ fetch response data items
+   in all subsequent unsolicited FETCH responses.
+
+   Syntax:  MODSEQ
+
+      The MODSEQ message data item causes the server to return MODSEQ
+      fetch response data items.
+
+   Syntax:  MODSEQ ( <permsg-modsequence> )
+
+      MODSEQ response data items contain per-message mod-sequences.
+
+      The MODSEQ response data item is returned if the client issued
+      FETCH with MODSEQ message data item.  It also allows the server to
+      notify the client about mod-sequence changes caused by conditional
+      STOREs (Section 3.2) and/or changes caused by external sources.
+
+   Example 13:
+
+      C: a FETCH 1:3 (MODSEQ)
+      S: * 1 FETCH (MODSEQ (624140003))
+      S: * 2 FETCH (MODSEQ (624140007))
+      S: * 3 FETCH (MODSEQ (624140005))
+      S: a OK Fetch complete
+
+      In this example, the client requests per-message mod-sequences for
+      a set of messages.
+
+   When a flag for a message is modified in a different session, the
+   server sends an unsolicited FETCH response containing the mod-
+   sequence for the message.
+
+   Example 14:
+
+      (Session 1, authenticated as a user "alex").  The user adds a
+      shared flag \Deleted:
+
+         C: A142 SELECT INBOX
+         ...
+         S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+         S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \*)] Limited
+
+
+
+Melnikov & Hole             Standards Track                    [Page 14]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+         ...
+
+         C: A160 STORE 7 +FLAGS.SILENT (\Deleted)
+         S: * 7 FETCH (MODSEQ (2121231000))
+         S: A160 OK Store completed
+
+      (Session 2, also authenticated as the user "alex").  Any changes
+      to flags are always reported to all sessions authenticated as the
+      same user as in the session 1.
+
+         C: C180 NOOP
+         S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (12121231000))
+         S: C180 OK Noop completed
+
+      (Session 3, authenticated as a user "andrew").  As \Deleted is a
+      shared flag, changes in session 1 are also reported in session 3:
+
+         C: D210 NOOP
+         S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (12121231000))
+         S: D210 OK Noop completed
+
+      The user modifies a private flag \Seen in session 1...
+
+         C: A240 STORE 7 +FLAGS.SILENT (\Seen)
+         S: * 7 FETCH (MODSEQ (12121231777))
+         S: A240 OK Store completed
+
+      ...which is only reported in session 2...
+
+         C: C270 NOOP
+         S: * 7 FETCH (FLAGS (\Deleted \Answered \Seen) MODSEQ
+              (12121231777))
+         S: C270 OK Noop completed
+
+      ...but not in session 3.
+
+         C: D300 NOOP
+         S: D300 OK Noop completed
+
+      And finally, the user removes flags \Answered (shared) and \Seen
+      (private) in session 1.
+
+         C: A330 STORE 7 -FLAGS.SILENT (\Answered \Seen)
+         S: * 7 FETCH (MODSEQ (12121245160))
+         S: A330 OK Store completed
+
+
+
+
+
+
+Melnikov & Hole             Standards Track                    [Page 15]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+      Both changes are reported in the session 2...
+
+         C: C360 NOOP
+         S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160))
+         S: C360 OK Noop completed
+
+      ...and only changes to shared flags are reported in session 3.
+
+         C: D390 NOOP
+         S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160))
+         S: D390 OK Noop completed
+
+   Server implementers should also see Section 3.8 for additional
+   quality of implementation issues related to the FETCH command.
+
+3.4.  MODSEQ Search Criterion in SEARCH
+
+   The MODSEQ criterion for the SEARCH command allows a client to search
+   for the metadata items that were modified since a specified moment.
+
+   Syntax:  MODSEQ [<entry-name> <entry-type-req>] <mod-sequence-valzer>
+
+      Messages that have modification values that are equal to or
+      greater than <mod-sequence-valzer>.  This allows a client, for
+      example, to find out which messages contain metadata items that
+      have changed since the last time it updated its disconnected
+      cache.  The client may also specify <entry-name> (name of metadata
+      item) and <entry-type-req> (type of metadata item) before
+      <mod-sequence-valzer>.  <entry-type-req> can be one of "shared",
+      "priv" (private), or "all".  The latter means that the server
+      should use the biggest value among "priv" and "shared" mod-
+      sequences for the metadata item.  If the server doesn't store
+      internally separate mod-sequences for different metadata items, it
+      MUST ignore <entry-name> and <entry-type-req>.  Otherwise, the
+      server should use them to narrow down the search.
+
+      For a flag <flagname>, the corresponding <entry-name> has a form
+      "/flags/<flagname>" as defined in [IMAPABNF].  Note that the
+      leading "\" character that denotes a system flag has to be escaped
+      as per Section 4.3 of [IMAP4], as the <entry-name> uses syntax for
+      quoted strings.
+
+   If client specifies a MODSEQ criterion in a SEARCH command and the
+   server returns a non-empty SEARCH result, the server MUST also append
+   (to the end of the untagged SEARCH response) the highest mod-sequence
+   for all messages being returned.  See also Section 3.5.
+
+
+
+
+
+Melnikov & Hole             Standards Track                    [Page 16]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+   Example 15:
+
+      C: a SEARCH MODSEQ "/flags/\\draft" all 620162338
+      S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 917162500)
+      S: a OK Search complete
+
+      In the above example, the message numbers of any messages
+      containing the string "IMAP4" in the "value" attribute of the
+      "/comment" entry and having a mod-sequence equal to or greater
+      than 620162338 for the "\Draft" flag are returned in the search
+      results.
+
+   Example 16:
+
+      C: t SEARCH OR NOT MODSEQ 720162338 LARGER 50000
+      S: * SEARCH
+      S: t OK Search complete, nothing found
+
+3.5.  Modified SEARCH Untagged Response
+
+   Data:       zero or more numbers
+               mod-sequence value (omitted if no match)
+
+   This document extends syntax of the untagged SEARCH response to
+   include the highest mod-sequence for all messages being returned.
+
+   If a client specifies a MODSEQ criterion in a SEARCH (or UID SEARCH)
+   command and the server returns a non-empty SEARCH result, the server
+   MUST also append (to the end of the untagged SEARCH response) the
+   highest mod-sequence for all messages being returned.  See Section
+   3.4 for examples.
+
+3.6.  HIGHESTMODSEQ Status Data Items
+
+   This document defines a new status data item:
+
+   HIGHESTMODSEQ
+
+      The highest mod-sequence value of all messages in the mailbox.
+      This is the same value that is returned by the server in the
+      HIGHESTMODSEQ response code in an OK untagged response (see
+      Section 3.1.1).  If the server doesn't support the persistent
+      storage of mod-sequences for the mailbox (see Section 3.1.2), the
+      server MUST return 0 as the value of HIGHESTMODSEQ status data
+      item.
+
+
+
+
+
+
+Melnikov & Hole             Standards Track                    [Page 17]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+   Example 17:
+
+      C: A042 STATUS blurdybloop (UIDNEXT MESSAGES HIGHESTMODSEQ)
+      S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292
+           HIGHESTMODSEQ 7011231777)
+      S: A042 OK STATUS completed
+
+3.7.  CONDSTORE Parameter to SELECT and EXAMINE
+
+   The CONDSTORE extension defines a single optional select parameter,
+   "CONDSTORE", which tells the server that it MUST include the MODSEQ
+   fetch response data items in all subsequent unsolicited FETCH
+   responses.
+
+   The CONDSTORE parameter to SELECT/EXAMINE helps avoid a race
+   condition that might arise when one or more metadata items are
+   modified in another session after the server has sent the
+   HIGHESTMODSEQ response code and before the client was able to issue a
+   CONDSTORE enabling command.
+
+   Example 18:
+
+      C: A142 SELECT INBOX (CONDSTORE)
+      S: * 172 EXISTS
+      S: * 1 RECENT
+      S: * OK [UNSEEN 12] Message 12 is first unseen
+      S: * OK [UIDVALIDITY 3857529045] UIDs valid
+      S: * OK [UIDNEXT 4392] Predicted next UID
+      S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+      S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
+      S: * OK [HIGHESTMODSEQ 715194045007]
+      S: A142 OK [READ-WRITE] SELECT completed, CONDSTORE is now enabled
+
+3.8.  Additional Quality-of-Implementation Issues
+
+   Server implementations should follow the following rule, which
+   applies to any successfully completed STORE/UID STORE (with and
+   without UNCHANGEDSINCE modifier), as well as to a FETCH command that
+   implicitly sets \Seen flag:
+
+      Adding the flag when it is already present or removing when it is
+      not present SHOULD NOT change the mod-sequence.
+
+   This will prevent spurious client synchronization requests.
+
+
+
+
+
+
+
+Melnikov & Hole             Standards Track                    [Page 18]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+   However, note that client implementers MUST NOT rely on this server
+   behavior.  A client can't distinguish between the case when a server
+   has violated the SHOULD mentioned above, and that when one or more
+   clients set and unset (or unset and set) the flag in another session.
+
+4.  Formal Syntax
+
+   The following syntax specification uses the Augmented Backus-Naur
+   Form (ABNF) [ABNF] notation.  Elements not defined here can be found
+   in the formal syntax of the ABNF [ABNF], IMAP [IMAP4], and IMAP ABNF
+   extensions [IMAPABNF] specifications.
+
+   Except as noted otherwise, all alphabetic characters are case-
+   insensitive.  The use of upper- or lowercase characters to define
+   token strings is for editorial clarity only.  Implementations MUST
+   accept these strings in a case-insensitive fashion.
+
+   capability          =/ "CONDSTORE"
+
+   status-att          =/ "HIGHESTMODSEQ"
+                          ;; extends non-terminal defined in RFC 3501.
+
+   status-att-val      =/ "HIGHESTMODSEQ" SP mod-sequence-valzer
+                          ;; extends non-terminal defined in [IMAPABNF].
+                          ;; Value 0 denotes that the mailbox doesn't
+                          ;; support persistent mod-sequences
+                          ;; as described in Section 3.1.2
+
+   store-modifier      =/ "UNCHANGEDSINCE" SP mod-sequence-valzer
+                          ;; Only a single "UNCHANGEDSINCE" may be
+                          ;; specified in a STORE operation
+
+   fetch-modifier      =/ chgsince-fetch-mod
+                          ;; conforms to the generic "fetch-modifier"
+                          ;; syntax defined in [IMAPABNF].
+
+   chgsince-fetch-mod  = "CHANGEDSINCE" SP mod-sequence-value
+                          ;; CHANGEDSINCE FETCH modifier conforms to
+                          ;; the fetch-modifier syntax
+
+   fetch-att           =/ fetch-mod-sequence
+                          ;; modifies original IMAP4 fetch-att
+
+   fetch-mod-sequence  = "MODSEQ"
+
+   fetch-mod-resp      = "MODSEQ" SP "(" permsg-modsequence ")"
+
+   msg-att-dynamic     =/ fetch-mod-resp
+
+
+
+Melnikov & Hole             Standards Track                    [Page 19]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+   search-key          =/ search-modsequence
+                          ;; modifies original IMAP4 search-key
+                          ;;
+                          ;; This change applies to all commands
+                          ;; referencing this non-terminal, in
+                          ;; particular SEARCH.
+
+   search-modsequence  = "MODSEQ" [search-modseq-ext] SP
+                         mod-sequence-valzer
+
+   search-modseq-ext   = SP entry-name SP entry-type-req
+
+   resp-text-code      =/ "HIGHESTMODSEQ" SP mod-sequence-value /
+                          "NOMODSEQ" /
+                          "MODIFIED" SP set
+
+   entry-name          = entry-flag-name
+
+   entry-flag-name     = DQUOTE "/flags/" attr-flag DQUOTE
+                          ;; each system or user defined flag <flag>
+                          ;; is mapped to "/flags/<flag>".
+                          ;;
+                          ;; <entry-flag-name> follows the escape rules
+                          ;; used by "quoted" string as described in
+                          ;; Section 4.3 of [IMAP4], e.g., for the flag
+                          ;; \Seen the corresponding <entry-name> is
+                          ;; "/flags/\\seen", and for the flag
+                          ;; $MDNSent, the corresponding <entry-name>
+                          ;; is "/flags/$mdnsent".
+
+   entry-type-resp     = "priv" / "shared"
+                          ;; metadata item type
+
+   entry-type-req      = entry-type-resp / "all"
+                          ;; perform SEARCH operation on private
+                          ;; metadata item, shared metadata item or both
+
+   permsg-modsequence  = mod-sequence-value
+                          ;; per message mod-sequence
+
+   mod-sequence-value  = 1*DIGIT
+                          ;; Positive unsigned 64-bit integer
+                          ;; (mod-sequence)
+                          ;; (1 <= n < 18,446,744,073,709,551,615)
+
+   mod-sequence-valzer = "0" / mod-sequence-value
+
+   search-sort-mod-seq = "(" "MODSEQ" SP mod-sequence-value ")"
+
+
+
+Melnikov & Hole             Standards Track                    [Page 20]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+   select-param        =/ condstore-param
+                          ;; conforms to the generic "select-param"
+                          ;; non-terminal syntax defined in [IMAPABNF].
+
+   condstore-param     = "CONDSTORE"
+
+   mailbox-data        =/ "SEARCH" [1*(SP nz-number) SP
+                          search-sort-mod-seq]
+
+   attr-flag           = "\\Answered" / "\\Flagged" / "\\Deleted" /
+                         "\\Seen" / "\\Draft" / attr-flag-keyword /
+                         attr-flag-extension
+                          ;; Does not include "\\Recent"
+
+   attr-flag-extension = "\\" atom
+                          ;; Future expansion.  Client implementations
+                          ;; MUST accept flag-extension flags.  Server
+                          ;; implementations MUST NOT generate
+                          ;; flag-extension flags except as defined by
+                          ;; future standard or standards-track
+                          ;; revisions of [IMAP4].
+
+   attr-flag-keyword   = atom
+
+5.  Server Implementation Considerations
+
+   This section describes how a server implementation that doesn't store
+   separate per-metadata mod-sequences for different metadata items can
+   avoid sending the MODIFIED response to any of the following
+   conditional STORE operations:
+
+      +FLAGS
+      -FLAGS
+      +FLAGS.SILENT
+      -FLAGS.SILENT
+
+   Note that the optimization described in this section can't be
+   performed in case of a conditional STORE FLAGS operation.
+
+   Let's use the following example.  The client has issued
+
+      C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
+         +FLAGS.SILENT ($Processed)
+
+   When the server receives the command and parses it successfully, it
+   iterates through the message set and tries to execute the conditional
+   STORE command for each message.
+
+
+
+
+Melnikov & Hole             Standards Track                    [Page 21]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+   Each server internally works as a client, i.e., it has to cache the
+   current state of all IMAP flags as it is known to the client.  In
+   order to report flag changes to the client, the server compares the
+   cached values with the values in its database for IMAP flags.
+
+   Imagine that another client has changed the state of a flag \Deleted
+   on the message 101 and that the change updated the mod-sequence for
+   the message.  The server knows that the mod-sequence for the mailbox
+   has changed; however, it also knows that:
+
+   a) the client is not interested in \Deleted flag, as it hasn't
+      included it in +FLAGS.SILENT operation; and
+
+   b) the state of the flag $Processed hasn't changed (the server can
+      determine this by comparing cached flag state with the state of
+      the flag in the database).
+
+   Therefore, the server doesn't have to report MODIFIED to the client.
+   Instead, the server may set $Processed flag, update the mod-sequence
+   for the message 101 once again and send an untagged FETCH response
+   with new mod-sequence and flags:
+
+      S: * 101 FETCH (MODSEQ (303011130956)
+         FLAGS ($Processed \Deleted \Answered))
+
+   See also Section 3.8 for additional quality-of-implementation issues.
+
+6.  Security Considerations
+
+   It is believed that the Conditional STORE extension doesn't raise any
+   new security concerns that are not already discussed in [IMAP4].
+   However, the availability of this extension may make it possible for
+   IMAP4 to be used in critical applications it could not be used for
+   previously, making correct IMAP server implementation and operation
+   even more important.
+
+7.  IANA Considerations
+
+   IMAP4 capabilities are registered by publishing a standards track or
+   IESG approved experimental RFC.  The registry is currently located
+   at:
+
+         http://www.iana.org/assignments/imap4-capabilities
+
+   This document defines the CONDSTORE IMAP capability.  IANA has added
+   it to the registry accordingly.
+
+
+
+
+
+Melnikov & Hole             Standards Track                    [Page 22]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+8.  References
+
+8.1.  Normative References
+
+   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 4234, October 2005.
+
+   [IMAP4]    Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+              4rev1", RFC 3501, March 2003.
+
+   [IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
+              ABNF", RFC 4466, April 2006.
+
+8.2.  Informative References
+
+   [ACAP]     Newman, C. and J. Myers, "ACAP -- Application
+              Configuration Access Protocol", RFC 2244, November 1997.
+
+   [ACL]      Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
+              RFC 4314, December 2005.
+
+   [ANN]      Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", Work
+              in Progress, March 2006.
+
+   [NTP]      Mills, D., "Network Time Protocol (Version 3)
+              Specification, Implementation and Analysis", RFC 1305,
+              March 1992.
+
+   [RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC
+              2180, July 1997.
+
+9.  Acknowledgements
+
+   Some text was borrowed from "IMAP ANNOTATE Extension" [ANN] by
+   Randall Gellens and Cyrus Daboo and from "ACAP -- Application
+   Configuration Access Protocol" [ACAP] by Chris Newman and John Myers.
+
+   Many thanks to Randall Gellens for his thorough review of the
+   document.
+
+   The authors also acknowledge the feedback provided by Cyrus Daboo,
+   Larry Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen,
+   Timo Sirainen, Mark Crispin, Ned Freed, Ken Murchison, and Dave
+   Cridland.
+
+
+
+
+Melnikov & Hole             Standards Track                    [Page 23]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+Authors' Addresses
+
+   Alexey Melnikov
+   Isode Limited
+   5 Castle Business Village
+   36 Station Road
+   Hampton, Middlesex
+   TW12 2BX,
+   United Kingdom
+
+   EMail: Alexey.Melnikov@isode.com
+
+
+   Steve Hole
+   ACI WorldWide/MessagingDirect
+   #1807, 10088 102 Ave
+   Edmonton, AB
+   T5J 2Z1
+   Canada
+
+   EMail: Steve.Hole@messagingdirect.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov & Hole             Standards Track                    [Page 24]
+
+RFC 4551          IMAP Extension for Conditional STORE         June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Melnikov & Hole             Standards Track                    [Page 25]
+