imapext-2007

annotate docs/rfc/rfc2180.txt @ 0:ada5e610ab86

find changesets by author, revision, files, or words in the commit message
imap-2007e
author yuuji@gentei.org
date Mon, 14 Sep 2009 15:17:45 +0900
parents
children
rev   line source
yuuji@0 1
yuuji@0 2
yuuji@0 3
yuuji@0 4
yuuji@0 5
yuuji@0 6
yuuji@0 7 Network Working Group M. Gahrns
yuuji@0 8 Request for Comments: 2180 Microsoft
yuuji@0 9 Category: Informational July 1997
yuuji@0 10
yuuji@0 11
yuuji@0 12 IMAP4 Multi-Accessed Mailbox Practice
yuuji@0 13
yuuji@0 14 Status of this Memo
yuuji@0 15
yuuji@0 16 This memo provides information for the Internet community. This memo
yuuji@0 17 does not specify an Internet standard of any kind. Distribution of
yuuji@0 18 this memo is unlimited.
yuuji@0 19
yuuji@0 20 1. Abstract
yuuji@0 21
yuuji@0 22 IMAP4[RFC-2060] is rich client/server protocol that allows a client
yuuji@0 23 to access and manipulate electronic mail messages on a server.
yuuji@0 24 Within the protocol framework, it is possible to have differing
yuuji@0 25 results for particular client/server interactions. If a protocol does
yuuji@0 26 not allow for this, it is often unduly restrictive.
yuuji@0 27
yuuji@0 28 For example, when multiple clients are accessing a mailbox and one
yuuji@0 29 attempts to delete the mailbox, an IMAP4 server may choose to
yuuji@0 30 implement a solution based upon server architectural constraints or
yuuji@0 31 individual preference.
yuuji@0 32
yuuji@0 33 With this flexibility comes greater client responsibility. It is not
yuuji@0 34 sufficient for a client to be written based upon the behavior of a
yuuji@0 35 particular IMAP server. Rather the client must be based upon the
yuuji@0 36 behavior allowed by the protocol.
yuuji@0 37
yuuji@0 38 By documenting common IMAP4 server practice for the case of
yuuji@0 39 simultaneous client access to a mailbox, we hope to ensure the widest
yuuji@0 40 amount of inter-operation between IMAP4 clients and servers.
yuuji@0 41
yuuji@0 42 The behavior described in this document reflects the practice of some
yuuji@0 43 existing servers or behavior that the consensus of the IMAP mailing
yuuji@0 44 list has deemed to be reasonable. The behavior described within this
yuuji@0 45 document is believed to be [RFC-2060] compliant. However, this
yuuji@0 46 document is not meant to define IMAP4 compliance, nor is it an
yuuji@0 47 exhaustive list of valid IMAP4 behavior. [RFC-2060] must always be
yuuji@0 48 consulted to determine IMAP4 compliance, especially for server
yuuji@0 49 behavior not described within this document.
yuuji@0 50
yuuji@0 51
yuuji@0 52
yuuji@0 53
yuuji@0 54
yuuji@0 55
yuuji@0 56
yuuji@0 57
yuuji@0 58 Gahrns Informational [Page 1]
yuuji@0 59
yuuji@0 60 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
yuuji@0 61
yuuji@0 62
yuuji@0 63 2. Conventions used in this document
yuuji@0 64
yuuji@0 65 In examples,"C1:", "C2:" and "C3:" indicate lines sent by 3 different
yuuji@0 66 clients (client #1, client #2 and client #3) that are connected to a
yuuji@0 67 server. "S1:", "S2:" and "S3:" indicated lines sent by the server to
yuuji@0 68 client #1, client #2 and client #3 respectively.
yuuji@0 69
yuuji@0 70 A shared mailbox, is a mailbox that can be used by multiple users.
yuuji@0 71
yuuji@0 72 A multi-accessed mailbox, is a mailbox that has multiple clients
yuuji@0 73 simultaneously accessing it.
yuuji@0 74
yuuji@0 75 A client is said to have accessed a mailbox after a successful SELECT
yuuji@0 76 or EXAMINE command.
yuuji@0 77
yuuji@0 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
yuuji@0 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
yuuji@0 80 document are to be interpreted as described in [RFC-2119].
yuuji@0 81
yuuji@0 82
yuuji@0 83 3. Deletion/Renaming of a multi-accessed mailbox
yuuji@0 84
yuuji@0 85 If an external agent or multiple clients are accessing a mailbox,
yuuji@0 86 care must be taken when handling the deletion or renaming of the
yuuji@0 87 mailbox. Following are some strategies an IMAP server may choose to
yuuji@0 88 use when dealing with this situation.
yuuji@0 89
yuuji@0 90
yuuji@0 91 3.1. The server MAY fail the DELETE/RENAME command of a multi-accessed
yuuji@0 92 mailbox
yuuji@0 93
yuuji@0 94 In some cases, this behavior may not be practical. For example, if a
yuuji@0 95 large number of clients are accessing a shared mailbox, the window in
yuuji@0 96 which no clients have the mailbox accessed may be small or non-
yuuji@0 97 existent, effectively rendering the mailbox undeletable or
yuuji@0 98 unrenamable.
yuuji@0 99
yuuji@0 100 Example:
yuuji@0 101
yuuji@0 102 <Client #1 and Client #2 have mailbox FOO accessed. Client #1 tries
yuuji@0 103 to DELETE the mailbox and is refused>
yuuji@0 104
yuuji@0 105 C1: A001 DELETE FOO
yuuji@0 106 S1: A001 NO Mailbox FOO is in use by another user.
yuuji@0 107
yuuji@0 108
yuuji@0 109
yuuji@0 110
yuuji@0 111
yuuji@0 112
yuuji@0 113
yuuji@0 114 Gahrns Informational [Page 2]
yuuji@0 115
yuuji@0 116 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
yuuji@0 117
yuuji@0 118
yuuji@0 119 3.2. The server MAY allow the DELETE command of a multi-accessed
yuuji@0 120 mailbox, but keep the information in the mailbox available for
yuuji@0 121 those clients that currently have access to the mailbox.
yuuji@0 122
yuuji@0 123 When all clients have finished accessing the mailbox, it is
yuuji@0 124 permanently removed. For clients that do not already have access to
yuuji@0 125 the mailbox, the 'ghosted' mailbox would not be available. For
yuuji@0 126 example, it would not be returned to these clients in a subsequent
yuuji@0 127 LIST or LSUB command and would not be a valid mailbox argument to any
yuuji@0 128 other IMAP command until the reference count of clients accessing the
yuuji@0 129 mailbox reached 0.
yuuji@0 130
yuuji@0 131 In some cases, this behavior may not be desirable. For example if
yuuji@0 132 someone created a mailbox with offensive or sensitive information,
yuuji@0 133 one might prefer to have the mailbox deleted and all access to the
yuuji@0 134 information contained within removed immediately, rather than
yuuji@0 135 continuing to allow access until the client closes the mailbox.
yuuji@0 136
yuuji@0 137 Furthermore, this behavior, may prevent 'recycling' of the same
yuuji@0 138 mailbox name until all clients have finished accessing the original
yuuji@0 139 mailbox.
yuuji@0 140
yuuji@0 141 Example:
yuuji@0 142
yuuji@0 143 <Client #1 and Client #2 have mailbox FOO selected. Client #1 DELETEs
yuuji@0 144 mailbox FOO>
yuuji@0 145
yuuji@0 146 C1: A001 DELETE FOO
yuuji@0 147 S1: A001 OK Mailbox FOO is deleted.
yuuji@0 148
yuuji@0 149 <Client #2 is still able to operate on the deleted mailbox>
yuuji@0 150
yuuji@0 151 C2: B001 STORE 1 +FLAGS (\Seen)
yuuji@0 152 S2: * 1 FETCH FLAGS (\Seen)
yuuji@0 153 S2: B001 OK STORE completed
yuuji@0 154
yuuji@0 155 <Client #3 which did not have access to the mailbox prior to the
yuuji@0 156 deletion by client #1 does not have access to the mailbox>
yuuji@0 157
yuuji@0 158 C3: C001 STATUS FOO (MESSAGES)
yuuji@0 159 S3: C001 NO Mailbox does not exist
yuuji@0 160
yuuji@0 161 <Nor is client #3 able to create a mailbox with the name FOO, while
yuuji@0 162 the reference count is non zero>
yuuji@0 163
yuuji@0 164 C3: C002 CREATE FOO
yuuji@0 165 S3: C002 NO Mailbox FOO is still in use. Try again later.
yuuji@0 166
yuuji@0 167
yuuji@0 168
yuuji@0 169
yuuji@0 170 Gahrns Informational [Page 3]
yuuji@0 171
yuuji@0 172 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
yuuji@0 173
yuuji@0 174
yuuji@0 175 <Client #2 closes its access to the mailbox, no other clients have
yuuji@0 176 access to the mailbox FOO and reference count becomes 0>
yuuji@0 177
yuuji@0 178 C2: B002 CLOSE
yuuji@0 179 S2: B002 OK CLOSE Completed
yuuji@0 180
yuuji@0 181 <Now that the reference count on FOO has reached 0, the mailbox name
yuuji@0 182 can be recycled>
yuuji@0 183
yuuji@0 184 C3: C003 CREATE FOO
yuuji@0 185 S3: C003 OK CREATE Completed
yuuji@0 186
yuuji@0 187
yuuji@0 188 3.3. The server MAY allow the DELETE/RENAME of a multi-accessed
yuuji@0 189 mailbox, but disconnect all other clients who have the mailbox
yuuji@0 190 accessed by sending a untagged BYE response.
yuuji@0 191
yuuji@0 192 A server may often choose to disconnect clients in the DELETE case,
yuuji@0 193 but may choose to implement a "friendlier" method for the RENAME
yuuji@0 194 case.
yuuji@0 195
yuuji@0 196 Example:
yuuji@0 197
yuuji@0 198 <Client #1 and Client #2 have mailbox FOO accessed. Client #1 DELETEs
yuuji@0 199 the mailbox FOO>
yuuji@0 200
yuuji@0 201 C1: A002 DELETE FOO
yuuji@0 202 S1: A002 OK DELETE completed.
yuuji@0 203
yuuji@0 204 <Server disconnects all other users of the mailbox>
yuuji@0 205 S2: * BYE Mailbox FOO has been deleted.
yuuji@0 206
yuuji@0 207
yuuji@0 208 3.4. The server MAY allow the RENAME of a multi-accessed mailbox by
yuuji@0 209 simply changing the name attribute on the mailbox.
yuuji@0 210
yuuji@0 211 Other clients that have access to the mailbox can continue issuing
yuuji@0 212 commands such as FETCH that do not reference the mailbox name.
yuuji@0 213 Clients would discover the renaming the next time they referred to
yuuji@0 214 the old mailbox name. Some servers MAY choose to include the
yuuji@0 215 [NEWNAME] response code in their tagged NO response to a command that
yuuji@0 216 contained the old mailbox name, as a hint to the client that the
yuuji@0 217 operation can succeed if the command is issued with the new mailbox
yuuji@0 218 name.
yuuji@0 219
yuuji@0 220
yuuji@0 221
yuuji@0 222
yuuji@0 223
yuuji@0 224
yuuji@0 225
yuuji@0 226 Gahrns Informational [Page 4]
yuuji@0 227
yuuji@0 228 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
yuuji@0 229
yuuji@0 230
yuuji@0 231 Example:
yuuji@0 232
yuuji@0 233 <Client #1 and Client #2 have mailbox FOO accessed. Client #1 RENAMEs
yuuji@0 234 the mailbox.>
yuuji@0 235
yuuji@0 236 C1: A001 RENAME FOO BAR
yuuji@0 237 S1: A001 OK RENAME completed.
yuuji@0 238
yuuji@0 239 <Client #2 is still able to do operations that do not reference the
yuuji@0 240 mailbox name>
yuuji@0 241
yuuji@0 242 C2: B001 FETCH 2:4 (FLAGS)
yuuji@0 243 S2: * 2 FETCH . . .
yuuji@0 244 S2: * 3 FETCH . . .
yuuji@0 245 S2: * 4 FETCH . . .
yuuji@0 246 S2: B001 OK FETCH completed
yuuji@0 247
yuuji@0 248 <Client #2 is not able to do operations that reference the mailbox
yuuji@0 249 name>
yuuji@0 250
yuuji@0 251 C2: B002 APPEND FOO {300} C2: Date: Mon, 7 Feb 1994
yuuji@0 252 21:52:25 0800 (PST) C2: . . . S2: B002 NO [NEWNAME FOO
yuuji@0 253 BAR] Mailbox has been renamed
yuuji@0 254
yuuji@0 255
yuuji@0 256 4. Expunging of messages on a multi-accessed mailbox
yuuji@0 257
yuuji@0 258 If an external agent or multiple clients are accessing a mailbox,
yuuji@0 259 care must be taken when handling the EXPUNGE of messages. Other
yuuji@0 260 clients accessing the mailbox may be in the midst of issuing a
yuuji@0 261 command that depends upon message sequence numbers. Because an
yuuji@0 262 EXPUNGE response can not be sent while responding to a FETCH, STORE
yuuji@0 263 or SEARCH command, it is not possible to immediately notify the
yuuji@0 264 client of the EXPUNGE. This can result in ambiguity if the client
yuuji@0 265 issues a FETCH, STORE or SEARCH operation on a message that has been
yuuji@0 266 EXPUNGED.
yuuji@0 267
yuuji@0 268
yuuji@0 269 4.1. Fetching of expunged messages
yuuji@0 270
yuuji@0 271 Following are some strategies an IMAP server may choose to use when
yuuji@0 272 dealing with a FETCH command on expunged messages.
yuuji@0 273
yuuji@0 274
yuuji@0 275
yuuji@0 276
yuuji@0 277
yuuji@0 278
yuuji@0 279
yuuji@0 280
yuuji@0 281
yuuji@0 282 Gahrns Informational [Page 5]
yuuji@0 283
yuuji@0 284 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
yuuji@0 285
yuuji@0 286
yuuji@0 287 Consider the following scenario:
yuuji@0 288
yuuji@0 289 - Client #1 and Client #2 have mailbox FOO selected.
yuuji@0 290 - There are 7 messages in the mailbox.
yuuji@0 291 - Messages 4:7 are marked for deletion.
yuuji@0 292 - Client #1 issues an EXPUNGE, to expunge messages 4:7
yuuji@0 293
yuuji@0 294
yuuji@0 295 4.1.1. The server MAY allow the EXPUNGE of a multi-accessed mailbox but
yuuji@0 296 keep the messages available to satisfy subsequent FETCH commands
yuuji@0 297 until it is able to send an EXPUNGE response to each client.
yuuji@0 298
yuuji@0 299 In some cases, the behavior of keeping "ghosted" messages may not be
yuuji@0 300 desirable. For example if a message contained offensive or sensitive
yuuji@0 301 information, one might prefer to instantaneously remove all access to
yuuji@0 302 the information, regardless of whether another client is in the midst
yuuji@0 303 of accessing it.
yuuji@0 304
yuuji@0 305 Example: (Building upon the scenario outlined in 4.1.)
yuuji@0 306
yuuji@0 307 <Client #2 is still able to access the expunged messages because the
yuuji@0 308 server has kept a 'ghosted' copy of the messages until it is able to
yuuji@0 309 notify client #2 of the EXPUNGE>
yuuji@0 310
yuuji@0 311 C2: B001 FETCH 4:7 RFC822
yuuji@0 312 S2: * 4 FETCH RFC822 . . . (RFC822 info returned)
yuuji@0 313 S2: * 5 FETCH RFC822 . . . (RFC822 info returned)
yuuji@0 314 S2: * 6 FETCH RFC822 . . . (RFC822 info returned)
yuuji@0 315 S2: * 7 FETCH RFC822 . . . (RFC822 info returned)
yuuji@0 316 S2: B001 OK FETCH Completed
yuuji@0 317
yuuji@0 318 <Client #2 issues a command where it can get notified of the EXPUNGE>
yuuji@0 319
yuuji@0 320 C2: B002 NOOP
yuuji@0 321 S2: * 4 EXPUNGE
yuuji@0 322 S2: * 4 EXPUNGE
yuuji@0 323 S2: * 4 EXPUNGE
yuuji@0 324 S2: * 4 EXPUNGE
yuuji@0 325 S2: * 3 EXISTS
yuuji@0 326 S2: B002 OK NOOP Complete
yuuji@0 327
yuuji@0 328 <Client #2 no longer has access to the expunged messages>
yuuji@0 329
yuuji@0 330 C2: B003 FETCH 4:7 RFC822
yuuji@0 331 S2: B003 NO Messages 4:7 are no longer available.
yuuji@0 332
yuuji@0 333
yuuji@0 334
yuuji@0 335
yuuji@0 336
yuuji@0 337
yuuji@0 338 Gahrns Informational [Page 6]
yuuji@0 339
yuuji@0 340 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
yuuji@0 341
yuuji@0 342
yuuji@0 343 4.1.2 The server MAY allow the EXPUNGE of a multi-accessed mailbox,
yuuji@0 344 and on subsequent FETCH commands return FETCH responses only for
yuuji@0 345 non-expunged messages and a tagged NO.
yuuji@0 346
yuuji@0 347 After receiving a tagged NO FETCH response, the client SHOULD issue a
yuuji@0 348 NOOP command so that it will be informed of any pending EXPUNGE
yuuji@0 349 responses. The client may then either reissue the failed FETCH
yuuji@0 350 command, or by examining the EXPUNGE response from the NOOP and the
yuuji@0 351 FETCH response from the FETCH, determine that the FETCH failed
yuuji@0 352 because of pending expunges.
yuuji@0 353
yuuji@0 354 Example: (Building upon the scenario outlined in 4.1.)
yuuji@0 355
yuuji@0 356 <Client #2 attempts to FETCH a mix of expunged and non-expunged
yuuji@0 357 messages. A FETCH response is returned only for then non-expunged
yuuji@0 358 messages along with a tagged NO>
yuuji@0 359
yuuji@0 360 C2: B001 FETCH 3:5 ENVELOPE
yuuji@0 361 S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)
yuuji@0 362 S2: B001 NO Some of the requested messages no longer exist
yuuji@0 363
yuuji@0 364 <Upon receiving a tagged NO FETCH response, Client #2 issues a NOOP
yuuji@0 365 to be informed of any pending EXPUNGE responses>
yuuji@0 366
yuuji@0 367 C2: B002 NOOP
yuuji@0 368 S2: * 4 EXPUNGE
yuuji@0 369 S2: * 4 EXPUNGE
yuuji@0 370 S2: * 4 EXPUNGE
yuuji@0 371 S2: * 4 EXPUNGE
yuuji@0 372 S2: * 3 EXISTS
yuuji@0 373 S2: B002 OK NOOP Completed.
yuuji@0 374
yuuji@0 375 <By receiving a FETCH response for message 3, and an EXPUNGE response
yuuji@0 376 that indicates messages 4:7 have been expunged, the client does not
yuuji@0 377 need to re-issue the FETCH>
yuuji@0 378
yuuji@0 379
yuuji@0 380
yuuji@0 381
yuuji@0 382
yuuji@0 383
yuuji@0 384
yuuji@0 385
yuuji@0 386
yuuji@0 387
yuuji@0 388
yuuji@0 389
yuuji@0 390
yuuji@0 391
yuuji@0 392
yuuji@0 393
yuuji@0 394 Gahrns Informational [Page 7]
yuuji@0 395
yuuji@0 396 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
yuuji@0 397
yuuji@0 398
yuuji@0 399 4.1.3 The server MAY allow the EXPUNGE of a multi-accessed mailbox, and
yuuji@0 400 on subsequent FETCH commands return the usual FETCH responses for
yuuji@0 401 non-expunged messages, "NIL FETCH Responses" for expunged
yuuji@0 402 messages, and a tagged OK response.
yuuji@0 403
yuuji@0 404 If all of the messages in the subsequent FETCH command have been
yuuji@0 405 expunged, the server SHOULD return only a tagged NO. In this case,
yuuji@0 406 the client SHOULD issue a NOOP command so that it will be informed of
yuuji@0 407 any pending EXPUNGE responses. The client may then either reissue
yuuji@0 408 the failed FETCH command, or by examining the EXPUNGE response from
yuuji@0 409 the NOOP, determine that the FETCH failed because of pending
yuuji@0 410 expunges.
yuuji@0 411
yuuji@0 412 "NIL FETCH responses" are a representation of empty data as
yuuji@0 413 appropriate for the FETCH argument specified.
yuuji@0 414
yuuji@0 415 Example:
yuuji@0 416
yuuji@0 417 * 1 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL))
yuuji@0 418 * 1 FETCH (FLAGS ())
yuuji@0 419 * 1 FETCH (INTERNALDATE "00-Jan-0000 00:00:00 +0000")
yuuji@0 420 * 1 FETCH (RFC822 "")
yuuji@0 421 * 1 FETCH (RFC822.HEADER "")
yuuji@0 422 * 1 FETCH (RFC822.TEXT "")
yuuji@0 423 * 1 FETCH (RFC822.SIZE 0)
yuuji@0 424 * 1 FETCH (BODY ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
yuuji@0 425 * 1 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
yuuji@0 426 * 1 FETCH (BODY[<section>] "")
yuuji@0 427 * 1 FETCH (BODY[<section>]<partial> "")
yuuji@0 428
yuuji@0 429 In some cases, a client may not be able to distinguish between "NIL
yuuji@0 430 FETCH responses" received because a message was expunged and those
yuuji@0 431 received because the data actually was NIL. For example, a * 5
yuuji@0 432 FETCH (FLAGS ()) response could be received if no flags were set on
yuuji@0 433 message 5, or because message 5 was expunged. In a case of potential
yuuji@0 434 ambiguity, the client SHOULD issue a command such as NOOP to force
yuuji@0 435 the sending of the EXPUNGE responses to resolve any ambiguity.
yuuji@0 436
yuuji@0 437 Example: (Building upon the scenario outlined in 4.1.)
yuuji@0 438
yuuji@0 439 <Client #2 attempts to access a mix of expunged and non-expunged
yuuji@0 440 messages. Normal data is returned for non-expunged message, "NIL
yuuji@0 441 FETCH responses" are returned for expunged messages>
yuuji@0 442
yuuji@0 443
yuuji@0 444
yuuji@0 445
yuuji@0 446
yuuji@0 447
yuuji@0 448
yuuji@0 449
yuuji@0 450 Gahrns Informational [Page 8]
yuuji@0 451
yuuji@0 452 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
yuuji@0 453
yuuji@0 454
yuuji@0 455 C2: B002 FETCH 3:5 ENVELOPE
yuuji@0 456 S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)
yuuji@0 457 S2: * 4 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL
yuuji@0 458 NIL NIL)
yuuji@0 459 S2: * 5 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL
yuuji@0 460 NIL NIL)
yuuji@0 461 S2: B002 OK FETCH Completed
yuuji@0 462
yuuji@0 463 <Client #2 attempts to FETCH only expunged messages and receives a
yuuji@0 464 tagged NO response>
yuuji@0 465
yuuji@0 466 C2: B002 FETCH 4:7 ENVELOPE
yuuji@0 467 S2: B002 NO Messages 4:7 have been expunged.
yuuji@0 468
yuuji@0 469
yuuji@0 470 4.1.4 To avoid the situation altogether, the server MAY fail the
yuuji@0 471 EXPUNGE of a multi-accessed mailbox
yuuji@0 472
yuuji@0 473 In some cases, this behavior may not be practical. For example, if a
yuuji@0 474 large number of clients are accessing a shared mailbox, the window in
yuuji@0 475 which no clients have the mailbox accessed may be small or non-
yuuji@0 476 existent, effectively rendering the message unexpungeable.
yuuji@0 477
yuuji@0 478
yuuji@0 479 4.2. Storing of expunged messages
yuuji@0 480
yuuji@0 481 Following are some strategies an IMAP server may choose to use when
yuuji@0 482 dealing with a STORE command on expunged messages.
yuuji@0 483
yuuji@0 484
yuuji@0 485 4.2.1 If the ".SILENT" suffix is used, and the STORE completed
yuuji@0 486 successfully for all the non-expunged messages, the server SHOULD
yuuji@0 487 return a tagged OK.
yuuji@0 488
yuuji@0 489 Example: (Building upon the scenario outlined in 4.1.)
yuuji@0 490
yuuji@0 491 <Client #2 tries to silently STORE flags on expunged and non-
yuuji@0 492 expunged messages. The server sets the flags on the non-expunged
yuuji@0 493 messages and returns OK>
yuuji@0 494
yuuji@0 495 C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN)
yuuji@0 496 S2: B001 OK
yuuji@0 497
yuuji@0 498
yuuji@0 499
yuuji@0 500
yuuji@0 501
yuuji@0 502
yuuji@0 503
yuuji@0 504
yuuji@0 505
yuuji@0 506 Gahrns Informational [Page 9]
yuuji@0 507
yuuji@0 508 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
yuuji@0 509
yuuji@0 510
yuuji@0 511 4.2.2. If the ".SILENT" suffix is not used, and only expunged messages
yuuji@0 512 are referenced, the server SHOULD return only a tagged NO.
yuuji@0 513
yuuji@0 514 Example: (Building upon the scenario outlined in 4.1.)
yuuji@0 515
yuuji@0 516 <Client #2 tries to STORE flags only on expunged messages>
yuuji@0 517
yuuji@0 518 C2: B001 STORE 5:7 +FLAGS (\SEEN)
yuuji@0 519 S2: B001 NO Messages have been expunged
yuuji@0 520
yuuji@0 521
yuuji@0 522 4.2.3. If the ".SILENT" suffix is not used, and a mixture of expunged
yuuji@0 523 and non-expunged messages are referenced, the server MAY set the
yuuji@0 524 flags and return a FETCH response for the non-expunged messages
yuuji@0 525 along with a tagged NO.
yuuji@0 526
yuuji@0 527 After receiving a tagged NO STORE response, the client SHOULD issue a
yuuji@0 528 NOOP command so that it will be informed of any pending EXPUNGE
yuuji@0 529 responses. The client may then either reissue the failed STORE
yuuji@0 530 command, or by examining the EXPUNGE responses from the NOOP and
yuuji@0 531 FETCH responses from the STORE, determine that the STORE failed
yuuji@0 532 because of pending expunges.
yuuji@0 533
yuuji@0 534 Example: (Building upon the scenario outlined in 4.1.)
yuuji@0 535
yuuji@0 536 <Client #2 tries to STORE flags on a mixture of expunged and non-
yuuji@0 537 expunged messages>
yuuji@0 538
yuuji@0 539 C2: B001 STORE 1:7 +FLAGS (\SEEN)
yuuji@0 540 S2: * FETCH 1 FLAGS (\SEEN)
yuuji@0 541 S2: * FETCH 2 FLAGS (\SEEN)
yuuji@0 542 S2: * FETCH 3 FLAGS (\SEEN)
yuuji@0 543 S2: B001 NO Some of the messages no longer exist.
yuuji@0 544
yuuji@0 545 C2: B002 NOOP
yuuji@0 546 S2: * 4 EXPUNGE
yuuji@0 547 S2: * 4 EXPUNGE
yuuji@0 548 S2: * 4 EXPUNGE
yuuji@0 549 S2: * 4 EXPUNGE
yuuji@0 550 S2: * 3 EXISTS
yuuji@0 551 S2: B002 OK NOOP Completed.
yuuji@0 552
yuuji@0 553 <By receiving FETCH responses for messages 1:3, and an EXPUNGE
yuuji@0 554 response that indicates messages 4:7 have been expunged, the client
yuuji@0 555 does not need to re-issue the STORE>
yuuji@0 556
yuuji@0 557
yuuji@0 558
yuuji@0 559
yuuji@0 560
yuuji@0 561
yuuji@0 562 Gahrns Informational [Page 10]
yuuji@0 563
yuuji@0 564 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
yuuji@0 565
yuuji@0 566
yuuji@0 567 4.2.4. If the ".SILENT" suffix is not used, and a mixture of expunged
yuuji@0 568 and non-expunged messages are referenced, the server MAY return
yuuji@0 569 an untagged NO and not set any flags.
yuuji@0 570
yuuji@0 571 After receiving a tagged NO STORE response, the client SHOULD issue a
yuuji@0 572 NOOP command so that it will be informed of any pending EXPUNGE
yuuji@0 573 responses. The client would then re-issue the STORE command after
yuuji@0 574 updating its message list per any EXPUNGE response.
yuuji@0 575
yuuji@0 576 If a large number of clients are accessing a shared mailbox, the
yuuji@0 577 window in which there are no pending expunges may be small or non-
yuuji@0 578 existent, effectively disallowing a client from setting the flags on
yuuji@0 579 all messages at once.
yuuji@0 580
yuuji@0 581 Example: (Building upon the scenario outlined in 4.1.)
yuuji@0 582
yuuji@0 583 <Client #2 tries to STORE flags on a mixture of expunged and non-
yuuji@0 584 expunged messages>
yuuji@0 585
yuuji@0 586 C2: B001 STORE 1:7 +FLAGS (\SEEN)
yuuji@0 587 S2: B001 NO Some of the messages no longer exist.
yuuji@0 588
yuuji@0 589 <Client #2 issues a NOOP to be informed of the EXPUNGED messages>
yuuji@0 590
yuuji@0 591 C2: B002 NOOP
yuuji@0 592 S2: * 4 EXPUNGE
yuuji@0 593 S2: * 4 EXPUNGE
yuuji@0 594 S2: * 4 EXPUNGE
yuuji@0 595 S2: * 4 EXPUNGE
yuuji@0 596 S2: * 3 EXISTS
yuuji@0 597 S2: B002 OK NOOP Completed.
yuuji@0 598
yuuji@0 599 <Client #2 updates its message list and re-issues the STORE on only
yuuji@0 600 those messages that have not been expunged>
yuuji@0 601
yuuji@0 602 C2: B003 STORE 1:3 +FLAGS (\SEEN) S2: * FETCH 1 FLAGS
yuuji@0 603 (\SEEN) S2: * FETCH 2 FLAGS (\SEEN) S2: * FETCH 3 FLAGS
yuuji@0 604 (\SEEN) S2: B003 OK STORE Completed
yuuji@0 605
yuuji@0 606
yuuji@0 607 4.3. Searching of expunged messages
yuuji@0 608
yuuji@0 609 A server MAY simply not return a search response for messages that
yuuji@0 610 have been expunged and it has not been able to inform the client
yuuji@0 611 about. If a client was expecting a particular message to be returned
yuuji@0 612 in a search result, and it was not, the client SHOULD issue a NOOP
yuuji@0 613 command to see if the message was expunged by another client.
yuuji@0 614
yuuji@0 615
yuuji@0 616
yuuji@0 617
yuuji@0 618 Gahrns Informational [Page 11]
yuuji@0 619
yuuji@0 620 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
yuuji@0 621
yuuji@0 622
yuuji@0 623 4.4 Copying of expunged messages
yuuji@0 624
yuuji@0 625 COPY is the only IMAP4 sequence number command that is safe to allow
yuuji@0 626 an EXPUNGE response on. This is because a client is not permitted to
yuuji@0 627 cascade several COPY commands together. A client is required to wait
yuuji@0 628 and confirm that the copy worked before issuing another one.
yuuji@0 629
yuuji@0 630 4.4.1 The server MAY disallow the COPY of messages in a multi-access
yuuji@0 631 mailbox that contains expunged messages.
yuuji@0 632
yuuji@0 633 Pending EXPUNGE response(s) MUST be returned to the COPY command.
yuuji@0 634
yuuji@0 635 Example:
yuuji@0 636
yuuji@0 637 C: A001 COPY 2,4,6,8 FRED
yuuji@0 638 S: * 4 EXPUNGE
yuuji@0 639 S: A001 NO COPY rejected, because some of the requested
yuuji@0 640 messages were expunged
yuuji@0 641
yuuji@0 642 Note: Non of the above messages are copied because if a COPY command
yuuji@0 643 is unsuccessful, the server MUST restore the destination mailbox to
yuuji@0 644 its state before the COPY attempt.
yuuji@0 645
yuuji@0 646
yuuji@0 647 4.4.2 The server MAY allow the COPY of messages in a multi-access
yuuji@0 648 mailbox that contains expunged messages.
yuuji@0 649
yuuji@0 650 Pending EXPUNGE response(s) MUST be returned to the COPY command.
yuuji@0 651 Messages that are copied are messages corresponding to sequence
yuuji@0 652 numbers before any EXPUNGE response.
yuuji@0 653
yuuji@0 654 Example:
yuuji@0 655
yuuji@0 656 C: A001 COPY 2,4,6,8 FRED
yuuji@0 657 S: * 3 EXPUNGE
yuuji@0 658 S: A001 OK COPY completed
yuuji@0 659
yuuji@0 660 In the above example, the messages that are copied to FRED are
yuuji@0 661 messages 2,4,6,8 at the start of the COPY command. These are
yuuji@0 662 equivalent to messages 2,3,5,7 at the end of the COPY command. The
yuuji@0 663 EXPUNGE response can't take place until after the messages from the
yuuji@0 664 COPY command are identified (because of the "no expunge while no
yuuji@0 665 commands in progress" rule).
yuuji@0 666
yuuji@0 667
yuuji@0 668
yuuji@0 669
yuuji@0 670
yuuji@0 671
yuuji@0 672
yuuji@0 673
yuuji@0 674 Gahrns Informational [Page 12]
yuuji@0 675
yuuji@0 676 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
yuuji@0 677
yuuji@0 678
yuuji@0 679 Example:
yuuji@0 680
yuuji@0 681 C: A001 COPY 2,4,6,8 FRED
yuuji@0 682 S: * 4 EXPUNGE
yuuji@0 683 S: A001 OK COPY completed
yuuji@0 684
yuuji@0 685 In the above example, message 4 was copied before it was expunged,
yuuji@0 686 and MUST appear in the destination mailbox FRED.
yuuji@0 687
yuuji@0 688
yuuji@0 689 5. Security Considerations
yuuji@0 690
yuuji@0 691 This document describes behavior of servers that use the IMAP4
yuuji@0 692 protocol, and as such, has the same security considerations as
yuuji@0 693 described in [RFC-2060].
yuuji@0 694
yuuji@0 695 In particular, some described server behavior does not allow for the
yuuji@0 696 immediate deletion of information when a mailbox is accessed by
yuuji@0 697 multiple clients. This may be a consideration when dealing with
yuuji@0 698 sensitive information where immediate deletion would be preferred.
yuuji@0 699
yuuji@0 700
yuuji@0 701 6. References
yuuji@0 702
yuuji@0 703 [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
yuuji@0 704 4rev1", RFC 2060, University of Washington, December 1996.
yuuji@0 705
yuuji@0 706 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
yuuji@0 707 Requirement Levels", RFC 2119, Harvard University, March 1997.
yuuji@0 708
yuuji@0 709
yuuji@0 710 7. Acknowledgments
yuuji@0 711
yuuji@0 712 This document is the result of discussions on the IMAP4 mailing list
yuuji@0 713 and is meant to reflect consensus of this group. In particular,
yuuji@0 714 Raymond Cheng, Mark Crispin, Jim Evans, Erik Forsberg, Steve Hole,
yuuji@0 715 Mark Keasling, Barry Leiba, Syd Logan, John Mani, Pat Moran, Larry
yuuji@0 716 Osterman, Chris Newman, Bart Schaefer, Vladimir Vulovic, and Jack De
yuuji@0 717 Winter were active participants in this discussion or made
yuuji@0 718 suggestions to this document.
yuuji@0 719
yuuji@0 720
yuuji@0 721
yuuji@0 722
yuuji@0 723
yuuji@0 724
yuuji@0 725
yuuji@0 726
yuuji@0 727
yuuji@0 728
yuuji@0 729
yuuji@0 730 Gahrns Informational [Page 13]
yuuji@0 731
yuuji@0 732 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
yuuji@0 733
yuuji@0 734
yuuji@0 735 8. Author's Address
yuuji@0 736
yuuji@0 737 Mike Gahrns
yuuji@0 738 Microsoft
yuuji@0 739 One Microsoft Way
yuuji@0 740 Redmond, WA, 98072
yuuji@0 741
yuuji@0 742 Phone: (206) 936-9833
yuuji@0 743 EMail: mikega@microsoft.com
yuuji@0 744
yuuji@0 745
yuuji@0 746
yuuji@0 747
yuuji@0 748
yuuji@0 749
yuuji@0 750
yuuji@0 751
yuuji@0 752
yuuji@0 753
yuuji@0 754
yuuji@0 755
yuuji@0 756
yuuji@0 757
yuuji@0 758
yuuji@0 759
yuuji@0 760
yuuji@0 761
yuuji@0 762
yuuji@0 763
yuuji@0 764
yuuji@0 765
yuuji@0 766
yuuji@0 767
yuuji@0 768
yuuji@0 769
yuuji@0 770
yuuji@0 771
yuuji@0 772
yuuji@0 773
yuuji@0 774
yuuji@0 775
yuuji@0 776
yuuji@0 777
yuuji@0 778
yuuji@0 779
yuuji@0 780
yuuji@0 781
yuuji@0 782
yuuji@0 783
yuuji@0 784
yuuji@0 785
yuuji@0 786 Gahrns Informational [Page 14]
yuuji@0 787

UW-IMAP'd extensions by yuuji