IMAP4 Multi-Accessed Mailbox Practice
RFC 2180
Document | Type |
RFC - Informational
(July 1997; No errata)
Was draft-gahrns-imap-practice (individual)
|
|
---|---|---|---|
Author | Mike Gahrns | ||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 2180 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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.Show full document text