RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 19974.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[<section>] "")   * 1 FETCH (BODY[<section>]<partial> "")   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.)   <Client #2 attempts to access a mix of expunged and non-expunged   messages.  Normal data is returned for non-expunged message, "NIL   FETCH responses" are returned for expunged messages>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   <Client #2 attempts to FETCH only expunged messages and receives a   tagged NO response>             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.)   <Client #2 tries to silently STORE flags on expunged and non-   expunged messages.  The server sets the flags on the non-expunged   messages and returns OK>             C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN)             S2: B001 OKGahrns                       Informational                      [Page 9]RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 19974.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.)   <Client #2 tries to STORE flags only on expunged messages>             C2: B001 STORE 5:7 +FLAGS (\SEEN)             S2: B001 NO  Messages have been expunged4.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.)   <Client #2 tries to STORE flags on a mixture of expunged and non-   expunged messages>             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.   <By receiving FETCH responses for messages 1:3, and an EXPUNGE   response that indicates messages 4:7 have been expunged, the client   does not need to re-issue the STORE>Gahrns                       Informational                     [Page 10]RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 19974.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.)   <Client #2 tries to STORE flags on a mixture of expunged and non-   expunged messages>             C2: B001 STORE 1:7 +FLAGS (\SEEN)             S2: B001 NO  Some of the messages no longer exist.   <Client #2 issues a NOOP to be informed of the EXPUNGED messages>             C2: B002 NOOP             S2: * 4 EXPUNGE             S2: * 4 EXPUNGE             S2: * 4 EXPUNGE             S2: * 4 EXPUNGE             S2: * 3 EXISTS             S2: B002 OK NOOP Completed.   <Client #2 updates its message list and re-issues the STORE on only   those messages that have not been expunged>             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 Completed4.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 19974.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 19978. Author's Address   Mike Gahrns   Microsoft   One Microsoft Way   Redmond, WA, 98072   Phone: (206) 936-9833   EMail: mikega@microsoft.comGahrns                       Informational                     [Page 14]