The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol
RFC 3656

Document Type RFC - Experimental (December 2003; No errata)
Last updated 2015-10-14
Stream ISE
Formats plain text pdf html bibtex
Stream ISE state (None)
Consensus Boilerplate Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 3656 (Experimental)
Telechat date
Responsible AD Ned Freed
IESG note Approved by IESG 18-Sep-2003
Send notices to (None)
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",
Show full document text