IMAP4 Multi-Accessed Mailbox Practice
What an IMAP4 server may do when several clients are using the same mailbox at once.
Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180, DOI 10.17487/RFC2180, July 1997, <https://www.rfc-editor.org/info/rfc2180>.
@misc{rfc2180,
series = {Request for Comments},
number = 2180,
howpublished = {RFC 2180},
publisher = {RFC Editor},
doi = {10.17487/RFC2180},
url = {https://www.rfc-editor.org/info/rfc2180},
author = {M. Gahrns},
title = {{IMAP4 Multi-Accessed Mailbox Practice}},
pagetotal = 14,
year = 1997,
month = jul,
} RFC text
Contents
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.
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.
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:
<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.
<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 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)
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 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.
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>
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-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>
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[<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>
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 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.)
<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: * 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>
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.)
<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 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.
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).
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.
8. Author's Address
Mike Gahrns
Microsoft
One Microsoft Way
Redmond, WA, 98072
Phone: (206) 936-9833
EMail: mikega@microsoft.com
ISO Plain Language
On this page
§1Why This Memo Exists and Its Conventions
IMAP4 is a rich client and 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 and server interactions, and a protocol that does not allow for this 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 on its own architectural constraints or on individual preference.
With that flexibility comes greater client responsibility. It is not sufficient for a client to be written on the basis of the behaviour of a particular IMAP server; rather the client must be based on the behaviour allowed by the protocol. The memo documents common IMAP4 server practice for the case of simultaneous client access to a mailbox, in the hope of ensuring the widest amount of interoperation between IMAP4 clients and servers. The behaviour described reflects the practice of some existing servers, or behaviour that the consensus of the IMAP mailing list has deemed reasonable, and is believed to be compliant with RFC 2060. It is not meant to define IMAP4 compliance, nor is it an exhaustive list of valid behaviour, and RFC 2060 must always be consulted to determine compliance, especially for server behaviour not described in the memo.
The conventions used in the examples are simple. C1, C2 and C3 indicate lines sent by three different clients connected to a server, and S1, S2 and S3 indicate 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, and 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 protocol deliberately leaves some choices open, which gives servers room to behave in the way that suits their own storage. The cost is that clients have to handle more than one possible answer.
§3Deleting or Renaming 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 that mailbox. The memo lists four strategies a server may choose, and they are strategies rather than rules, so that a server can pick the one that suits it.
The first is to fail the DELETE or RENAME command of a multi-accessed mailbox. The server simply answers NO, for example "Mailbox FOO is in use by another user." This may not be practical, because if a large number of clients are accessing a shared mailbox the window in which no client has the mailbox accessed may be small or non-existent, which effectively renders the mailbox undeletable or unrenamable.
The second is to allow the DELETE command but keep the information in the mailbox available to the clients that currently have access to it. The mailbox is permanently removed when all clients have finished accessing it. For clients that do not already have access, the ghosted mailbox is not available: it would not be returned in a later LIST or LSUB command, and it would not be a valid mailbox argument to any other IMAP command, until the reference count of clients accessing it reached 0. In some cases this is not desirable, for instance when someone created a mailbox with offensive or sensitive information and would prefer the mailbox to be deleted and all access removed immediately rather than continuing until the client closes the mailbox. This behaviour may also prevent recycling of the same mailbox name until all clients have finished accessing the original mailbox.
The third is to allow the DELETE or RENAME and disconnect all other clients that have the mailbox accessed, by sending them an untagged BYE response. A server may often choose to disconnect clients in the DELETE case, but may implement a friendlier method for the RENAME case. The fourth is to allow the RENAME by simply changing the name attribute on the mailbox. Other clients that have access can continue issuing commands such as FETCH that do not reference the mailbox name, and they discover the renaming the next time they refer to the old mailbox name. Some servers may include the [NEWNAME] response code in their tagged NO response to a command that contained the old mailbox name, as a hint that the operation can succeed if it is issued with the new name.
Four things a server can do when asked to delete or rename a mailbox that someone else is using: say no, delete it later, kick the other users out, or just rename it and let the others find out.
| Strategy | What the server does | What the other clients see |
|---|---|---|
| Fail the command | Answers NO and changes nothing | The mailbox is unchanged |
| Allow DELETE and keep the data | Keeps the mailbox for the clients using it | Those clients keep working; others see the mailbox as gone |
| Allow DELETE and disconnect | Sends an untagged BYE to the other clients | The other clients are disconnected |
| Allow RENAME by renaming the attribute | Changes the name and leaves the mailbox in place | Commands naming the old mailbox fail, with a NEWNAME hint |
§4.1Fetching Messages That Have Been Expunged
If an external agent or multiple clients are accessing a mailbox, care must be taken when handling the EXPUNGE of messages. Other clients may be in the middle of issuing a command that depends on message sequence numbers. Because an EXPUNGE response cannot be sent while the server is responding to a FETCH, STORE or SEARCH command, it is not possible to notify the client of the EXPUNGE immediately, and this can leave ambiguity if the client then issues a FETCH, STORE or SEARCH on a message that has been expunged.
The memo's worked example has two clients with mailbox FOO selected, seven messages in the mailbox, messages 4 to 7 marked for deletion, and client 1 issuing an EXPUNGE for those messages. For a FETCH on those expunged messages, the server may keep them available to satisfy subsequent FETCH commands until it is able to send an EXPUNGE response to each client. The other client can then still fetch them, and learns of the expunges the next time it issues a command that allows the server to send them, for example a NOOP, after which the messages are no longer available. Keeping ghosted messages may not be desirable when a message contains offensive or sensitive information and immediate removal of access is preferred.
The second strategy is to return FETCH responses only for the non-expunged messages, together with a tagged NO. After a tagged NO FETCH response the client should issue a NOOP so that it is informed of any pending EXPUNGE responses, and can then either reissue the failed FETCH or, by examining the EXPUNGE response from the NOOP and the FETCH response, work out that the FETCH failed because of pending expunges. The third strategy is to return the usual FETCH responses for non-expunged messages, NIL FETCH responses for expunged messages, and a tagged OK. NIL FETCH responses are a representation of empty data as appropriate for the FETCH argument specified. If all the messages in the command have been expunged, the server should return only a tagged NO.
The memo notes one ambiguity with the third strategy: a client may not be able to distinguish between a NIL FETCH response caused by an expunged message and one caused by the data actually being NIL, for instance a FLAGS () response for a message with no flags set or for an expunged message. Where there is a potential ambiguity the client should issue a command such as NOOP to force the EXPUNGE responses to be sent. The fourth way to avoid the situation is for the server to fail the EXPUNGE of a multi-accessed mailbox altogether, which may not be practical if a large number of clients are accessing a shared mailbox, since the window in which there are no pending expunges may be small or non-existent.
A message that has been deleted is still referred to by number until the client is told. The server can keep it readable for a while, refuse the fetch, or return an empty answer, and the client has to be ready for all three.
- EXPUNGERemoves messages 4 to 7 while client 2 is still using the mailbox.
- NOOPA command that lets the server deliver the pending expunge responses.
- EXPUNGE x4 AND EXISTS 3The expunges could not be sent while a command was running, so they arrive with the NOOP.
§4.2Storing, Searching and Copying Expunged Messages
For a STORE command on expunged messages the memo gives four more strategies. If the .SILENT suffix is used and the STORE completed successfully for all the non-expunged messages, the server should return a tagged OK, since the client has asked not to be told about each message. If the .SILENT suffix is not used and only expunged messages are referenced, the server should return only a tagged NO.
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, or it may return an untagged NO and set no flags at all. In both cases, after a tagged NO STORE response the client should issue a NOOP so that it is informed of pending EXPUNGE responses. In the first case the client may then reissue the failed STORE, or work out from the EXPUNGE responses and the FETCH responses that the STORE failed because of pending expunges. In the second case the client reissues the STORE command after updating its message list from 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, which effectively disallows a client from setting the flags on all messages at once.
For SEARCH, a server may simply not return a search response for messages that have been expunged and that it has not yet been able to tell the client about. If a client expected a particular message to be in a search result and it was not, the client should issue a NOOP to see whether the message was expunged by another client.
COPY is the only IMAP4 sequence number command that is safe to allow an EXPUNGE response on, because a client is not permitted to cascade several COPY commands together: it must wait and confirm that the copy worked before issuing another one. A server may disallow the COPY of messages in a multi-access mailbox that contains expunged messages, and must then return the pending EXPUNGE responses and copy none of the messages, because if a COPY command is unsuccessful the server must restore the destination mailbox to its state before the attempt. Or the server may allow the COPY, return the pending EXPUNGE responses, and copy the messages that correspond to sequence numbers before any EXPUNGE response. The memo notes that the EXPUNGE response cannot take place until after the messages from the COPY command are identified, because of the rule that no expunge may be sent while commands are in progress.
The same problem comes up for commands that change flags, that search, and that copy mail. The client's rule of thumb is the same: if a command fails, ask for a NOOP so the server can tell you what has been removed.
- NOOP after a failureAfter a tagged NO, issue a NOOP so the server can send any pending expunge responses.
- NIL FETCH responsesEmpty data stands in for a message that has been expunged.
- The reference countA ghosted mailbox lasts until the last client closes it.
- COPY is specialIt is the only sequence number command that an expunge response may be sent with.
- Do not cascade COPYA client must wait for one COPY to finish before starting the next.
- Restore on failureIf a COPY fails, the destination mailbox must be put back as it was.
§5Security Considerations
The Security Considerations section says the document describes the behaviour of servers that use the IMAP4 protocol and so has the same security considerations as RFC 2060. In particular, some of the server behaviour described does not allow for the immediate deletion of information when a mailbox is accessed by multiple clients, and that may be a consideration when dealing with sensitive information where immediate deletion would be preferred.
Where a server keeps deleted messages readable for a while, a message that should have been gone can still be fetched. That matters for sensitive mail.