Network Working Group M. Gahrns Internet Draft Microsoft Document: draft-gahrns-imap-practice-00.txt March 1997 IMAP4 Implementation Practice Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire before September 1997. Distribution of this draft is unlimited. 1. Abstract IMAP4[rfc2060] 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. Gahrns 1 IMAP4 Implementation Practice March 1997 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 [RFC2060] compliant. However, this document is not meant to define IMAP4 compliance, nor is it and exhaustive list of valid IMAP4 behavior. [RFC2060] must always be consulted to determine IMAP4 compliance, especially for server behavior not described within this document. 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 have accessed a mailbox after a successful SELECT or EXAMINE command. SHOULD and MAY are terms that are defined in accordance with [RFC- 2060]. 3. Deletion/Renaming of a multi-accessed mailbox When multiple clients are accessing a mailbox, care must be taken when handling the deletion or renaming of the mailbox by one of the clients. Following are some strategies an IMAP server may choose to use when dealing with this. 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 2 IMAP4 Implementation Practice March 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, prevents 'recycling' of the same mailbox name until all clients have finished accessing the original mailbox. Example: <Client #1 and Client #2 have mailbox FOO accessed. 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 STATUS FOO (MESSAGES) S2: * STATUS FOO (MESSAGES 6) S2: B001 OK STATUS 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. <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 Gahrns 3 IMAP4 Implementation Practice March 1997 <Now that the reference count on FOO has reached 0, the mailbox name can be recycled> 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: <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. 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) Gahrns 4 IMAP4 Implementation Practice March 1997 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 STATUS FOO (MESSAGES) S2: B002 NO [NEWNAME FOO BAR] Mailbox has been renamed 4. Expunging of messages on a multi-accessed mailbox When 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. 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.) <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> Gahrns 5 IMAP4 Implementation Practice March 1997 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. 4.1.2 The server MAY allow the EXPUNGE of a multi-access mailbox, and on subsequent FETCH commands return a tagged NO, and FETCH responses only for the non-expunged messages. If all of the messages in the subsequent FETCH command have been expunged, the server SHOULD return only 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 Gahrns 6 IMAP4 Implementation Practice March 1997 S2: * EXPUNGE 4 S2: * EXPUNGE 4 S2: * EXPUNGE 4 S2: * EXPUNGE 4 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> 4.1.3 The server MAY allow the EXPUNGE of a multi-access mailbox, and on subsequent FETCH commands return a tagged OK, "NIL FETCH Responses" for expunged messages, and FETCH responses for non -expunged messages. 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. Gahrns 7 IMAP4 Implementation Practice March 1997 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> 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 SILENETLY 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 OK 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.) Gahrns 8 IMAP4 Implementation Practice March 1997 <Client #2 tries to STORE flags only on expunged messages> 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.) <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: * EXPUNGE 4 S2: * EXPUNGE 4 S2: * EXPUNGE 4 S2: * EXPUNGE 4 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> 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 only an untagged NO and not set any flags, nor return any FETCH responses 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. Gahrns 9 IMAP4 Implementation Practice March 1997 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: * EXPUNGE 4 S2: * EXPUNGE 4 S2: * EXPUNGE 4 S2: * EXPUNGE 4 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 Completed 4.2. 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. 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 Gahrns 10 IMAP4 Implementation Practice March 1997 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. 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, Jack De Winter, Jim Evans, Steve Hole, Mark Keasling, Barry Leiba, Pat Moran, Larry Osterman, Chris Newman, and Vladimir Vulovic were significant participants in this discussion or made suggestions to this document. 8. Author's Address Mike Gahrns Microsoft One Microsoft Way Redmond, WA, 98072 Phone: (206) 936-9833 Email: mikega@microsoft.co m Gahrns 11