Network Working Group                                          M. GahrnsRequest for Comments: 2180                                     MicrosoftCategory: Informational                                        July 1997                 IMAP4 Multi-Accessed Mailbox PracticeStatus 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 19972. 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 19973.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 Completed3.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 renamed4. 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:74.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 19974.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]