rfc3656.txt

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

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