1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc2180.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,787 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                          M. Gahrns
    1.11 +Request for Comments: 2180                                     Microsoft
    1.12 +Category: Informational                                        July 1997
    1.13 +
    1.14 +
    1.15 +                 IMAP4 Multi-Accessed Mailbox Practice
    1.16 +
    1.17 +Status of this Memo
    1.18 +
    1.19 +   This memo provides information for the Internet community.  This memo
    1.20 +   does not specify an Internet standard of any kind.  Distribution of
    1.21 +   this memo is unlimited.
    1.22 +
    1.23 +1. Abstract
    1.24 +
    1.25 +   IMAP4[RFC-2060] is rich client/server protocol that allows a client
    1.26 +   to access and manipulate electronic mail messages on a server.
    1.27 +   Within the protocol framework, it is possible to have differing
    1.28 +   results for particular client/server interactions. If a protocol does
    1.29 +   not allow for this, it is often unduly restrictive.
    1.30 +
    1.31 +   For example, when multiple clients are accessing a mailbox and one
    1.32 +   attempts to delete the mailbox, an IMAP4 server may choose to
    1.33 +   implement a solution based upon server architectural constraints or
    1.34 +   individual preference.
    1.35 +
    1.36 +   With this flexibility comes greater client responsibility.  It is not
    1.37 +   sufficient for a client to be written based upon the behavior of a
    1.38 +   particular IMAP server.  Rather the client must be based upon the
    1.39 +   behavior allowed by the protocol.
    1.40 +
    1.41 +   By documenting common IMAP4 server practice for the case of
    1.42 +   simultaneous client access to a mailbox, we hope to ensure the widest
    1.43 +   amount of inter-operation between IMAP4 clients and servers.
    1.44 +
    1.45 +   The behavior described in this document reflects the practice of some
    1.46 +   existing servers or behavior that the consensus of the IMAP mailing
    1.47 +   list has deemed to be reasonable.  The behavior described within this
    1.48 +   document is believed to be [RFC-2060] compliant. However, this
    1.49 +   document is not meant to define IMAP4 compliance, nor is it an
    1.50 +   exhaustive list of valid IMAP4 behavior. [RFC-2060] must always be
    1.51 +   consulted to determine IMAP4 compliance, especially for server
    1.52 +   behavior not described within this document.
    1.53 +
    1.54 +
    1.55 +
    1.56 +
    1.57 +
    1.58 +
    1.59 +
    1.60 +
    1.61 +Gahrns                       Informational                      [Page 1]
    1.62 +
    1.63 +RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
    1.64 +
    1.65 +
    1.66 +2. Conventions used in this document
    1.67 +
    1.68 +   In examples,"C1:", "C2:" and "C3:" indicate lines sent by 3 different
    1.69 +   clients (client #1, client #2 and client #3) that are connected to a
    1.70 +   server.  "S1:", "S2:" and "S3:" indicated lines sent by the server to
    1.71 +   client #1, client #2 and client #3 respectively.
    1.72 +
    1.73 +   A shared mailbox, is a mailbox that can be used by multiple users.
    1.74 +
    1.75 +   A multi-accessed mailbox, is a mailbox that has multiple clients
    1.76 +   simultaneously accessing it.
    1.77 +
    1.78 +   A client is said to have accessed a mailbox after a successful SELECT
    1.79 +   or EXAMINE command.
    1.80 +
    1.81 +   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    1.82 +   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
    1.83 +   document are to be interpreted as described in [RFC-2119].
    1.84 +
    1.85 +
    1.86 +3. Deletion/Renaming of a multi-accessed mailbox
    1.87 +
    1.88 +   If an external agent or multiple clients are accessing a mailbox,
    1.89 +   care must be taken when handling the deletion or renaming of the
    1.90 +   mailbox. Following are some strategies an IMAP server may choose to
    1.91 +   use when dealing with this situation.
    1.92 +
    1.93 +
    1.94 +3.1. The server MAY fail the DELETE/RENAME command of a multi-accessed
    1.95 +     mailbox
    1.96 +
    1.97 +   In some cases, this behavior may not be practical.  For example, if a
    1.98 +   large number of clients are accessing a shared mailbox, the window in
    1.99 +   which no clients have the mailbox accessed may be small or non-
   1.100 +   existent, effectively rendering the mailbox undeletable or
   1.101 +   unrenamable.
   1.102 +
   1.103 +   Example:
   1.104 +
   1.105 +   <Client #1 and Client #2 have mailbox FOO accessed. Client #1 tries
   1.106 +   to DELETE the mailbox and is refused>
   1.107 +
   1.108 +             C1: A001 DELETE FOO
   1.109 +             S1: A001 NO Mailbox FOO is in use by another user.
   1.110 +
   1.111 +
   1.112 +
   1.113 +
   1.114 +
   1.115 +
   1.116 +
   1.117 +Gahrns                       Informational                      [Page 2]
   1.118 +
   1.119 +RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
   1.120 +
   1.121 +
   1.122 +3.2. The server MAY allow the DELETE command of a multi-accessed
   1.123 +     mailbox, but keep the information in the mailbox available for
   1.124 +     those clients that currently have access to the mailbox.
   1.125 +
   1.126 +   When all clients have finished accessing the mailbox, it is
   1.127 +   permanently removed.  For clients that do not already have access to
   1.128 +   the mailbox, the 'ghosted' mailbox would not be available.  For
   1.129 +   example, it would not be returned to these clients in a subsequent
   1.130 +   LIST or LSUB command and would not be a valid mailbox argument to any
   1.131 +   other IMAP command until the reference count of clients accessing the
   1.132 +   mailbox reached 0.
   1.133 +
   1.134 +   In some cases, this behavior may not be desirable. For example if
   1.135 +   someone created a mailbox with offensive or sensitive information,
   1.136 +   one might prefer to have the mailbox deleted and all access to the
   1.137 +   information contained within removed immediately, rather than
   1.138 +   continuing to allow access until the client closes the mailbox.
   1.139 +
   1.140 +   Furthermore, this behavior, may prevent 'recycling' of the same
   1.141 +   mailbox name until all clients have finished accessing the original
   1.142 +   mailbox.
   1.143 +
   1.144 +   Example:
   1.145 +
   1.146 +   <Client #1 and Client #2 have mailbox FOO selected. Client #1 DELETEs
   1.147 +   mailbox FOO>
   1.148 +
   1.149 +             C1: A001 DELETE FOO
   1.150 +             S1: A001 OK Mailbox FOO is deleted.
   1.151 +
   1.152 +   <Client #2 is still able to operate on the deleted mailbox>
   1.153 +
   1.154 +             C2: B001 STORE 1 +FLAGS (\Seen)
   1.155 +             S2: * 1 FETCH FLAGS (\Seen)
   1.156 +             S2: B001 OK STORE completed
   1.157 +
   1.158 +   <Client #3 which did not have access to the mailbox prior to the
   1.159 +   deletion by client #1 does not have access to the mailbox>
   1.160 +
   1.161 +             C3: C001 STATUS FOO (MESSAGES)
   1.162 +             S3: C001 NO Mailbox does not exist
   1.163 +
   1.164 +   <Nor is client #3 able to create a mailbox with the name FOO, while
   1.165 +   the reference count is non zero>
   1.166 +
   1.167 +             C3: C002 CREATE FOO
   1.168 +             S3: C002 NO Mailbox FOO is still in use. Try again later.
   1.169 +
   1.170 +
   1.171 +
   1.172 +
   1.173 +Gahrns                       Informational                      [Page 3]
   1.174 +
   1.175 +RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
   1.176 +
   1.177 +
   1.178 +   <Client #2 closes its access to the mailbox, no other clients have
   1.179 +   access to the mailbox FOO and reference count becomes 0>
   1.180 +
   1.181 +             C2: B002 CLOSE
   1.182 +             S2: B002 OK CLOSE Completed
   1.183 +
   1.184 +   <Now that the reference count on FOO has reached 0, the mailbox name
   1.185 +   can be recycled>
   1.186 +
   1.187 +             C3: C003 CREATE FOO
   1.188 +             S3: C003 OK CREATE Completed
   1.189 +
   1.190 +
   1.191 +3.3. The server MAY allow the DELETE/RENAME of a multi-accessed
   1.192 +     mailbox, but disconnect all other clients who have the mailbox
   1.193 +     accessed by sending a untagged BYE response.
   1.194 +
   1.195 +   A server may often choose to disconnect clients in the DELETE case,
   1.196 +   but may choose to implement a "friendlier" method for the RENAME
   1.197 +   case.
   1.198 +
   1.199 +   Example:
   1.200 +
   1.201 +   <Client #1 and Client #2 have mailbox FOO accessed. Client #1 DELETEs
   1.202 +   the mailbox FOO>
   1.203 +
   1.204 +             C1: A002 DELETE FOO
   1.205 +             S1: A002 OK DELETE completed.
   1.206 +
   1.207 +   <Server disconnects all other users of the mailbox>
   1.208 +             S2: * BYE Mailbox FOO has been deleted.
   1.209 +
   1.210 +
   1.211 +3.4. The server MAY allow the RENAME of a multi-accessed mailbox by
   1.212 +     simply changing the name attribute on the mailbox.
   1.213 +
   1.214 +   Other clients that have access to the mailbox can continue issuing
   1.215 +   commands such as FETCH that do not reference the mailbox name.
   1.216 +   Clients would discover the renaming the next time they referred to
   1.217 +   the old mailbox name.  Some servers MAY choose to include the
   1.218 +   [NEWNAME] response code in their tagged NO response to a command that
   1.219 +   contained the old mailbox name, as a hint to the client that the
   1.220 +   operation can succeed if the command is issued with the new mailbox
   1.221 +   name.
   1.222 +
   1.223 +
   1.224 +
   1.225 +
   1.226 +
   1.227 +
   1.228 +
   1.229 +Gahrns                       Informational                      [Page 4]
   1.230 +
   1.231 +RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
   1.232 +
   1.233 +
   1.234 +   Example:
   1.235 +
   1.236 +   <Client #1 and Client #2 have mailbox FOO accessed. Client #1 RENAMEs
   1.237 +   the mailbox.>
   1.238 +
   1.239 +             C1: A001 RENAME FOO BAR
   1.240 +             S1: A001 OK RENAME completed.
   1.241 +
   1.242 +   <Client #2 is still able to do operations that do not reference the
   1.243 +   mailbox name>
   1.244 +
   1.245 +             C2: B001 FETCH 2:4 (FLAGS)
   1.246 +             S2: * 2 FETCH . . .
   1.247 +             S2: * 3 FETCH . . .
   1.248 +             S2: * 4 FETCH . . .
   1.249 +             S2: B001 OK FETCH completed
   1.250 +
   1.251 +   <Client #2 is not able to do operations that reference the mailbox
   1.252 +   name>
   1.253 +
   1.254 +             C2: B002 APPEND FOO {300} C2: Date: Mon, 7 Feb 1994
   1.255 +             21:52:25 0800 (PST) C2: . . .  S2: B002 NO [NEWNAME FOO
   1.256 +             BAR] Mailbox has been renamed
   1.257 +
   1.258 +
   1.259 +4. Expunging of messages on a multi-accessed mailbox
   1.260 +
   1.261 +   If an external agent or multiple clients are accessing a mailbox,
   1.262 +   care must be taken when handling the EXPUNGE of messages.  Other
   1.263 +   clients accessing the mailbox may be in the midst of issuing a
   1.264 +   command that depends upon message sequence numbers.  Because an
   1.265 +   EXPUNGE response can not be sent while responding to a FETCH, STORE
   1.266 +   or SEARCH command, it is not possible to immediately notify the
   1.267 +   client of the EXPUNGE.  This can result in ambiguity if the client
   1.268 +   issues a FETCH, STORE or SEARCH operation on a message that has been
   1.269 +   EXPUNGED.
   1.270 +
   1.271 +
   1.272 +4.1. Fetching of expunged messages
   1.273 +
   1.274 +   Following are some strategies an IMAP server may choose to use when
   1.275 +   dealing with a FETCH command on expunged messages.
   1.276 +
   1.277 +
   1.278 +
   1.279 +
   1.280 +
   1.281 +
   1.282 +
   1.283 +
   1.284 +
   1.285 +Gahrns                       Informational                      [Page 5]
   1.286 +
   1.287 +RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
   1.288 +
   1.289 +
   1.290 +   Consider the following scenario:
   1.291 +
   1.292 +   - Client #1 and Client #2 have mailbox FOO selected.
   1.293 +   - There are 7 messages in the mailbox.
   1.294 +   - Messages 4:7 are marked for deletion.
   1.295 +   - Client #1 issues an EXPUNGE, to expunge messages 4:7
   1.296 +
   1.297 +
   1.298 +4.1.1. The server MAY allow the EXPUNGE of a multi-accessed mailbox but
   1.299 +       keep the messages available to satisfy subsequent FETCH commands
   1.300 +       until it is able to send an EXPUNGE response to each client.
   1.301 +
   1.302 +   In some cases, the behavior of keeping "ghosted" messages may not be
   1.303 +   desirable.  For example if a message contained offensive or sensitive
   1.304 +   information, one might prefer to instantaneously remove all access to
   1.305 +   the information, regardless of whether another client is in the midst
   1.306 +   of accessing it.
   1.307 +
   1.308 +   Example:  (Building upon the scenario outlined in 4.1.)
   1.309 +
   1.310 +   <Client #2 is still able to access the expunged messages because the
   1.311 +   server has kept a 'ghosted' copy of the messages until it is able to
   1.312 +   notify client #2 of the EXPUNGE>
   1.313 +
   1.314 +             C2: B001 FETCH 4:7 RFC822
   1.315 +             S2: * 4 FETCH RFC822 . . . (RFC822 info returned)
   1.316 +             S2: * 5 FETCH RFC822 . . . (RFC822 info returned)
   1.317 +             S2: * 6 FETCH RFC822 . . . (RFC822 info returned)
   1.318 +             S2: * 7 FETCH RFC822 . . . (RFC822 info returned)
   1.319 +             S2: B001 OK FETCH Completed
   1.320 +
   1.321 +   <Client #2 issues a command where it can get notified of the EXPUNGE>
   1.322 +
   1.323 +             C2: B002 NOOP
   1.324 +             S2: * 4 EXPUNGE
   1.325 +             S2: * 4 EXPUNGE
   1.326 +             S2: * 4 EXPUNGE
   1.327 +             S2: * 4 EXPUNGE
   1.328 +             S2: * 3 EXISTS
   1.329 +             S2: B002 OK NOOP Complete
   1.330 +
   1.331 +   <Client #2 no longer has access to the expunged messages>
   1.332 +
   1.333 +             C2: B003 FETCH 4:7 RFC822
   1.334 +             S2: B003 NO Messages 4:7 are no longer available.
   1.335 +
   1.336 +
   1.337 +
   1.338 +
   1.339 +
   1.340 +
   1.341 +Gahrns                       Informational                      [Page 6]
   1.342 +
   1.343 +RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
   1.344 +
   1.345 +
   1.346 +4.1.2 The server MAY allow the EXPUNGE of a multi-accessed mailbox,
   1.347 +      and on subsequent FETCH commands return FETCH responses only for
   1.348 +      non-expunged messages and a tagged NO.
   1.349 +
   1.350 +   After receiving a tagged NO FETCH response, the client SHOULD issue a
   1.351 +   NOOP command so that it will be informed of any pending EXPUNGE
   1.352 +   responses.  The client may then either reissue the failed FETCH
   1.353 +   command, or by examining the EXPUNGE response from the NOOP and the
   1.354 +   FETCH response from the FETCH, determine that the FETCH failed
   1.355 +   because of pending expunges.
   1.356 +
   1.357 +   Example:  (Building upon the scenario outlined in 4.1.)
   1.358 +
   1.359 +   <Client #2 attempts to FETCH a mix of expunged and non-expunged
   1.360 +   messages.  A FETCH response is returned only for then non-expunged
   1.361 +   messages along with a tagged NO>
   1.362 +
   1.363 +             C2: B001 FETCH 3:5 ENVELOPE
   1.364 +             S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)
   1.365 +             S2: B001 NO Some of the requested messages no longer exist
   1.366 +
   1.367 +   <Upon receiving a tagged NO FETCH response, Client #2 issues a NOOP
   1.368 +   to be informed of any pending EXPUNGE responses>
   1.369 +
   1.370 +             C2: B002 NOOP
   1.371 +             S2: * 4 EXPUNGE
   1.372 +             S2: * 4 EXPUNGE
   1.373 +             S2: * 4 EXPUNGE
   1.374 +             S2: * 4 EXPUNGE
   1.375 +             S2: * 3 EXISTS
   1.376 +             S2: B002 OK NOOP Completed.
   1.377 +
   1.378 +   <By receiving a FETCH response for message 3, and an EXPUNGE response
   1.379 +   that indicates messages 4:7 have been expunged, the client does not
   1.380 +   need to re-issue the FETCH>
   1.381 +
   1.382 +
   1.383 +
   1.384 +
   1.385 +
   1.386 +
   1.387 +
   1.388 +
   1.389 +
   1.390 +
   1.391 +
   1.392 +
   1.393 +
   1.394 +
   1.395 +
   1.396 +
   1.397 +Gahrns                       Informational                      [Page 7]
   1.398 +
   1.399 +RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
   1.400 +
   1.401 +
   1.402 +4.1.3 The server MAY allow the EXPUNGE of a multi-accessed mailbox, and
   1.403 +      on subsequent FETCH commands return the usual FETCH responses for
   1.404 +      non-expunged messages, "NIL FETCH Responses" for expunged
   1.405 +      messages, and a tagged OK response.
   1.406 +
   1.407 +   If all of the messages in the subsequent FETCH command have been
   1.408 +   expunged, the server SHOULD return only a tagged NO.  In this case,
   1.409 +   the client SHOULD issue a NOOP command so that it will be informed of
   1.410 +   any pending EXPUNGE responses.  The client may then either reissue
   1.411 +   the failed FETCH command, or by examining the EXPUNGE response from
   1.412 +   the NOOP, determine that the FETCH failed because of pending
   1.413 +   expunges.
   1.414 +
   1.415 +   "NIL FETCH responses" are a representation of empty data as
   1.416 +   appropriate for the FETCH argument specified.
   1.417 +
   1.418 +   Example:
   1.419 +
   1.420 +   * 1 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL))
   1.421 +   * 1 FETCH (FLAGS ())
   1.422 +   * 1 FETCH (INTERNALDATE "00-Jan-0000 00:00:00 +0000")
   1.423 +   * 1 FETCH (RFC822 "")
   1.424 +   * 1 FETCH (RFC822.HEADER "")
   1.425 +   * 1 FETCH (RFC822.TEXT "")
   1.426 +   * 1 FETCH (RFC822.SIZE 0)
   1.427 +   * 1 FETCH (BODY ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
   1.428 +   * 1 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
   1.429 +   * 1 FETCH (BODY[<section>] "")
   1.430 +   * 1 FETCH (BODY[<section>]<partial> "")
   1.431 +
   1.432 +   In some cases, a client may not be able to distinguish between "NIL
   1.433 +   FETCH responses" received because a message was expunged and those
   1.434 +   received because the data actually was NIL.  For example, a  * 5
   1.435 +   FETCH (FLAGS ()) response could be received if no flags were set on
   1.436 +   message 5, or because message 5 was expunged. In a case of potential
   1.437 +   ambiguity, the client SHOULD issue a command such as NOOP to force
   1.438 +   the sending of the EXPUNGE responses to resolve any ambiguity.
   1.439 +
   1.440 +   Example:  (Building upon the scenario outlined in 4.1.)
   1.441 +
   1.442 +   <Client #2 attempts to access a mix of expunged and non-expunged
   1.443 +   messages.  Normal data is returned for non-expunged message, "NIL
   1.444 +   FETCH responses" are returned for expunged messages>
   1.445 +
   1.446 +
   1.447 +
   1.448 +
   1.449 +
   1.450 +
   1.451 +
   1.452 +
   1.453 +Gahrns                       Informational                      [Page 8]
   1.454 +
   1.455 +RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
   1.456 +
   1.457 +
   1.458 +             C2: B002 FETCH 3:5 ENVELOPE
   1.459 +             S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)
   1.460 +             S2: * 4 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL
   1.461 +                   NIL NIL)
   1.462 +             S2: * 5 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL
   1.463 +                   NIL NIL)
   1.464 +             S2: B002 OK FETCH Completed
   1.465 +
   1.466 +   <Client #2 attempts to FETCH only expunged messages and receives a
   1.467 +   tagged NO response>
   1.468 +
   1.469 +             C2: B002 FETCH 4:7 ENVELOPE
   1.470 +             S2: B002 NO Messages 4:7 have been expunged.
   1.471 +
   1.472 +
   1.473 +4.1.4 To avoid the situation altogether, the server MAY fail the
   1.474 +      EXPUNGE of a multi-accessed mailbox
   1.475 +
   1.476 +   In some cases, this behavior may not be practical.  For example, if a
   1.477 +   large number of clients are accessing a shared mailbox, the window in
   1.478 +   which no clients have the mailbox accessed may be small or non-
   1.479 +   existent, effectively rendering the message unexpungeable.
   1.480 +
   1.481 +
   1.482 +4.2. Storing of expunged messages
   1.483 +
   1.484 +   Following are some strategies an IMAP server may choose to use when
   1.485 +   dealing with a STORE command on expunged messages.
   1.486 +
   1.487 +
   1.488 +4.2.1 If the ".SILENT" suffix is used, and the STORE completed
   1.489 +      successfully for all the non-expunged messages, the server SHOULD
   1.490 +      return a tagged OK.
   1.491 +
   1.492 +   Example:  (Building upon the scenario outlined in 4.1.)
   1.493 +
   1.494 +   <Client #2 tries to silently STORE flags on expunged and non-
   1.495 +   expunged messages.  The server sets the flags on the non-expunged
   1.496 +   messages and returns OK>
   1.497 +
   1.498 +             C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN)
   1.499 +             S2: B001 OK
   1.500 +
   1.501 +
   1.502 +
   1.503 +
   1.504 +
   1.505 +
   1.506 +
   1.507 +
   1.508 +
   1.509 +Gahrns                       Informational                      [Page 9]
   1.510 +
   1.511 +RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
   1.512 +
   1.513 +
   1.514 +4.2.2. If the ".SILENT" suffix is not used, and only expunged messages
   1.515 +       are referenced, the server SHOULD return only a tagged NO.
   1.516 +
   1.517 +   Example:  (Building upon the scenario outlined in 4.1.)
   1.518 +
   1.519 +   <Client #2 tries to STORE flags only on expunged messages>
   1.520 +
   1.521 +             C2: B001 STORE 5:7 +FLAGS (\SEEN)
   1.522 +             S2: B001 NO  Messages have been expunged
   1.523 +
   1.524 +
   1.525 +4.2.3. If the ".SILENT" suffix is not used, and a mixture of expunged
   1.526 +       and non-expunged messages are referenced, the server MAY set the
   1.527 +       flags and return a FETCH response for the non-expunged messages
   1.528 +       along with a tagged NO.
   1.529 +
   1.530 +   After receiving a tagged NO STORE response, the client SHOULD issue a
   1.531 +   NOOP command so that it will be informed of any pending EXPUNGE
   1.532 +   responses.  The client may then either reissue the failed STORE
   1.533 +   command, or by examining the EXPUNGE responses from the NOOP and
   1.534 +   FETCH responses from the STORE, determine that the STORE failed
   1.535 +   because of pending expunges.
   1.536 +
   1.537 +   Example:  (Building upon the scenario outlined in 4.1.)
   1.538 +
   1.539 +   <Client #2 tries to STORE flags on a mixture of expunged and non-
   1.540 +   expunged messages>
   1.541 +
   1.542 +             C2: B001 STORE 1:7 +FLAGS (\SEEN)
   1.543 +             S2: * FETCH 1 FLAGS (\SEEN)
   1.544 +             S2: * FETCH 2 FLAGS (\SEEN)
   1.545 +             S2: * FETCH 3 FLAGS (\SEEN)
   1.546 +             S2: B001 NO Some of the messages no longer exist.
   1.547 +
   1.548 +             C2: B002 NOOP
   1.549 +             S2: * 4 EXPUNGE
   1.550 +             S2: * 4 EXPUNGE
   1.551 +             S2: * 4 EXPUNGE
   1.552 +             S2: * 4 EXPUNGE
   1.553 +             S2: * 3 EXISTS
   1.554 +             S2: B002 OK NOOP Completed.
   1.555 +
   1.556 +   <By receiving FETCH responses for messages 1:3, and an EXPUNGE
   1.557 +   response that indicates messages 4:7 have been expunged, the client
   1.558 +   does not need to re-issue the STORE>
   1.559 +
   1.560 +
   1.561 +
   1.562 +
   1.563 +
   1.564 +
   1.565 +Gahrns                       Informational                     [Page 10]
   1.566 +
   1.567 +RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
   1.568 +
   1.569 +
   1.570 +4.2.4. If the ".SILENT" suffix is not used, and a mixture of expunged
   1.571 +       and non-expunged messages are referenced, the server MAY return
   1.572 +       an untagged NO and not set any flags.
   1.573 +
   1.574 +   After receiving a tagged NO STORE response, the client SHOULD issue a
   1.575 +   NOOP command so that it will be informed of any pending EXPUNGE
   1.576 +   responses.  The client would then re-issue the STORE command after
   1.577 +   updating its message list per any EXPUNGE response.
   1.578 +
   1.579 +   If a large number of clients are accessing a shared mailbox, the
   1.580 +   window in which there are no pending expunges may be small or non-
   1.581 +   existent, effectively disallowing a client from setting the flags on
   1.582 +   all messages at once.
   1.583 +
   1.584 +   Example:  (Building upon the scenario outlined in 4.1.)
   1.585 +
   1.586 +   <Client #2 tries to STORE flags on a mixture of expunged and non-
   1.587 +   expunged messages>
   1.588 +
   1.589 +             C2: B001 STORE 1:7 +FLAGS (\SEEN)
   1.590 +             S2: B001 NO  Some of the messages no longer exist.
   1.591 +
   1.592 +   <Client #2 issues a NOOP to be informed of the EXPUNGED messages>
   1.593 +
   1.594 +             C2: B002 NOOP
   1.595 +             S2: * 4 EXPUNGE
   1.596 +             S2: * 4 EXPUNGE
   1.597 +             S2: * 4 EXPUNGE
   1.598 +             S2: * 4 EXPUNGE
   1.599 +             S2: * 3 EXISTS
   1.600 +             S2: B002 OK NOOP Completed.
   1.601 +
   1.602 +   <Client #2 updates its message list and re-issues the STORE on only
   1.603 +   those messages that have not been expunged>
   1.604 +
   1.605 +             C2: B003 STORE 1:3 +FLAGS (\SEEN) S2: * FETCH 1 FLAGS
   1.606 +             (\SEEN) S2: * FETCH 2 FLAGS (\SEEN) S2: * FETCH 3 FLAGS
   1.607 +             (\SEEN) S2: B003 OK  STORE Completed
   1.608 +
   1.609 +
   1.610 +4.3. Searching of expunged messages
   1.611 +
   1.612 +   A server MAY simply not return a search response for messages that
   1.613 +   have been expunged and it has not been able to inform the client
   1.614 +   about.  If a client was expecting a particular message to be returned
   1.615 +   in a search result, and it was not, the client SHOULD issue a NOOP
   1.616 +   command to see if the message was expunged by another client.
   1.617 +
   1.618 +
   1.619 +
   1.620 +
   1.621 +Gahrns                       Informational                     [Page 11]
   1.622 +
   1.623 +RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
   1.624 +
   1.625 +
   1.626 +4.4 Copying of expunged messages
   1.627 +
   1.628 +   COPY is the only IMAP4 sequence number command that is safe to allow
   1.629 +   an EXPUNGE response on.  This is because a client is not permitted to
   1.630 +   cascade several COPY commands together. A client is required to wait
   1.631 +   and confirm that the copy worked before issuing another one.
   1.632 +
   1.633 +4.4.1 The server MAY disallow the COPY of messages in a multi-access
   1.634 +      mailbox that contains expunged messages.
   1.635 +
   1.636 +   Pending EXPUNGE response(s) MUST be returned to the COPY command.
   1.637 +
   1.638 +   Example:
   1.639 +
   1.640 +             C: A001 COPY 2,4,6,8 FRED
   1.641 +             S: * 4 EXPUNGE
   1.642 +             S: A001 NO COPY rejected, because some of the requested
   1.643 +                messages were expunged
   1.644 +
   1.645 +   Note: Non of the above messages are copied because if a COPY command
   1.646 +   is unsuccessful, the server MUST restore the destination mailbox to
   1.647 +   its state before the COPY attempt.
   1.648 +
   1.649 +
   1.650 +4.4.2 The server MAY allow the COPY of messages in a multi-access
   1.651 +      mailbox that contains expunged messages.
   1.652 +
   1.653 +   Pending EXPUNGE response(s) MUST be returned to the COPY command.
   1.654 +   Messages that are copied are messages corresponding to sequence
   1.655 +   numbers before any EXPUNGE response.
   1.656 +
   1.657 +   Example:
   1.658 +
   1.659 +             C: A001 COPY 2,4,6,8 FRED
   1.660 +             S: * 3 EXPUNGE
   1.661 +             S: A001 OK COPY completed
   1.662 +
   1.663 +   In the above example, the messages that are copied to FRED are
   1.664 +   messages 2,4,6,8 at the start of the COPY command.  These are
   1.665 +   equivalent to messages 2,3,5,7 at the end of the COPY command.  The
   1.666 +   EXPUNGE response can't take place until after the messages from the
   1.667 +   COPY command are identified (because of the "no expunge while no
   1.668 +   commands in progress" rule).
   1.669 +
   1.670 +
   1.671 +
   1.672 +
   1.673 +
   1.674 +
   1.675 +
   1.676 +
   1.677 +Gahrns                       Informational                     [Page 12]
   1.678 +
   1.679 +RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
   1.680 +
   1.681 +
   1.682 +   Example:
   1.683 +
   1.684 +             C: A001 COPY 2,4,6,8 FRED
   1.685 +             S: * 4 EXPUNGE
   1.686 +             S: A001 OK COPY completed
   1.687 +
   1.688 +   In the above example, message 4 was copied before it was expunged,
   1.689 +   and MUST appear in the destination mailbox FRED.
   1.690 +
   1.691 +
   1.692 +5. Security Considerations
   1.693 +
   1.694 +   This document describes behavior of servers that use the IMAP4
   1.695 +   protocol, and as such, has the same security considerations as
   1.696 +   described in [RFC-2060].
   1.697 +
   1.698 +   In particular, some described server behavior does not allow for the
   1.699 +   immediate deletion of information when a mailbox is accessed by
   1.700 +   multiple clients.  This may be a consideration when dealing with
   1.701 +   sensitive information where immediate deletion would be preferred.
   1.702 +
   1.703 +
   1.704 +6. References
   1.705 +
   1.706 +   [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
   1.707 +   4rev1", RFC 2060, University of Washington, December 1996.
   1.708 +
   1.709 +   [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
   1.710 +   Requirement Levels", RFC 2119, Harvard University, March 1997.
   1.711 +
   1.712 +
   1.713 +7.  Acknowledgments
   1.714 +
   1.715 +   This document is the result of discussions on the IMAP4 mailing list
   1.716 +   and is meant to reflect consensus of this group.  In particular,
   1.717 +   Raymond Cheng, Mark Crispin, Jim Evans, Erik Forsberg, Steve Hole,
   1.718 +   Mark Keasling, Barry Leiba, Syd Logan, John Mani, Pat Moran, Larry
   1.719 +   Osterman, Chris Newman, Bart Schaefer, Vladimir Vulovic, and Jack De
   1.720 +   Winter were active participants in this discussion or made
   1.721 +   suggestions to this document.
   1.722 +
   1.723 +
   1.724 +
   1.725 +
   1.726 +
   1.727 +
   1.728 +
   1.729 +
   1.730 +
   1.731 +
   1.732 +
   1.733 +Gahrns                       Informational                     [Page 13]
   1.734 +
   1.735 +RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997
   1.736 +
   1.737 +
   1.738 +8. Author's Address
   1.739 +
   1.740 +   Mike Gahrns
   1.741 +   Microsoft
   1.742 +   One Microsoft Way
   1.743 +   Redmond, WA, 98072
   1.744 +
   1.745 +   Phone: (206) 936-9833
   1.746 +   EMail: mikega@microsoft.com
   1.747 +
   1.748 +
   1.749 +
   1.750 +
   1.751 +
   1.752 +
   1.753 +
   1.754 +
   1.755 +
   1.756 +
   1.757 +
   1.758 +
   1.759 +
   1.760 +
   1.761 +
   1.762 +
   1.763 +
   1.764 +
   1.765 +
   1.766 +
   1.767 +
   1.768 +
   1.769 +
   1.770 +
   1.771 +
   1.772 +
   1.773 +
   1.774 +
   1.775 +
   1.776 +
   1.777 +
   1.778 +
   1.779 +
   1.780 +
   1.781 +
   1.782 +
   1.783 +
   1.784 +
   1.785 +
   1.786 +
   1.787 +
   1.788 +
   1.789 +Gahrns                       Informational                     [Page 14]
   1.790 +