As per Relevance of the word practice, we have this rfc below:
Network Working Group M.
Request for Comments: 2180
Category: Informational July 1997
IMAP4 Multi-Accessed Mailbox
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
1.
IMAP4[RFC-2060] is rich client/server protocol that allows a
to access and manipulate electronic mail messages on a server
Within the protocol framework, it is possible to have
results for particular client/server interactions. If a protocol
not allow for this, it is often unduly restrictive
For example, when multiple clients are accessing a mailbox and
attempts to delete the mailbox, an IMAP4 server may choose
implement a solution based upon server architectural constraints
individual preference
With this flexibility comes greater client responsibility. It is
sufficient for a client to be written based upon the behavior of
particular IMAP server. Rather the client must be based upon
behavior allowed by the protocol
By documenting common IMAP4 server practice for the case
simultaneous client access to a mailbox, we hope to ensure the
amount of inter-operation between IMAP4 clients and servers
The behavior described in this document reflects the practice of
existing servers or behavior that the consensus of the IMAP
list has deemed to be reasonable. The behavior described within
document is believed to be [RFC-2060] compliant. However,
document is not meant to define IMAP4 compliance, nor is it
exhaustive list of valid IMAP4 behavior. [RFC-2060] must always
consulted to determine IMAP4 compliance, especially for
behavior not described within this document
Gahrns Informational [Page 1]
RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
2. Conventions used in this
In examples,"C1:", "C2:" and "C3:" indicate lines sent by 3
clients (client #1, client #2 and client #3) that are connected to
server. "S1:", "S2:" and "S3:" indicated lines sent by the server
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
simultaneously accessing it
A client is said to have accessed a mailbox after a successful
or EXAMINE command
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC-2119].
3. Deletion/Renaming of a multi-accessed
If an external agent or multiple clients are accessing a mailbox
care must be taken when handling the deletion or renaming of
mailbox. Following are some strategies an IMAP server may choose
use when dealing with this situation
3.1. The server MAY fail the DELETE/RENAME command of a multi-
In some cases, this behavior may not be practical. For example, if
large number of clients are accessing a shared mailbox, the window
which no clients have the mailbox accessed may be small or non
existent, effectively rendering the mailbox undeletable
unrenamable
Example
to DELETE the mailbox and is refused
C1: A001 DELETE
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-
mailbox, but keep the information in the mailbox available
those clients that currently have access to the mailbox
When all clients have finished accessing the mailbox, it
permanently removed. For clients that do not already have access
the mailbox, the 'ghosted' mailbox would not be available.
example, it would not be returned to these clients in a
LIST or LSUB command and would not be a valid mailbox argument to
other IMAP command until the reference count of clients accessing
mailbox reached 0.
In some cases, this behavior may not be desirable. For example
someone created a mailbox with offensive or sensitive information
one might prefer to have the mailbox deleted and all access to
information contained within removed immediately, rather
continuing to allow access until the client closes the mailbox
Furthermore, this behavior, may prevent 'recycling' of the
mailbox name until all clients have finished accessing the
mailbox
Example
mailbox FOO
C1: A001 DELETE
S1: A001 OK Mailbox FOO is deleted
C2: B001 STORE 1 +FLAGS (\Seen
S2: * 1 FETCH FLAGS (\Seen
S2: B001 OK STORE
deletion by client #1 does not have access to the mailbox
C3: C001 STATUS FOO (MESSAGES
S3: C001 NO Mailbox does not
the reference count is non zero
C3: C002 CREATE
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
access to the mailbox FOO and reference count becomes 0>
C2: B002
S2: B002 OK CLOSE
reference count on FOO has reached 0, the mailbox
can be recycled
C3: C003 CREATE
S3: C003 OK CREATE
3.3. The server MAY allow the DELETE/RENAME of a multi-
mailbox, but disconnect all other clients who have the
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
case
Example
the mailbox FOO
C1: A002 DELETE
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
simply changing the name attribute on the mailbox
Other clients that have access to the mailbox can continue
commands such as FETCH that do not reference the mailbox name
Clients would discover the renaming the next time they referred
the old mailbox name. Some servers MAY choose to include
[NEWNAME] response code in their tagged NO response to a command
contained the old mailbox name, as a hint to the client that
operation can succeed if the command is issued with the new
name
Gahrns Informational [Page 4]
RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
Example
the mailbox.>
C1: A001 RENAME FOO
S1: A001 OK RENAME completed
operations that do not reference
mailbox name
C2: B001 FETCH 2:4 (FLAGS
S2: * 2 FETCH . . .
S2: * 3 FETCH . . .
S2: * 4 FETCH . . .
S2: B001 OK FETCH
operations that reference the
name
C2: B002 APPEND FOO {300} C2: Date: Mon, 7 Feb 1994
21:52:25 0800 (PST) C2: . . . S2: B002 NO [NEWNAME
BAR] Mailbox has been
4. Expunging of messages on a multi-accessed
If an external agent or multiple clients are accessing a mailbox
care must be taken when handling the EXPUNGE of messages.
clients accessing the mailbox may be in the midst of issuing
command that depends upon message sequence numbers. Because
EXPUNGE response can not be sent while responding to a FETCH,
or SEARCH command, it is not possible to immediately notify
client of the EXPUNGE. This can result in ambiguity if the
issues a FETCH, STORE or SEARCH operation on a message that has
EXPUNGED
4.1. Fetching of expunged
Following are some strategies an IMAP server may choose to use
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
keep the messages available to satisfy subsequent FETCH
until it is able to send an EXPUNGE response to each client
In some cases, the behavior of keeping "ghosted" messages may not
desirable. For example if a message contained offensive or
information, one might prefer to instantaneously remove all access
the information, regardless of whether another client is in the
of accessing it
Example: (Building upon the scenario outlined in 4.1.)
expunged messages because
server has kept a 'ghosted' copy of the messages until it is able
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
C2: B002
S2: * 4
S2: * 4
S2: * 4
S2: * 4
S2: * 3
S2: B002 OK NOOP
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 1997
4.1.2 The server MAY allow the EXPUNGE of a multi-accessed mailbox
and on subsequent FETCH commands return FETCH responses only
non-expunged messages and a tagged NO
After receiving a tagged NO FETCH response, the client SHOULD issue
NOOP command so that it will be informed of any pending
responses. The client may then either reissue the failed
command, or by examining the EXPUNGE response from the NOOP and
FETCH response from the FETCH, determine that the FETCH
because of pending expunges
Example: (Building upon the scenario outlined in 4.1.)
expunged and non-
messages. A FETCH response is returned only for then non-
messages along with a tagged NO
C2: B001 FETCH 3:5
S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned
S2: B001 NO Some of the requested messages no longer
receiving a tagged NO FETCH response, Client #2 issues a
to be informed of any pending EXPUNGE responses
C2: B002
S2: * 4
S2: * 4
S2: * 4
S2: * 4
S2: * 3
S2: B002 OK NOOP Completed
receiving a FETCH response for message 3, and an EXPUNGE
that indicates messages 4:7 have been expunged, the client does
need to re-issue the FETCH
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,
on subsequent FETCH commands return the usual FETCH responses
non-expunged messages, "NIL FETCH Responses" for
messages, and a tagged OK response
If all of the messages in the subsequent FETCH command have
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
any pending EXPUNGE responses. The client may then either
the failed FETCH command, or by examining the EXPUNGE response
the NOOP, determine that the FETCH failed because of
expunges
"NIL FETCH responses" are a representation of empty data
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 "
FETCH responses" received because a message was expunged and
received because the data actually was NIL. For example, a * 5
FETCH (FLAGS ()) response could be received if no flags were set
message 5, or because message 5 was expunged. In a case of
ambiguity, the client SHOULD issue a command such as NOOP to
the sending of the EXPUNGE responses to resolve any ambiguity
Example: (Building upon the scenario outlined in 4.1.)
expunged and non-
messages. Normal data is returned for non-expunged message, "
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
S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned
S2: * 4 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL
NIL NIL
S2: * 5 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL
NIL NIL
S2: B002 OK FETCH
expunged messages and receives
tagged NO response
C2: B002 FETCH 4:7
S2: B002 NO Messages 4:7 have been expunged
4.1.4 To avoid the situation altogether, the server MAY fail
EXPUNGE of a multi-accessed
In some cases, this behavior may not be practical. For example, if
large number of clients are accessing a shared mailbox, the window
which no clients have the mailbox accessed may be small or non
existent, effectively rendering the message unexpungeable
4.2. Storing of expunged
Following are some strategies an IMAP server may choose to use
dealing with a STORE command on expunged messages
4.2.1 If the ".SILENT" suffix is used, and the STORE
successfully for all the non-expunged messages, the server
return a tagged OK
Example: (Building upon the scenario outlined in 4.1.)
expunged and non
expunged messages. The server sets the flags on the non-
messages and returns OK
C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN
S2: B001
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
are referenced, the server SHOULD return only a tagged NO
Example: (Building upon the scenario outlined in 4.1.)
expunged messages
C2: B001 STORE 5:7 +FLAGS (\SEEN
S2: B001 NO Messages have been
4.2.3. If the ".SILENT" suffix is not used, and a mixture of
and non-expunged messages are referenced, the server MAY set
flags and return a FETCH response for the non-expunged
along with a tagged NO
After receiving a tagged NO STORE response, the client SHOULD issue
NOOP command so that it will be informed of any pending
responses. The client may then either reissue the failed
command, or by examining the EXPUNGE responses from the NOOP
FETCH responses from the STORE, determine that the STORE
because of pending expunges
Example: (Building upon the scenario outlined in 4.1.)
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
S2: * 4
S2: * 4
S2: * 4
S2: * 4
S2: * 3
S2: B002 OK NOOP Completed
receiving FETCH responses for messages 1:3, and an
response that indicates messages 4:7 have been expunged, the
does not need to re-issue the STORE
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
and non-expunged messages are referenced, the server MAY
an untagged NO and not set any flags
After receiving a tagged NO STORE response, the client SHOULD issue
NOOP command so that it will be informed of any pending
responses. The client would then re-issue the STORE command
updating its message list per any EXPUNGE response
If a large number of clients are accessing a shared mailbox,
window in which there are no pending expunges may be small or non
existent, effectively disallowing a client from setting the flags
all messages at once
Example: (Building upon the scenario outlined in 4.1.)
expunged and non
expunged messages
C2: B001 STORE 1:7 +FLAGS (\SEEN
S2: B001 NO Some of the messages no longer exist
informed of the EXPUNGED messages
C2: B002
S2: * 4
S2: * 4
S2: * 4
S2: * 4
S2: * 3
S2: B002 OK NOOP Completed
those messages that have not been expunged
C2: B003 STORE 1:3 +FLAGS (\SEEN) S2: * FETCH 1
(\SEEN) S2: * FETCH 2 FLAGS (\SEEN) S2: * FETCH 3
(\SEEN) S2: B003 OK STORE
4.3. Searching of expunged
A server MAY simply not return a search response for messages
have been expunged and it has not been able to inform the
about. If a client was expecting a particular message to be
in a search result, and it was not, the client SHOULD issue a
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
COPY is the only IMAP4 sequence number command that is safe to
an EXPUNGE response on. This is because a client is not permitted
cascade several COPY commands together. A client is required to
and confirm that the copy worked before issuing another one
4.4.1 The server MAY disallow the COPY of messages in a multi-
mailbox that contains expunged messages
Pending EXPUNGE response(s) MUST be returned to the COPY command
Example
C: A001 COPY 2,4,6,8
S: * 4
S: A001 NO COPY rejected, because some of the
messages were
Note: Non of the above messages are copied because if a COPY
is unsuccessful, the server MUST restore the destination mailbox
its state before the COPY attempt
4.4.2 The server MAY allow the COPY of messages in a multi-
mailbox that contains expunged messages
Pending EXPUNGE response(s) MUST be returned to the COPY command
Messages that are copied are messages corresponding to
numbers before any EXPUNGE response
Example
C: A001 COPY 2,4,6,8
S: * 3
S: A001 OK COPY
In the above example, the messages that are copied to FRED
messages 2,4,6,8 at the start of the COPY command. These
equivalent to messages 2,3,5,7 at the end of the COPY command.
EXPUNGE response can't take place until after the messages from
COPY command are identified (because of the "no expunge while
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
S: * 4
S: A001 OK COPY
In the above example, message 4 was copied before it was expunged
and MUST appear in the destination mailbox FRED
5. Security
This document describes behavior of servers that use the IMAP
protocol, and as such, has the same security considerations
described in [RFC-2060].
In particular, some described server behavior does not allow for
immediate deletion of information when a mailbox is accessed
multiple clients. This may be a consideration when dealing
sensitive information where immediate deletion would be preferred
6.
[RFC-2060], Crispin, M., "Internet Message Access Protocol -
4rev1", RFC 2060, University of Washington, December 1996.
[RFC-2119], Bradner, S., "Key words for use in RFCs to
Requirement Levels", RFC 2119, Harvard University, March 1997.
7.
This document is the result of discussions on the IMAP4 mailing
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,
Osterman, Chris Newman, Bart Schaefer, Vladimir Vulovic, and Jack
Winter were active participants in this discussion or
suggestions to this document
Gahrns Informational [Page 13]
RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
8. Author's
Mike
One Microsoft
Redmond, WA, 98072
Phone: (206) 936-9833
EMail: mikega@microsoft.
Gahrns Informational [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
