rfc3656.txt

广泛使用的邮件服务器！同时

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"