Selected Books:


Buy this book!




Buy this book!




Buy this book!




Buy this book!




Buy this book!



German speakers - order books from amazon.de!

Books to UK - order books from amazon.co.uk!

The Online Requests For Comments - RFCs

Home | Books | Bookmark! | Link to Us | Help

RFC 2180 


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:

   

             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.

   Furthermore, this behavior, may prevent 'recycling' of the same
   mailbox name until all clients have finished accessing the original
   mailbox.

   Example:

   

             C1: A001 DELETE FOO
             S1: A001 OK Mailbox FOO is deleted.

   

             C2: B001 STORE 1 +FLAGS (\Seen)
             S2: * 1 FETCH FLAGS (\Seen)
             S2: B001 OK STORE completed

   

             C3: C001 STATUS FOO (MESSAGES)
             S3: C001 NO Mailbox does not exist

   

             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


   

             C2: B002 CLOSE
             S2: B002 OK CLOSE Completed

   

             C3: C003 CREATE FOO
             S3: C003 OK CREATE Completed


3.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:

   

             C1: A002 DELETE FOO
             S1: A002 OK DELETE completed.

   
             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:

   

             C1: A001 RENAME FOO BAR
             S1: A001 OK RENAME completed.

   

             C2: B001 FETCH 2:4 (FLAGS)
             S2: * 2 FETCH . . .
             S2: * 3 FETCH . . .
             S2: * 4 FETCH . . .
             S2: B001 OK FETCH completed

   

             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 renamed


4. 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:7


4.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.)

   

             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

   

             C2: B002 NOOP
             S2: * 4 EXPUNGE
             S2: * 4 EXPUNGE
             S2: * 4 EXPUNGE
             S2: * 4 EXPUNGE
             S2: * 3 EXISTS
             S2: B002 OK NOOP Complete

   

             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 1997


4.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.)

   

             C2: B001 FETCH 3:5 ENVELOPE
             S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)
             S2: B001 NO Some of the requested messages no longer exist

   

             C2: B002 NOOP
             S2: * 4 EXPUNGE
             S2: * 4 EXPUNGE
             S2: * 4 EXPUNGE
             S2: * 4 EXPUNGE
             S2: * 3 EXISTS
             S2: B002 OK NOOP Completed.

   
















Gahrns                       Informational                      [Page 7]

RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997


4.1.3 The server MAY allow the EXPUNGE of a multi-accessed mailbox, and
      on subsequent FETCH commands return the usual FETCH responses for
      non-expunged messages, "NIL FETCH Responses" for expunged
      messages, and a tagged OK response.

   If all of the messages in the subsequent FETCH command have been
   expunged, the server SHOULD return only a tagged NO.  In this case,
   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, determine that the FETCH failed because of pending
   expunges.

   "NIL FETCH responses" are a representation of empty data as
   appropriate for the FETCH argument specified.

   Example:

   * 1 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL))
   * 1 FETCH (FLAGS ())
   * 1 FETCH (INTERNALDATE "00-Jan-0000 00:00:00 +0000")
   * 1 FETCH (RFC822 "")
   * 1 FETCH (RFC822.HEADER "")
   * 1 FETCH (RFC822.TEXT "")
   * 1 FETCH (RFC822.SIZE 0)
   * 1 FETCH (BODY ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
   * 1 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
   * 1 FETCH (BODY[
] "") * 1 FETCH (BODY[
] "") In some cases, a client may not be able to distinguish between "NIL FETCH responses" received because a message was expunged and those received because the data actually was NIL. For example, a * 5 FETCH (FLAGS ()) response could be received if no flags were set on message 5, or because message 5 was expunged. In a case of potential ambiguity, the client SHOULD issue a command such as NOOP to force the sending of the EXPUNGE responses to resolve any ambiguity. Example: (Building upon the scenario outlined in 4.1.) Gahrns Informational [Page 8] RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 C2: B002 FETCH 3:5 ENVELOPE S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned) S2: * 4 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL) S2: * 5 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL) S2: B002 OK FETCH Completed C2: B002 FETCH 4:7 ENVELOPE S2: B002 NO Messages 4:7 have been expunged. 4.1.4 To avoid the situation altogether, the server MAY fail the EXPUNGE 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 message unexpungeable. 4.2. Storing of expunged messages Following are some strategies an IMAP server may choose to use when dealing with a STORE command on expunged messages. 4.2.1 If the ".SILENT" suffix is used, and the STORE completed successfully for all the non-expunged messages, the server SHOULD return a tagged OK. Example: (Building upon the scenario outlined in 4.1.) C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN) S2: B001 OK Gahrns Informational [Page 9] RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 4.2.2. If the ".SILENT" suffix is not used, and only expunged messages are referenced, the server SHOULD return only a tagged NO. Example: (Building upon the scenario outlined in 4.1.) C2: B001 STORE 5:7 +FLAGS (\SEEN) S2: B001 NO Messages have been expunged 4.2.3. If the ".SILENT" suffix is not used, and a mixture of expunged and non-expunged messages are referenced, the server MAY set the flags and return a FETCH response for the non-expunged messages along with a tagged NO. After receiving a tagged NO STORE 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 STORE command, or by examining the EXPUNGE responses from the NOOP and FETCH responses from the STORE, determine that the STORE failed because of pending expunges. Example: (Building upon the scenario outlined in 4.1.) C2: B001 STORE 1:7 +FLAGS (\SEEN) S2: * FETCH 1 FLAGS (\SEEN) S2: * FETCH 2 FLAGS (\SEEN) S2: * FETCH 3 FLAGS (\SEEN) S2: B001 NO Some of the messages no longer exist. C2: B002 NOOP S2: * 4 EXPUNGE S2: * 4 EXPUNGE S2: * 4 EXPUNGE S2: * 4 EXPUNGE S2: * 3 EXISTS S2: B002 OK NOOP Completed. Gahrns Informational [Page 10] RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 4.2.4. If the ".SILENT" suffix is not used, and a mixture of expunged and non-expunged messages are referenced, the server MAY return an untagged NO and not set any flags. After receiving a tagged NO STORE response, the client SHOULD issue a NOOP command so that it will be informed of any pending EXPUNGE responses. The client would then re-issue the STORE command after updating its message list per any EXPUNGE response. If a large number of clients are accessing a shared mailbox, the window in which there are no pending expunges may be small or non- existent, effectively disallowing a client from setting the flags on all messages at once. Example: (Building upon the scenario outlined in 4.1.) C2: B001 STORE 1:7 +FLAGS (\SEEN) S2: B001 NO Some of the messages no longer exist. C2: B002 NOOP S2: * 4 EXPUNGE S2: * 4 EXPUNGE S2: * 4 EXPUNGE S2: * 4 EXPUNGE S2: * 3 EXISTS S2: B002 OK NOOP Completed. C2: B003 STORE 1:3 +FLAGS (\SEEN) S2: * FETCH 1 FLAGS (\SEEN) S2: * FETCH 2 FLAGS (\SEEN) S2: * FETCH 3 FLAGS (\SEEN) S2: B003 OK STORE Completed 4.3. Searching of expunged messages A server MAY simply not return a search response for messages that have been expunged and it has not been able to inform the client about. If a client was expecting a particular message to be returned in a search result, and it was not, the client SHOULD issue a NOOP command to see if the message was expunged by another client. Gahrns Informational [Page 11] RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 4.4 Copying of expunged messages COPY is the only IMAP4 sequence number command that is safe to allow an EXPUNGE response on. This is because a client is not permitted to cascade several COPY commands together. A client is required to wait and confirm that the copy worked before issuing another one. 4.4.1 The server MAY disallow the COPY of messages in a multi-access mailbox that contains expunged messages. Pending EXPUNGE response(s) MUST be returned to the COPY command. Example: C: A001 COPY 2,4,6,8 FRED S: * 4 EXPUNGE S: A001 NO COPY rejected, because some of the requested messages were expunged Note: Non of the above messages are copied because if a COPY command is unsuccessful, the server MUST restore the destination mailbox to its state before the COPY attempt. 4.4.2 The server MAY allow the COPY of messages in a multi-access mailbox that contains expunged messages. Pending EXPUNGE response(s) MUST be returned to the COPY command. Messages that are copied are messages corresponding to sequence numbers before any EXPUNGE response. Example: C: A001 COPY 2,4,6,8 FRED S: * 3 EXPUNGE S: A001 OK COPY completed In the above example, the messages that are copied to FRED are messages 2,4,6,8 at the start of the COPY command. These are equivalent to messages 2,3,5,7 at the end of the COPY command. The EXPUNGE response can't take place until after the messages from the COPY command are identified (because of the "no expunge while no commands in progress" rule). Gahrns Informational [Page 12] RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 Example: C: A001 COPY 2,4,6,8 FRED S: * 4 EXPUNGE S: A001 OK COPY completed In the above example, message 4 was copied before it was expunged, and MUST appear in the destination mailbox FRED. 5. Security Considerations This document describes behavior of servers that use the IMAP4 protocol, and as such, has the same security considerations as described in [RFC-2060]. In particular, some described server behavior does not allow for the immediate deletion of information when a mailbox is accessed by multiple clients. This may be a consideration when dealing with sensitive information where immediate deletion would be preferred. 6. References [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, University of Washington, December 1996. [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. 7. Acknowledgments This document is the result of discussions on the IMAP4 mailing list and is meant to reflect consensus of this group. In particular, Raymond Cheng, Mark Crispin, Jim Evans, Erik Forsberg, Steve Hole, Mark Keasling, Barry Leiba, Syd Logan, John Mani, Pat Moran, Larry Osterman, Chris Newman, Bart Schaefer, Vladimir Vulovic, and Jack De Winter were active participants in this discussion or made suggestions to this document. Gahrns Informational [Page 13] RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 8. Author's Address Mike Gahrns Microsoft One Microsoft Way Redmond, WA, 98072 Phone: (206) 936-9833 EMail: mikega@microsoft.com Gahrns Informational [Page 14]



RFC Search. Copyright ©1999 by Dodoland Co.
Web design ©1999 by WebYou.com


Selected Books:


Buy this book!



    
Buy this book!



    
Buy this book!



    
Buy this book!



    
Buy this book!