imapext-2007

annotate docs/rfc/rfc5162.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 A. Melnikov
yuuji@0 8 Request for Comments: 5162 D. Cridland
yuuji@0 9 Category: Standards Track Isode Ltd
yuuji@0 10 C. Wilson
yuuji@0 11 Nokia
yuuji@0 12 March 2008
yuuji@0 13
yuuji@0 14
yuuji@0 15 IMAP4 Extensions for Quick Mailbox Resynchronization
yuuji@0 16
yuuji@0 17 Status of This Memo
yuuji@0 18
yuuji@0 19 This document specifies an Internet standards track protocol for the
yuuji@0 20 Internet community, and requests discussion and suggestions for
yuuji@0 21 improvements. Please refer to the current edition of the "Internet
yuuji@0 22 Official Protocol Standards" (STD 1) for the standardization state
yuuji@0 23 and status of this protocol. Distribution of this memo is unlimited.
yuuji@0 24
yuuji@0 25 Abstract
yuuji@0 26
yuuji@0 27 This document defines an IMAP4 extension, which gives an IMAP client
yuuji@0 28 the ability to quickly resynchronize any previously opened mailbox as
yuuji@0 29 part of the SELECT command, without the need for server-side state or
yuuji@0 30 additional client round-trips. This extension also introduces a new
yuuji@0 31 response that allows for a more compact representation of a list of
yuuji@0 32 expunged messages (and always includes the Unique Identifiers (UIDs)
yuuji@0 33 expunged).
yuuji@0 34
yuuji@0 35
yuuji@0 36
yuuji@0 37
yuuji@0 38
yuuji@0 39
yuuji@0 40
yuuji@0 41
yuuji@0 42
yuuji@0 43
yuuji@0 44
yuuji@0 45
yuuji@0 46
yuuji@0 47
yuuji@0 48
yuuji@0 49
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 Melnikov, et al. Standards Track [Page 1]
yuuji@0 59
yuuji@0 60 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 61
yuuji@0 62
yuuji@0 63 Table of Contents
yuuji@0 64
yuuji@0 65 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
yuuji@0 66 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
yuuji@0 67 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 4
yuuji@0 68 3.1. QRESYNC Parameter to SELECT/EXAMINE . . . . . . . . . . . 4
yuuji@0 69 3.2. VANISHED UID FETCH Modifier . . . . . . . . . . . . . . . 8
yuuji@0 70 3.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . . . 10
yuuji@0 71 3.4. CLOSE Command . . . . . . . . . . . . . . . . . . . . . . 11
yuuji@0 72 3.5. UID EXPUNGE Command . . . . . . . . . . . . . . . . . . . 11
yuuji@0 73 3.6. VANISHED Response . . . . . . . . . . . . . . . . . . . . 12
yuuji@0 74 3.7. CLOSED Response Code . . . . . . . . . . . . . . . . . . . 15
yuuji@0 75 4. Server Implementation Considerations . . . . . . . . . . . . . 15
yuuji@0 76 4.1. Server Implementations That Don't Store Extra State . . . 15
yuuji@0 77 4.2. Server Implementations Storing Minimal State . . . . . . . 16
yuuji@0 78 4.3. Additional State Required on the Server . . . . . . . . . 16
yuuji@0 79 5. Updated Synchronization Sequence . . . . . . . . . . . . . . . 17
yuuji@0 80 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19
yuuji@0 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
yuuji@0 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
yuuji@0 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
yuuji@0 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
yuuji@0 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
yuuji@0 86 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
yuuji@0 87
yuuji@0 88 1. Introduction and Overview
yuuji@0 89
yuuji@0 90 The [CONDSTORE] extension gives a disconnected client the ability to
yuuji@0 91 quickly resynchronize IMAP flag changes for previously seen messages.
yuuji@0 92 This can be done using the CHANGEDSINCE FETCH modifier once a mailbox
yuuji@0 93 is opened. In order for the client to discover which messages have
yuuji@0 94 been expunged, the client still has to issue a UID FETCH or a UID
yuuji@0 95 SEARCH command. This document defines an extension to [CONDSTORE]
yuuji@0 96 that allows a reconnecting client to perform full resynchronization,
yuuji@0 97 including discovery of expunged messages, in a single round-trip.
yuuji@0 98 This extension also introduces a new response, VANISHED, that allows
yuuji@0 99 for a more compact representation of a list of expunged messages.
yuuji@0 100
yuuji@0 101 This extension can be useful for mobile clients that can experience
yuuji@0 102 frequent disconnects caused by environmental factors (battery life,
yuuji@0 103 signal strength, etc.). Such clients need a way to quickly reconnect
yuuji@0 104 to the IMAP server, while minimizing delay experienced by the user as
yuuji@0 105 well as the amount of traffic (and hence the expense) generated by
yuuji@0 106 resynchronization.
yuuji@0 107
yuuji@0 108
yuuji@0 109
yuuji@0 110
yuuji@0 111
yuuji@0 112
yuuji@0 113
yuuji@0 114 Melnikov, et al. Standards Track [Page 2]
yuuji@0 115
yuuji@0 116 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 117
yuuji@0 118
yuuji@0 119 By extending the SELECT command to perform the additional
yuuji@0 120 resynchronization, this also allows clients to reduce concurrent
yuuji@0 121 connections to the IMAP server held purely for the sake of avoiding
yuuji@0 122 the resynchronization.
yuuji@0 123
yuuji@0 124 The quick resync IMAP extension is present if an IMAP4 server returns
yuuji@0 125 "QRESYNC" as one of the supported capabilities to the CAPABILITY
yuuji@0 126 command.
yuuji@0 127
yuuji@0 128 Servers supporting this extension MUST implement and advertise
yuuji@0 129 support for the [ENABLE] IMAP extension. Also, the presence of the
yuuji@0 130 "QRESYNC" capability implies support for the [CONDSTORE] IMAP
yuuji@0 131 extension even if the CONDSTORE capability isn't advertised. A
yuuji@0 132 server compliant with this specification is REQUIREd to support
yuuji@0 133 "ENABLE QRESYNC" and "ENABLE QRESYNC CONDSTORE" (which are "CONDSTORE
yuuji@0 134 enabling commands", as defined in [CONDSTORE], and have identical
yuuji@0 135 results), but there is no requirement for a compliant server to
yuuji@0 136 support "ENABLE CONDSTORE" by itself. The "ENABLE QRESYNC"/"ENABLE
yuuji@0 137 QRESYNC CONDSTORE" command also tells the server that it SHOULD start
yuuji@0 138 sending VANISHED responses (see Section 3.6) instead of EXPUNGE
yuuji@0 139 responses. This change remains in effect until the connection is
yuuji@0 140 closed.
yuuji@0 141
yuuji@0 142 For compatibility with clients that only support the [CONDSTORE] IMAP
yuuji@0 143 extension, servers SHOULD advertise CONDSTORE in the CAPABILITY
yuuji@0 144 response as well.
yuuji@0 145
yuuji@0 146 A client making use of this extension MUST issue "ENABLE QRESYNC"
yuuji@0 147 once it is authenticated. A server MUST respond with a tagged BAD
yuuji@0 148 response if the QRESYNC parameter to the SELECT/EXAMINE command or
yuuji@0 149 the VANISHED UID FETCH modifier is specified and the client hasn't
yuuji@0 150 issued "ENABLE QRESYNC" in the current connection.
yuuji@0 151
yuuji@0 152 This document puts additional requirements on a server implementing
yuuji@0 153 the [CONDSTORE] extension. Each mailbox that supports persistent
yuuji@0 154 storage of mod-sequences, i.e., for which the server has sent a
yuuji@0 155 HIGHESTMODSEQ untagged OK response code on a successful SELECT/
yuuji@0 156 EXAMINE, MUST increment the per-mailbox mod-sequence when one or more
yuuji@0 157 messages are expunged due to EXPUNGE, UID EXPUNGE or CLOSE; the
yuuji@0 158 server MUST associate the incremented mod-sequence with the UIDs of
yuuji@0 159 the expunged messages.
yuuji@0 160
yuuji@0 161 A client that supports CONDSTORE but not this extension might
yuuji@0 162 resynchronize a mailbox and discover that its HIGHESTMODSEQ has
yuuji@0 163 increased from the value cached by the client. If the increase is
yuuji@0 164 only due to messages having been expunged since the client last
yuuji@0 165 synchronized, the client is likely to send a FETCH ... CHANGEDSINCE
yuuji@0 166 command that returns no data. Thus, a client that supports CONDSTORE
yuuji@0 167
yuuji@0 168
yuuji@0 169
yuuji@0 170 Melnikov, et al. Standards Track [Page 3]
yuuji@0 171
yuuji@0 172 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 173
yuuji@0 174
yuuji@0 175 but not this extension might incur a penalty of an unneeded round-
yuuji@0 176 trip when resynchronizing some mailboxes (those that have had
yuuji@0 177 messages expunged but no flag changes since the last
yuuji@0 178 synchronization).
yuuji@0 179
yuuji@0 180 This extra round-trip is only incurred by clients that support
yuuji@0 181 CONDSTORE but not this extension, and only when a mailbox has had
yuuji@0 182 messages expunged but no flag changes to non-expunged messages.
yuuji@0 183 Since CONDSTORE is a relatively new extension, it is thought likely
yuuji@0 184 that clients that support it will also support this extension.
yuuji@0 185
yuuji@0 186 2. Requirements Notation
yuuji@0 187
yuuji@0 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
yuuji@0 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
yuuji@0 190 document are to be interpreted as described in [RFC2119].
yuuji@0 191
yuuji@0 192 In examples, "C:" and "S:" indicate lines sent by the client and
yuuji@0 193 server respectively. If a single "C:" or "S:" label applies to
yuuji@0 194 multiple lines, then the line breaks between those lines are for
yuuji@0 195 editorial clarity only and are not part of the actual protocol
yuuji@0 196 exchange. The five characters [...] means that something has been
yuuji@0 197 elided.
yuuji@0 198
yuuji@0 199 Understanding of the IMAP message sequence numbers and UIDs and the
yuuji@0 200 EXPUNGE response [RFC3501] is essential when reading this document.
yuuji@0 201
yuuji@0 202 3. IMAP Protocol Changes
yuuji@0 203
yuuji@0 204 3.1. QRESYNC Parameter to SELECT/EXAMINE
yuuji@0 205
yuuji@0 206 The Quick Resynchronization parameter to SELECT/EXAMINE commands has
yuuji@0 207 four arguments:
yuuji@0 208
yuuji@0 209 o the last known UIDVALIDITY,
yuuji@0 210
yuuji@0 211 o the last known modification sequence,
yuuji@0 212
yuuji@0 213 o the optional set of known UIDs, and
yuuji@0 214
yuuji@0 215 o an optional parenthesized list of known sequence ranges and their
yuuji@0 216 corresponding UIDs.
yuuji@0 217
yuuji@0 218 A server MUST respond with a tagged BAD response if the Quick
yuuji@0 219 Resynchronization parameter to SELECT/EXAMINE command is specified
yuuji@0 220 and the client hasn't issued "ENABLE QRESYNC" in the current
yuuji@0 221 connection.
yuuji@0 222
yuuji@0 223
yuuji@0 224
yuuji@0 225
yuuji@0 226 Melnikov, et al. Standards Track [Page 4]
yuuji@0 227
yuuji@0 228 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 229
yuuji@0 230
yuuji@0 231 Before opening the specified mailbox, the server verifies all
yuuji@0 232 arguments for syntactic validity. If any parameter is not
yuuji@0 233 syntactically valid, the server returns the tagged BAD response, and
yuuji@0 234 the mailbox remains unselected. Once the check is done, the server
yuuji@0 235 opens the mailbox as if no SELECT/EXAMINE parameters are specified
yuuji@0 236 (this is subject to processing of other parameters as defined in
yuuji@0 237 other extensions). In particular this means that the server MUST
yuuji@0 238 send all untagged responses as specified in Sections 6.3.1 and 6.3.2
yuuji@0 239 of [RFC3501].
yuuji@0 240
yuuji@0 241 After that, the server checks the UIDVALIDITY value provided by the
yuuji@0 242 client. If the provided UIDVALIDITY doesn't match the UIDVALIDITY
yuuji@0 243 for the mailbox being opened, then the server MUST ignore the
yuuji@0 244 remaining parameters and behave as if no dynamic message data
yuuji@0 245 changed. The client can discover this situation by comparing the
yuuji@0 246 UIDVALIDITY value returned by the server. This behavior allows the
yuuji@0 247 client not to synchronize the mailbox or decide on the best
yuuji@0 248 synchronization strategy.
yuuji@0 249
yuuji@0 250 Example: Attempting to resynchronize INBOX, but the provided
yuuji@0 251 UIDVALIDITY parameter doesn't match the current UIDVALIDITY
yuuji@0 252 value.
yuuji@0 253
yuuji@0 254 C: A02 SELECT INBOX (QRESYNC (67890007 20050715194045000
yuuji@0 255 41,43:211,214:541))
yuuji@0 256 S: * 464 EXISTS
yuuji@0 257 S: * 3 RECENT
yuuji@0 258 S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY
yuuji@0 259 S: * OK [UIDNEXT 550] Predicted next UID
yuuji@0 260 S: * OK [HIGHESTMODSEQ 90060128194045007]
yuuji@0 261 S: * OK [UNSEEN 12] Message 12 is first unseen
yuuji@0 262 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
yuuji@0 263 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
yuuji@0 264 \Deleted \Seen \*)] Permanent flags
yuuji@0 265 S: A02 OK [READ-WRITE] Sorry, UIDVALIDITY mismatch
yuuji@0 266
yuuji@0 267 Modification Sequence and UID Parameters:
yuuji@0 268
yuuji@0 269 A server that doesn't support the persistent storage of mod-sequences
yuuji@0 270 for the mailbox MUST send the OK untagged response including the
yuuji@0 271 NOMODSEQ response code with every successful SELECT or EXAMINE
yuuji@0 272 command, as described in [CONDSTORE]. Such a server doesn't need to
yuuji@0 273 remember mod-sequences for expunged messages in the mailbox. It MUST
yuuji@0 274 ignore the remaining parameters and behave as if no dynamic message
yuuji@0 275 data changed.
yuuji@0 276
yuuji@0 277 If the provided UIDVALIDITY matches that of the selected mailbox, the
yuuji@0 278 server then checks the last known modification sequence.
yuuji@0 279
yuuji@0 280
yuuji@0 281
yuuji@0 282 Melnikov, et al. Standards Track [Page 5]
yuuji@0 283
yuuji@0 284 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 285
yuuji@0 286
yuuji@0 287 The server sends the client any pending flag changes (using FETCH
yuuji@0 288 responses that MUST contain UIDs) and expunges those that have
yuuji@0 289 occurred in this mailbox since the provided modification sequence.
yuuji@0 290
yuuji@0 291 If the list of known UIDs was also provided, the server should only
yuuji@0 292 report flag changes and expunges for the specified messages. If the
yuuji@0 293 client did not provide the list of UIDs, the server acts as if the
yuuji@0 294 client has specified "1:<maxuid>", where <maxuid> is the mailbox's
yuuji@0 295 UIDNEXT value minus 1. If the mailbox is empty and never had any
yuuji@0 296 messages in it, then lack of the list of UIDs is interpreted as an
yuuji@0 297 empty set of UIDs.
yuuji@0 298
yuuji@0 299 Thus, the client can process just these pending events and need not
yuuji@0 300 perform a full resynchronization. Without the message sequence
yuuji@0 301 number matching information, the result of this step is semantically
yuuji@0 302 equivalent to the client issuing:
yuuji@0 303 tag1 UID FETCH "known-uids" (FLAGS) (CHANGEDSINCE
yuuji@0 304 "mod-sequence-value" VANISHED)
yuuji@0 305
yuuji@0 306 Example:
yuuji@0 307 C: A03 SELECT INBOX (QRESYNC (67890007
yuuji@0 308 90060115194045000 41,43:211,214:541))
yuuji@0 309 S: * OK [CLOSED]
yuuji@0 310 S: * 314 EXISTS
yuuji@0 311 S: * 15 RECENT
yuuji@0 312 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
yuuji@0 313 S: * OK [UIDNEXT 567] Predicted next UID
yuuji@0 314 S: * OK [HIGHESTMODSEQ 90060115205545359]
yuuji@0 315 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
yuuji@0 316 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
yuuji@0 317 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
yuuji@0 318 \Deleted \Seen \*)] Permanent flags
yuuji@0 319 S: * VANISHED (EARLIER) 41,43:116,118,120:211,214:540
yuuji@0 320 S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered) MODSEQ
yuuji@0 321 (90060115194045001))
yuuji@0 322 S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent) MODSEQ
yuuji@0 323 (90060115194045308))
yuuji@0 324 S: ...
yuuji@0 325 S: * 100 FETCH (UID 541 FLAGS (\Seen $Forwarded) MODSEQ
yuuji@0 326 (90060115194045001))
yuuji@0 327 S: A03 OK [READ-WRITE] mailbox selected
yuuji@0 328
yuuji@0 329 Message sequence match data:
yuuji@0 330
yuuji@0 331 A client MAY provide a parenthesized list of a message sequence set
yuuji@0 332 and the corresponding UID sets. Both MUST be provided in ascending
yuuji@0 333 order. The server uses this data to restrict the range for which it
yuuji@0 334 provides expunged message information.
yuuji@0 335
yuuji@0 336
yuuji@0 337
yuuji@0 338 Melnikov, et al. Standards Track [Page 6]
yuuji@0 339
yuuji@0 340 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 341
yuuji@0 342
yuuji@0 343 Conceptually, the client provides a small sample of sequence numbers
yuuji@0 344 for which it knows the corresponding UIDs. The server then compares
yuuji@0 345 each sequence number and UID pair the client provides with the
yuuji@0 346 current state of the mailbox. If a pair matches, then the client
yuuji@0 347 knows of any expunges up to, and including, the message, and thus
yuuji@0 348 will not include that range in the VANISHED response, even if the
yuuji@0 349 "mod-sequence-value" provided by the client is too old for the server
yuuji@0 350 to have data of when those messages were expunged.
yuuji@0 351
yuuji@0 352 Thus, if the Nth message number in the first set in the list is 4,
yuuji@0 353 and the Nth UID in the second set in the list is 8, and the mailbox's
yuuji@0 354 fourth message has UID 8, then no UIDs equal to or less than 8 are
yuuji@0 355 present in the VANISHED response. If the (N+1)th message number is
yuuji@0 356 12, and the (N+1)th UID is 24, and the (N+1)th message in the mailbox
yuuji@0 357 has UID 25, then the lowest UID included in the VANISHED response
yuuji@0 358 would be 9.
yuuji@0 359
yuuji@0 360 In the following two examples, the server is unable to remember
yuuji@0 361 expunges at all, and only UIDs with messages divisible by three are
yuuji@0 362 present in the mailbox. In the first example, the client does not
yuuji@0 363 use the fourth parameter; in the second, it provides it. This
yuuji@0 364 example is somewhat extreme, but shows that judicious usage of the
yuuji@0 365 sequence match data can save a substantial amount of bandwidth.
yuuji@0 366
yuuji@0 367 Example:
yuuji@0 368 C: A04 SELECT INBOX (QRESYNC (67890007
yuuji@0 369 90060115194045000 1:29997))
yuuji@0 370 S: * 10003 EXISTS
yuuji@0 371 S: * 5 RECENT
yuuji@0 372 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
yuuji@0 373 S: * OK [UIDNEXT 30013] Predicted next UID
yuuji@0 374 S: * OK [HIGHESTMODSEQ 90060115205545359]
yuuji@0 375 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
yuuji@0 376 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
yuuji@0 377 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
yuuji@0 378 \Deleted \Seen \*)] Permanent flags
yuuji@0 379 S: * VANISHED (EARLIER) 1:2,4:5,7:8,10:11,13:14 [...]
yuuji@0 380 29998:29999,30001:30002,30004:30005,30007:30008
yuuji@0 381 S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ
yuuji@0 382 (90060115194045027))
yuuji@0 383 S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ
yuuji@0 384 (90060115194045028))
yuuji@0 385 S: ...
yuuji@0 386 S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ
yuuji@0 387 (90060115194045031))
yuuji@0 388 S: A04 OK [READ-WRITE] mailbox selected
yuuji@0 389
yuuji@0 390
yuuji@0 391
yuuji@0 392
yuuji@0 393
yuuji@0 394 Melnikov, et al. Standards Track [Page 7]
yuuji@0 395
yuuji@0 396 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 397
yuuji@0 398
yuuji@0 399 Example:
yuuji@0 400 C: B04 SELECT INBOX (QRESYNC (67890007
yuuji@0 401 90060115194045000 1:29997 (5000,7500,9000,9990:9999 15000,
yuuji@0 402 22500,27000,29970,29973,29976,29979,29982,29985,29988,29991,
yuuji@0 403 29994,29997)))
yuuji@0 404 S: * 10003 EXISTS
yuuji@0 405 S: * 5 RECENT
yuuji@0 406 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
yuuji@0 407 S: * OK [UIDNEXT 30013] Predicted next UID
yuuji@0 408 S: * OK [HIGHESTMODSEQ 90060115205545359]
yuuji@0 409 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
yuuji@0 410 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
yuuji@0 411 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
yuuji@0 412 \Deleted \Seen \*)] Permanent flags
yuuji@0 413 S: * VANISHED (EARLIER) 29998:29999,30001:30002,30004:30005,30007:
yuuji@0 414 30008
yuuji@0 415 S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ
yuuji@0 416 (90060115194045027))
yuuji@0 417 S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ
yuuji@0 418 (90060115194045028))
yuuji@0 419 S: ...
yuuji@0 420 S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ
yuuji@0 421 (90060115194045031))
yuuji@0 422 S: B04 OK [READ-WRITE] mailbox selected
yuuji@0 423
yuuji@0 424 3.2. VANISHED UID FETCH Modifier
yuuji@0 425
yuuji@0 426 [IMAPABNF] has extended the syntax of the FETCH and UID FETCH
yuuji@0 427 commands to include an optional FETCH modifier. This document
yuuji@0 428 defines a new UID FETCH modifier: VANISHED.
yuuji@0 429
yuuji@0 430 Note, that the VANISHED UID FETCH modifier is NOT allowed with a
yuuji@0 431 FETCH command. The server MUST return a tagged BAD response if this
yuuji@0 432 response is specified as a modifier to the FETCH command.
yuuji@0 433
yuuji@0 434 A server MUST respond with a tagged BAD response if the VANISHED UID
yuuji@0 435 FETCH modifier is specified and the client hasn't issued "ENABLE
yuuji@0 436 QRESYNC" in the current connection.
yuuji@0 437
yuuji@0 438 The VANISHED UID FETCH modifier MUST only be specified together with
yuuji@0 439 the CHANGEDSINCE UID FETCH modifier.
yuuji@0 440
yuuji@0 441 The VANISHED UID FETCH modifier instructs the server to report those
yuuji@0 442 messages from the UID set parameter that have been expunged and whose
yuuji@0 443 associated mod-sequence is larger than the specified mod-sequence.
yuuji@0 444 That is, the client requests to be informed of messages from the
yuuji@0 445 specified set that were expunged since the specified mod-sequence.
yuuji@0 446 Note that the mod-sequence(s) associated with these messages were
yuuji@0 447
yuuji@0 448
yuuji@0 449
yuuji@0 450 Melnikov, et al. Standards Track [Page 8]
yuuji@0 451
yuuji@0 452 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 453
yuuji@0 454
yuuji@0 455 updated when the messages were expunged (as described above). The
yuuji@0 456 expunged messages are reported using the VANISHED response as
yuuji@0 457 described in Section 3.6, which MUST contain the EARLIER tag. Any
yuuji@0 458 VANISHED (EARLIER) responses MUST be returned before any FETCH
yuuji@0 459 responses, as otherwise the client might get confused about how
yuuji@0 460 message numbers map to UIDs.
yuuji@0 461
yuuji@0 462 Note: A server that receives a mod-sequence smaller than <minmodseq>,
yuuji@0 463 where <minmodseq> is the value of the smallest expunged mod-sequence
yuuji@0 464 it remembers minus one, MUST behave as if it was requested to report
yuuji@0 465 all expunged messages from the provided UID set parameter.
yuuji@0 466
yuuji@0 467 Example 1: Without the VANISHED UID FETCH modifier, a CONDSTORE-aware
yuuji@0 468 client [CONDSTORE] needs to issue separate commands to learn of flag
yuuji@0 469 changes and expunged messages since the last synchronization:
yuuji@0 470
yuuji@0 471 C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345)
yuuji@0 472 S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen))
yuuji@0 473 S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted))
yuuji@0 474 S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk
yuuji@0 475 $AutoJunk $MDNSent))
yuuji@0 476 S: s100 OK FETCH completed
yuuji@0 477 C: s101 UID SEARCH 300:500
yuuji@0 478 S: * SEARCH 404 406 407 408 410 412
yuuji@0 479 S: s101 OK search completed
yuuji@0 480
yuuji@0 481 Where 300 and 500 are the lowest and highest UIDs from client's
yuuji@0 482 cache. The second SEARCH response tells the client that the messages
yuuji@0 483 with UIDs 407, 410, and 412 are still present, but their flags
yuuji@0 484 haven't changed since the specified modification sequence.
yuuji@0 485
yuuji@0 486 Using the VANISHED UID FETCH modifier, it is sufficient to issue only
yuuji@0 487 a single command:
yuuji@0 488
yuuji@0 489 C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345
yuuji@0 490 VANISHED)
yuuji@0 491 S: * VANISHED (EARLIER) 300:310,405,411
yuuji@0 492 S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen))
yuuji@0 493 S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted))
yuuji@0 494 S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk
yuuji@0 495 $AutoJunk $MDNSent))
yuuji@0 496 S: s100 OK FETCH completed
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 Melnikov, et al. Standards Track [Page 9]
yuuji@0 507
yuuji@0 508 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 509
yuuji@0 510
yuuji@0 511 3.3. EXPUNGE Command
yuuji@0 512
yuuji@0 513 Arguments: none
yuuji@0 514
yuuji@0 515 Responses: untagged responses: EXPUNGE or VANISHED
yuuji@0 516
yuuji@0 517 Result: OK - expunge completed
yuuji@0 518 NO - expunge failure: can't expunge (e.g., permission denied)
yuuji@0 519 BAD - command unknown or arguments invalid
yuuji@0 520
yuuji@0 521 This section updates the definition of the EXPUNGE command described
yuuji@0 522 in Section 6.4.3 of [RFC3501].
yuuji@0 523
yuuji@0 524 The EXPUNGE command permanently removes all messages that have the
yuuji@0 525 \Deleted flag set from the currently selected mailbox. Before
yuuji@0 526 returning an OK to the client, those messages that are removed are
yuuji@0 527 reported using a VANISHED response or EXPUNGE responses.
yuuji@0 528
yuuji@0 529 If the server is capable of storing modification sequences for the
yuuji@0 530 selected mailbox, it MUST increment the per-mailbox mod-sequence if
yuuji@0 531 at least one message was permanently removed due to the execution of
yuuji@0 532 the EXPUNGE command. For each permanently removed message, the
yuuji@0 533 server MUST remember the incremented mod-sequence and corresponding
yuuji@0 534 UID. If at least one message got expunged, the server MUST send the
yuuji@0 535 updated per-mailbox modification sequence using the HIGHESTMODSEQ
yuuji@0 536 response code (defined in [CONDSTORE]) in the tagged OK response.
yuuji@0 537
yuuji@0 538 Example: C: A202 EXPUNGE
yuuji@0 539 S: * 3 EXPUNGE
yuuji@0 540 S: * 3 EXPUNGE
yuuji@0 541 S: * 5 EXPUNGE
yuuji@0 542 S: * 8 EXPUNGE
yuuji@0 543 S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged
yuuji@0 544
yuuji@0 545 Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag
yuuji@0 546 set. The first "* 3 EXPUNGE" reports message # 3 as expunged. The
yuuji@0 547 second "* 3 EXPUNGE" reports message # 4 as expunged (the message
yuuji@0 548 number got decremented due to the previous EXPUNGE response). See
yuuji@0 549 the description of the EXPUNGE response in [RFC3501] for further
yuuji@0 550 explanation.
yuuji@0 551
yuuji@0 552 Note that if the server chooses to always send VANISHED responses
yuuji@0 553 instead of EXPUNGE responses, the previous example might look like
yuuji@0 554 this:
yuuji@0 555
yuuji@0 556 Example: C: B202 EXPUNGE
yuuji@0 557 S: * VANISHED 405,407,410,425
yuuji@0 558 S: B202 OK [HIGHESTMODSEQ 20010715194045319] expunged
yuuji@0 559
yuuji@0 560
yuuji@0 561
yuuji@0 562 Melnikov, et al. Standards Track [Page 10]
yuuji@0 563
yuuji@0 564 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 565
yuuji@0 566
yuuji@0 567 Here messages with message numbers 3, 4, 7, and 11 have respective
yuuji@0 568 UIDs 405, 407, 410, and 425.
yuuji@0 569
yuuji@0 570 3.4. CLOSE Command
yuuji@0 571
yuuji@0 572 Arguments: none
yuuji@0 573
yuuji@0 574 Responses: no specific responses for this command
yuuji@0 575
yuuji@0 576 Result: OK - close completed, now in authenticated state
yuuji@0 577 BAD - command unknown or arguments invalid
yuuji@0 578
yuuji@0 579 This section updates the definition of the CLOSE command described in
yuuji@0 580 Section 6.4.2 of [RFC3501].
yuuji@0 581
yuuji@0 582 The CLOSE command permanently removes all messages that have the
yuuji@0 583 \Deleted flag set from the currently selected mailbox, and returns to
yuuji@0 584 the authenticated state from the selected state. No untagged EXPUNGE
yuuji@0 585 (or VANISHED) responses are sent.
yuuji@0 586
yuuji@0 587 If the server is capable of storing modification sequences for the
yuuji@0 588 selected mailbox, it MUST increment the per-mailbox mod-sequence if
yuuji@0 589 at least one message was permanently removed due to the execution of
yuuji@0 590 the CLOSE command. For each permanently removed message, the server
yuuji@0 591 MUST remember the incremented mod-sequence and corresponding UID. If
yuuji@0 592 at least one message got expunged, the server MUST send the updated
yuuji@0 593 per-mailbox modification sequence using the HIGHESTMODSEQ response
yuuji@0 594 code (defined in [CONDSTORE]) in the tagged OK response.
yuuji@0 595
yuuji@0 596 Example: C: A202 CLOSE
yuuji@0 597 S: A202 OK [HIGHESTMODSEQ 20010715194045319] done
yuuji@0 598
yuuji@0 599 3.5. UID EXPUNGE Command
yuuji@0 600
yuuji@0 601 Arguments: message set
yuuji@0 602
yuuji@0 603 Responses: untagged responses: EXPUNGE or VANISHED
yuuji@0 604
yuuji@0 605 Result: OK - expunge completed
yuuji@0 606 NO - expunge failure: can't expunge (e.g., permission denied)
yuuji@0 607 BAD - command unknown or arguments invalid
yuuji@0 608
yuuji@0 609 This section updates the definition of the UID EXPUNGE command
yuuji@0 610 described in Section 2.1 of [UIDPLUS]. Servers that implement both
yuuji@0 611 [UIDPLUS] and QRESYNC extensions must implement UID EXPUNGE as
yuuji@0 612 described in this section.
yuuji@0 613
yuuji@0 614
yuuji@0 615
yuuji@0 616
yuuji@0 617
yuuji@0 618 Melnikov, et al. Standards Track [Page 11]
yuuji@0 619
yuuji@0 620 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 621
yuuji@0 622
yuuji@0 623 The UID EXPUNGE command permanently removes from the currently
yuuji@0 624 selected mailbox all messages that both have the \Deleted flag set
yuuji@0 625 and have a UID that is included in the specified message set. If a
yuuji@0 626 message either does not have the \Deleted flag set or has a UID that
yuuji@0 627 is not included in the specified message set, it is not affected.
yuuji@0 628
yuuji@0 629 This command is particularly useful for disconnected mode clients.
yuuji@0 630 By using UID EXPUNGE instead of EXPUNGE when resynchronizing with the
yuuji@0 631 server, the client can avoid inadvertently removing any messages that
yuuji@0 632 have been marked as \Deleted by other clients between the time that
yuuji@0 633 the client was last connected and the time the client resynchronizes.
yuuji@0 634
yuuji@0 635 Before returning an OK to the client, those messages that are removed
yuuji@0 636 are reported using a VANISHED response or EXPUNGE responses.
yuuji@0 637
yuuji@0 638 If the server is capable of storing modification sequences for the
yuuji@0 639 selected mailbox, it MUST increment the per-mailbox mod-sequence if
yuuji@0 640 at least one message was permanently removed due to the execution of
yuuji@0 641 the UID EXPUNGE command. For each permanently removed message, the
yuuji@0 642 server MUST remember the incremented mod-sequence and corresponding
yuuji@0 643 UID. If at least one message got expunged, the server MUST send the
yuuji@0 644 updated per-mailbox modification sequence using the HIGHESTMODSEQ
yuuji@0 645 response code (defined in [CONDSTORE]) in the tagged OK response.
yuuji@0 646
yuuji@0 647 Example: C: . UID EXPUNGE 3000:3002
yuuji@0 648 S: * 3 EXPUNGE
yuuji@0 649 S: * 3 EXPUNGE
yuuji@0 650 S: * 3 EXPUNGE
yuuji@0 651 S: . OK [HIGHESTMODSEQ 20010715194045319] Ok
yuuji@0 652
yuuji@0 653 Note: In this example, at least messages with message numbers 3, 4,
yuuji@0 654 and 5 (UIDs 3000 to 3002) had the \Deleted flag set. The first "* 3
yuuji@0 655 EXPUNGE" reports message # 3 as expunged. The second "* 3 EXPUNGE"
yuuji@0 656 reports message # 4 as expunged (the message number got decremented
yuuji@0 657 due to the previous EXPUNGE response). See the description of the
yuuji@0 658 EXPUNGE response in [RFC3501] for further explanation.
yuuji@0 659
yuuji@0 660 3.6. VANISHED Response
yuuji@0 661
yuuji@0 662 Contents: an optional EARLIER tag
yuuji@0 663
yuuji@0 664 list of UIDs
yuuji@0 665
yuuji@0 666 The VANISHED response reports that the specified UIDs have been
yuuji@0 667 permanently removed from the mailbox. This response is similar to
yuuji@0 668 the EXPUNGE response [RFC3501]; however, it can return information
yuuji@0 669 about multiple messages, and it returns UIDs instead of message
yuuji@0 670
yuuji@0 671
yuuji@0 672
yuuji@0 673
yuuji@0 674 Melnikov, et al. Standards Track [Page 12]
yuuji@0 675
yuuji@0 676 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 677
yuuji@0 678
yuuji@0 679 numbers. The first benefit saves bandwidth, while the second is more
yuuji@0 680 convenient for clients that only use UIDs to access the IMAP server.
yuuji@0 681
yuuji@0 682 The VANISHED response has the same restrictions on when it can be
yuuji@0 683 sent as does the EXPUNGE response (see below).
yuuji@0 684
yuuji@0 685 The VANISHED response has two forms. The first form contains the
yuuji@0 686 EARLIER tag, which signifies that the response was caused by a UID
yuuji@0 687 FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. This
yuuji@0 688 response is sent if the UID set parameter to the UID FETCH (VANISHED)
yuuji@0 689 command includes UIDs of messages that are no longer in the mailbox.
yuuji@0 690 When the client sees a VANISHED EARLIER response, it MUST NOT
yuuji@0 691 decrement message sequence numbers for each successive message in the
yuuji@0 692 mailbox.
yuuji@0 693
yuuji@0 694 The second form doesn't contain the EARLIER tag and is described
yuuji@0 695 below. Once a client has issued "ENABLE QRESYNC", the server SHOULD
yuuji@0 696 use the VANISHED response without the EARLIER tag instead of the
yuuji@0 697 EXPUNGE response. The server SHOULD continue using VANISHED in lieu
yuuji@0 698 of EXPUNGE for the duration of the connection. In particular, this
yuuji@0 699 affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as
yuuji@0 700 well as messages expunged in other connections. Such a VANISHED
yuuji@0 701 response MUST NOT contain the EARLIER tag.
yuuji@0 702
yuuji@0 703 A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command
yuuji@0 704 or because messages were expunged in other connections (i.e., the
yuuji@0 705 VANISHED response without the EARLIER tag) also decrements the number
yuuji@0 706 of messages in the mailbox; it is not necessary for the server to
yuuji@0 707 send an EXISTS response with the new value. It also decrements
yuuji@0 708 message sequence numbers for each successive message in the mailbox
yuuji@0 709 (see the example at the end of this section). Note that a VANISHED
yuuji@0 710 response caused by EXPUNGE, UID EXPUNGE, or messages expunged in
yuuji@0 711 other connections SHOULD only contain UIDs for messages expunged
yuuji@0 712 since the last VANISHED/EXPUNGE response sent for the currently
yuuji@0 713 opened mailbox or since the mailbox was opened. That is, servers
yuuji@0 714 SHOULD NOT send UIDs for previously expunged messages, unless
yuuji@0 715 explicitly requested to do so by the UID FETCH (VANISHED) command.
yuuji@0 716
yuuji@0 717 Note that client implementors must take care to properly decrement
yuuji@0 718 the number of messages in the mailbox even if a server violates this
yuuji@0 719 last SHOULD or repeats the same UID multiple times in the returned
yuuji@0 720 UID set. In general, this means that a client using this extension
yuuji@0 721 should either avoid using message numbers entirely, or have a
yuuji@0 722 complete mapping of UIDs to message sequence numbers for the selected
yuuji@0 723 mailbox.
yuuji@0 724
yuuji@0 725
yuuji@0 726
yuuji@0 727
yuuji@0 728
yuuji@0 729
yuuji@0 730 Melnikov, et al. Standards Track [Page 13]
yuuji@0 731
yuuji@0 732 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 733
yuuji@0 734
yuuji@0 735 Because clients handle the two different forms of the VANISHED
yuuji@0 736 response differently, servers MUST NOT report UIDs resulting from a
yuuji@0 737 UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) in the same
yuuji@0 738 VANISHED response as UIDs of messages expunged now (i.e., messages
yuuji@0 739 expunged in other connections). Instead, the server MUST send
yuuji@0 740 separate VANISHED responses: one with the EARLIER tag and one
yuuji@0 741 without.
yuuji@0 742
yuuji@0 743 A VANISHED response MUST NOT be sent when no command is in progress,
yuuji@0 744 nor while responding to a FETCH, STORE, or SEARCH command. This rule
yuuji@0 745 is necessary to prevent a loss of synchronization of message sequence
yuuji@0 746 numbers between client and server. A command is not "in progress"
yuuji@0 747 until the complete command has been received; in particular, a
yuuji@0 748 command is not "in progress" during the negotiation of command
yuuji@0 749 continuation.
yuuji@0 750
yuuji@0 751 Note: UID FETCH, UID STORE, and UID SEARCH are different commands
yuuji@0 752 from FETCH, STORE, and SEARCH. A VANISHED response MAY be sent
yuuji@0 753 during a UID command. However, the VANISHED response MUST NOT be
yuuji@0 754 sent during a UID SEARCH command that contains message numbers in the
yuuji@0 755 search criteria.
yuuji@0 756
yuuji@0 757 The update from the VANISHED response MUST be recorded by the client.
yuuji@0 758
yuuji@0 759 Example: Let's assume that there is the following mapping between
yuuji@0 760 message numbers and UIDs in the currently selected mailbox (here "X"
yuuji@0 761 marks messages with the \Deleted flag set, and "x" represents UIDs
yuuji@0 762 which are not relevant for the example):
yuuji@0 763
yuuji@0 764 Message numbers: 1 2 3 4 5 6 7 8 9 10 11
yuuji@0 765 UIDs: x 504 505 507 508 x 510 x x x 625
yuuji@0 766 \Deleted messages: X X X X
yuuji@0 767
yuuji@0 768 In the presence of the extension defined in this document:
yuuji@0 769
yuuji@0 770 C: A202 EXPUNGE
yuuji@0 771 S: * VANISHED 505,507,510,625
yuuji@0 772 S: A202 OK EXPUNGE completed
yuuji@0 773
yuuji@0 774 Without the QRESYNC extension, the same example might look like:
yuuji@0 775
yuuji@0 776 C: A202 EXPUNGE
yuuji@0 777 S: * 3 EXPUNGE
yuuji@0 778 S: * 3 EXPUNGE
yuuji@0 779 S: * 5 EXPUNGE
yuuji@0 780 S: * 8 EXPUNGE
yuuji@0 781 S: A202 OK EXPUNGE completed
yuuji@0 782
yuuji@0 783
yuuji@0 784
yuuji@0 785
yuuji@0 786 Melnikov, et al. Standards Track [Page 14]
yuuji@0 787
yuuji@0 788 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 789
yuuji@0 790
yuuji@0 791 (Continuing previous example) If subsequently messages with UIDs 504
yuuji@0 792 and 508 got marked as \Deleted:
yuuji@0 793
yuuji@0 794 C: A210 EXPUNGE
yuuji@0 795 S: * VANISHED 504,508
yuuji@0 796 S: A210 OK EXPUNGE completed
yuuji@0 797
yuuji@0 798 i.e., the last VANISHED response only contains UIDs of messages
yuuji@0 799 expunged since the previous VANISHED response.
yuuji@0 800
yuuji@0 801 3.7. CLOSED Response Code
yuuji@0 802
yuuji@0 803 The CLOSED response code has no parameters. A server implementing
yuuji@0 804 the extension defined in this document MUST return the CLOSED
yuuji@0 805 response code when the currently selected mailbox is closed
yuuji@0 806 implicitly using the SELECT/EXAMINE command on another mailbox. The
yuuji@0 807 CLOSED response code serves as a boundary between responses for the
yuuji@0 808 previously opened mailbox (which was closed) and the newly selected
yuuji@0 809 mailbox: all responses before the CLOSED response code relate to the
yuuji@0 810 mailbox that was closed, and all subsequent responses relate to the
yuuji@0 811 newly opened mailbox.
yuuji@0 812
yuuji@0 813 There is no need to return the CLOSED response code on completion of
yuuji@0 814 the CLOSE or the UNSELECT [UNSELECT] command (or similar) whose
yuuji@0 815 purpose is to close the currently selected mailbox without opening a
yuuji@0 816 new one.
yuuji@0 817
yuuji@0 818 4. Server Implementation Considerations
yuuji@0 819
yuuji@0 820 This section describes a minimalist implementation, a moderate
yuuji@0 821 implementation, and an example of a full implementation.
yuuji@0 822
yuuji@0 823 4.1. Server Implementations That Don't Store Extra State
yuuji@0 824
yuuji@0 825 Strictly speaking, a server implementation that doesn't remember mod-
yuuji@0 826 sequences associated with expunged messages can be considered
yuuji@0 827 compliant with this specification. Such implementations return all
yuuji@0 828 expunged messages specified in the UID set of the UID FETCH
yuuji@0 829 (VANISHED) command every time, without paying attention to the
yuuji@0 830 specified CHANGEDSINCE mod-sequence. Such implementations are
yuuji@0 831 discouraged, as they can end up returning VANISHED responses that are
yuuji@0 832 bigger than the result of a UID SEARCH command for the same UID set.
yuuji@0 833
yuuji@0 834 Clients that use the message sequence match data can reduce the scope
yuuji@0 835 of this VANISHED response substantially in the typical case where
yuuji@0 836 expunges have not happened, or happen only toward the end of the
yuuji@0 837 mailbox.
yuuji@0 838
yuuji@0 839
yuuji@0 840
yuuji@0 841
yuuji@0 842 Melnikov, et al. Standards Track [Page 15]
yuuji@0 843
yuuji@0 844 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 845
yuuji@0 846
yuuji@0 847 4.2. Server Implementations Storing Minimal State
yuuji@0 848
yuuji@0 849 A server that stores the HIGHESTMODSEQ value at the time of the last
yuuji@0 850 EXPUNGE can omit the VANISHED response when a client provides a
yuuji@0 851 MODSEQ value that is equal to, or higher than, the current value of
yuuji@0 852 this datum, that is, when there have been no EXPUNGEs.
yuuji@0 853
yuuji@0 854 A client providing message sequence match data can reduce the scope
yuuji@0 855 as above. In the case where there have been no expunges, the server
yuuji@0 856 can ignore this data.
yuuji@0 857
yuuji@0 858 4.3. Additional State Required on the Server
yuuji@0 859
yuuji@0 860 When compared to the [CONDSTORE] extension, this extension requires
yuuji@0 861 servers to store additional state associated with expunged messages.
yuuji@0 862 Note that implementations are not required to store this state in
yuuji@0 863 persistent storage; however, use of persistent storage is advisable.
yuuji@0 864
yuuji@0 865 One possible way to correctly implement the extension described in
yuuji@0 866 this document is to store a queue of <UID set, mod-sequence> pairs.
yuuji@0 867 <UID set> can be represented as a sequence of <min UID, max UID>
yuuji@0 868 pairs.
yuuji@0 869
yuuji@0 870 When messages are expunged, one or more entries are added to the
yuuji@0 871 queue tail.
yuuji@0 872
yuuji@0 873 When the server receives a request to return messages expunged since
yuuji@0 874 a given mod-sequence, it will search the queue from the tail (i.e.,
yuuji@0 875 going from the highest expunged mod-sequence to the lowest) until it
yuuji@0 876 sees the first record with a mod-sequence less than or equal to the
yuuji@0 877 given mod-sequence or it reaches the head of the queue.
yuuji@0 878
yuuji@0 879 Note that indefinitely storing information about expunged messages
yuuji@0 880 can cause storage and related problems for an implementation. In the
yuuji@0 881 worst case, this could result in almost 64Gb of storage for each IMAP
yuuji@0 882 mailbox. For example, consider an implementation that stores <min
yuuji@0 883 UID, max UID, mod-sequence> triples for each range of messages
yuuji@0 884 expunged at the same time. Each triple requires 16 octets: 4 octets
yuuji@0 885 for each of the two UIDs, and 8 octets for the mod-sequence. Assume
yuuji@0 886 that there is a mailbox containing a single message with a UID of
yuuji@0 887 2**32-1 (the maximum possible UID value), where messages had
yuuji@0 888 previously existed with UIDs starting at 1, and have been expunged
yuuji@0 889 one at a time. For this mailbox alone, storage is required for the
yuuji@0 890 triples <1, 1, modseq1>, <2, 2, modseq2>, ..., <2**32-2, 2**32-2,
yuuji@0 891 modseq4294967294>.
yuuji@0 892
yuuji@0 893
yuuji@0 894
yuuji@0 895
yuuji@0 896
yuuji@0 897
yuuji@0 898 Melnikov, et al. Standards Track [Page 16]
yuuji@0 899
yuuji@0 900 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 901
yuuji@0 902
yuuji@0 903 Hence, implementations are encouraged to adopt strategies to protect
yuuji@0 904 against such storage problems, such as limiting the size of the queue
yuuji@0 905 used to store mod-sequences for expunged messages and "expiring"
yuuji@0 906 older records when this limit is reached. When the selected
yuuji@0 907 implementation-specific queue limit is reached, the oldest record(s)
yuuji@0 908 are deleted from the queue (note that such records are located at the
yuuji@0 909 queue head). For all such "expired" records, the server needs to
yuuji@0 910 store a single mod-sequence, which is the highest mod-sequence for
yuuji@0 911 all "expired" expunged messages.
yuuji@0 912
yuuji@0 913 Note that if the client provides the message sequence match data,
yuuji@0 914 this can heavily reduce the data cost of sending a complete set of
yuuji@0 915 missing UIDs; thus, reducing the problems for clients if a server is
yuuji@0 916 unable to persist much of this queue. If the queue contains data
yuuji@0 917 back to the requested mod-sequence, this data can be ignored.
yuuji@0 918
yuuji@0 919 Also, note that if the UIDVALIDITY of the mailbox changes or if the
yuuji@0 920 mailbox is deleted, then any state associated with expunged messages
yuuji@0 921 doesn't need to be preserved and SHOULD be deleted.
yuuji@0 922
yuuji@0 923 5. Updated Synchronization Sequence
yuuji@0 924
yuuji@0 925 This section updates the description of optimized synchronization in
yuuji@0 926 Section 6.1 of the [IMAP-DISC].
yuuji@0 927
yuuji@0 928 An advanced disconnected mail client should use the QRESYNC and
yuuji@0 929 [CONDSTORE] extensions when they are supported by the server. The
yuuji@0 930 client uses the value from the HIGHESTMODSEQ OK response code
yuuji@0 931 received on mailbox opening to determine if it needs to
yuuji@0 932 resynchronize. Once the synchronization is complete, it MUST cache
yuuji@0 933 the received value (unless the mailbox UIDVALIDITY value has changed;
yuuji@0 934 see below). The client MUST update its copy of the HIGHESTMODSEQ
yuuji@0 935 value whenever the server sends a subsequent HIGHESTMODSEQ OK
yuuji@0 936 response code.
yuuji@0 937
yuuji@0 938 After completing a full synchronization, the client MUST also take
yuuji@0 939 note of any unsolicited MODSEQ FETCH data items received from the
yuuji@0 940 server. Whenever the client receives a tagged response to a command,
yuuji@0 941 it calculates the highest value among all MODSEQ FETCH data items
yuuji@0 942 received since the last tagged response. If this value is bigger
yuuji@0 943 than the client's copy of the HIGHESTMODSEQ value, then the client
yuuji@0 944 MUST use this value as its new HIGHESTMODSEQ value.
yuuji@0 945
yuuji@0 946 Note: It is not safe to update the client's copy of the HIGHESTMODSEQ
yuuji@0 947 value with a MODSEQ FETCH data item value as soon as it is received
yuuji@0 948 because servers are not required to send MODSEQ FETCH data items in
yuuji@0 949 increasing modseqence order. This can lead to the client missing
yuuji@0 950 some changes in case of connectivity loss.
yuuji@0 951
yuuji@0 952
yuuji@0 953
yuuji@0 954 Melnikov, et al. Standards Track [Page 17]
yuuji@0 955
yuuji@0 956 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 957
yuuji@0 958
yuuji@0 959 When opening the mailbox for synchronization, the client uses the
yuuji@0 960 QRESYNC parameter to the SELECT/EXAMINE command. The QRESYNC
yuuji@0 961 parameter is followed by the UIDVALIDITY and mailbox HIGHESTMODSEQ
yuuji@0 962 values, as known to the client. It can be optionally followed by the
yuuji@0 963 set of UIDs, for example, if the client is only interested in partial
yuuji@0 964 synchronization of the mailbox. The client may also transmit a list
yuuji@0 965 containing its knowledge of message numbers.
yuuji@0 966
yuuji@0 967 If the SELECT/EXAMINE command is successful, the client compares
yuuji@0 968 UIDVALIDITY as described in step d)1) in Section 3 of the
yuuji@0 969 [IMAP-DISC]. If the cached UIDVALIDITY value matches the one
yuuji@0 970 returned by the server and the server also returns the HIGHESTMODSEQ
yuuji@0 971 response code, then the server reports expunged messages and returns
yuuji@0 972 flag changes for all messages specified by the client in the UID set
yuuji@0 973 parameter (or for all messages in the mailbox, if the client omitted
yuuji@0 974 the UID set parameter). At this point, the client is synchronized,
yuuji@0 975 except for maybe the new messages.
yuuji@0 976
yuuji@0 977 If upon a successful SELECT/EXAMINE (QRESYNC) command the client
yuuji@0 978 receives a NOMODSEQ OK untagged response (instead of the
yuuji@0 979 HIGHESTMODSEQ response code), it MUST remove the last known
yuuji@0 980 HIGHESTMODSEQ value from its cache and follow the more general
yuuji@0 981 instructions in Section 3 of the [IMAP-DISC].
yuuji@0 982
yuuji@0 983 At this point, the client is in sync with the server regarding old
yuuji@0 984 messages. This client can now fetch information about new messages
yuuji@0 985 (if requested by the user).
yuuji@0 986
yuuji@0 987 Step d) ("Server-to-client synchronization") in Section 4 of the
yuuji@0 988 [IMAP-DISC] in the presence of the QRESYNC & CONDSTORE extensions is
yuuji@0 989 amended as follows:
yuuji@0 990
yuuji@0 991 d) "Server-to-client synchronization" -- for each mailbox that
yuuji@0 992 requires synchronization, do the following:
yuuji@0 993
yuuji@0 994 1a) Check the mailbox UIDVALIDITY (see Section 4.1 of the [IMAP-DISC]
yuuji@0 995 for more details) after issuing SELECT/EXAMINE (QRESYNC) command.
yuuji@0 996
yuuji@0 997 If the UIDVALIDITY value returned by the server differs, the
yuuji@0 998 client MUST
yuuji@0 999
yuuji@0 1000 * empty the local cache of that mailbox;
yuuji@0 1001
yuuji@0 1002 * "forget" the cached HIGHESTMODSEQ value for the mailbox;
yuuji@0 1003
yuuji@0 1004
yuuji@0 1005
yuuji@0 1006
yuuji@0 1007
yuuji@0 1008
yuuji@0 1009
yuuji@0 1010 Melnikov, et al. Standards Track [Page 18]
yuuji@0 1011
yuuji@0 1012 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 1013
yuuji@0 1014
yuuji@0 1015 * remove any pending "actions" which refer to UIDs in that
yuuji@0 1016 mailbox. Note, this doesn't affect actions performed on
yuuji@0 1017 client generated fake UIDs (see Section 5 of the
yuuji@0 1018 [IMAP-DISC]);
yuuji@0 1019
yuuji@0 1020 2) Fetch the current "descriptors";
yuuji@0 1021
yuuji@0 1022 I) Discover new messages.
yuuji@0 1023
yuuji@0 1024 3) Fetch the bodies of any "interesting" messages that the client
yuuji@0 1025 doesn't already have.
yuuji@0 1026
yuuji@0 1027 Example: The UIDVALIDITY value is the same, but the HIGHESTMODSEQ
yuuji@0 1028 value has changed on the server while the client was
yuuji@0 1029 offline:
yuuji@0 1030
yuuji@0 1031 C: A142 SELECT INBOX (QRESYNC (3857529045 20010715194032001 1:198))
yuuji@0 1032 S: * 172 EXISTS
yuuji@0 1033 S: * 1 RECENT
yuuji@0 1034 S: * OK [UNSEEN 12] Message 12 is first unseen
yuuji@0 1035 S: * OK [UIDVALIDITY 3857529045] UIDs valid
yuuji@0 1036 S: * OK [UIDNEXT 201] Predicted next UID
yuuji@0 1037 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
yuuji@0 1038 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
yuuji@0 1039 S: * OK [HIGHESTMODSEQ 20010715194045007]
yuuji@0 1040 S: * VANISHED (EARLIER) 1:5,7:8,10:15
yuuji@0 1041 S: * 2 FETCH (UID 6 MODSEQ (20010715205008000)
yuuji@0 1042 FLAGS (\Deleted))
yuuji@0 1043 S: * 5 FETCH (UID 9 MODSEQ (20010715195517000)
yuuji@0 1044 FLAGS ($NoJunk $AutoJunk $MDNSent))
yuuji@0 1045 ...
yuuji@0 1046 S: A142 OK [READ-WRITE] SELECT completed
yuuji@0 1047
yuuji@0 1048 6. Formal Syntax
yuuji@0 1049
yuuji@0 1050 The following syntax specification uses the Augmented Backus-Naur
yuuji@0 1051 Form (ABNF) notation as specified in [ABNF].
yuuji@0 1052
yuuji@0 1053 Non-terminals referenced but not defined below are as defined by
yuuji@0 1054 [RFC3501], [CONDSTORE], or [IMAPABNF].
yuuji@0 1055
yuuji@0 1056 Except as noted otherwise, all alphabetic characters are case-
yuuji@0 1057 insensitive. The use of upper or lower case characters to define
yuuji@0 1058 token strings is for editorial clarity only. Implementations MUST
yuuji@0 1059 accept these strings in a case-insensitive fashion.
yuuji@0 1060
yuuji@0 1061
yuuji@0 1062
yuuji@0 1063
yuuji@0 1064
yuuji@0 1065
yuuji@0 1066 Melnikov, et al. Standards Track [Page 19]
yuuji@0 1067
yuuji@0 1068 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 1069
yuuji@0 1070
yuuji@0 1071 capability =/ "QRESYNC"
yuuji@0 1072
yuuji@0 1073 select-param = "QRESYNC" SP "(" uidvalidity SP
yuuji@0 1074 mod-sequence-value [SP known-uids]
yuuji@0 1075 [SP seq-match-data] ")"
yuuji@0 1076 ;; conforms to the generic select-param
yuuji@0 1077 ;; syntax defined in [IMAPABNF]
yuuji@0 1078
yuuji@0 1079 seq-match-data = "(" known-sequence-set SP known-uid-set ")"
yuuji@0 1080
yuuji@0 1081 uidvalidity = nz-number
yuuji@0 1082
yuuji@0 1083 known-uids = sequence-set
yuuji@0 1084 ;; sequence of UIDs, "*" is not allowed
yuuji@0 1085
yuuji@0 1086 known-sequence-set = sequence-set
yuuji@0 1087 ;; set of message numbers corresponding to
yuuji@0 1088 ;; the UIDs in known-uid-set, in ascending order.
yuuji@0 1089 ;; * is not allowed.
yuuji@0 1090
yuuji@0 1091 known-uid-set = sequence-set
yuuji@0 1092 ;; set of UIDs corresponding to the messages in
yuuji@0 1093 ;; known-sequence-set, in ascending order.
yuuji@0 1094 ;; * is not allowed.
yuuji@0 1095
yuuji@0 1096 message-data =/ expunged-resp
yuuji@0 1097
yuuji@0 1098 expunged-resp = "VANISHED" [SP "(EARLIER)"] SP known-uids
yuuji@0 1099
yuuji@0 1100 rexpunges-fetch-mod = "VANISHED"
yuuji@0 1101 ;; VANISHED UID FETCH modifier conforms
yuuji@0 1102 ;; to the fetch-modifier syntax
yuuji@0 1103 ;; defined in [IMAPABNF]. It is only
yuuji@0 1104 ;; allowed in the UID FETCH command.
yuuji@0 1105
yuuji@0 1106 resp-text-code =/ "CLOSED"
yuuji@0 1107
yuuji@0 1108 7. Security Considerations
yuuji@0 1109
yuuji@0 1110 As always, it is important to thoroughly test clients and servers
yuuji@0 1111 implementing this extension, as it changes how the server reports
yuuji@0 1112 expunged messages to the client.
yuuji@0 1113
yuuji@0 1114 Security considerations relevant to [CONDSTORE] are relevant to this
yuuji@0 1115 extension.
yuuji@0 1116
yuuji@0 1117 This document doesn't raise any new security concerns not already
yuuji@0 1118 raised by [CONDSTORE] or [RFC3501].
yuuji@0 1119
yuuji@0 1120
yuuji@0 1121
yuuji@0 1122 Melnikov, et al. Standards Track [Page 20]
yuuji@0 1123
yuuji@0 1124 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 1125
yuuji@0 1126
yuuji@0 1127 8. IANA Considerations
yuuji@0 1128
yuuji@0 1129 IMAP4 capabilities are registered by publishing a standards track or
yuuji@0 1130 IESG approved experimental RFC. The registry is currently located
yuuji@0 1131 at:
yuuji@0 1132
yuuji@0 1133 http://www.iana.org/assignments/imap4-capabilities
yuuji@0 1134
yuuji@0 1135 This document defines the QRESYNC IMAP capability. IANA has added
yuuji@0 1136 this capability to the registry.
yuuji@0 1137
yuuji@0 1138 9. Acknowledgments
yuuji@0 1139
yuuji@0 1140 Thanks to Steve Hole, Cyrus Daboo, and Michael Wener for encouraging
yuuji@0 1141 creation of this document.
yuuji@0 1142
yuuji@0 1143 Valuable comments, both in agreement and in dissent, were received
yuuji@0 1144 from Timo Sirainen, Michael Wener, Randall Gellens, Arnt Gulbrandsen,
yuuji@0 1145 Chris Newman, Peter Coates, Mark Crispin, Elwyn Davies, Dan Karp,
yuuji@0 1146 Eric Rescorla, and Mike Zraly.
yuuji@0 1147
yuuji@0 1148 This document takes substantial text from [RFC3501] by Mark Crispin.
yuuji@0 1149
yuuji@0 1150 10. References
yuuji@0 1151
yuuji@0 1152 10.1. Normative References
yuuji@0 1153
yuuji@0 1154 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
yuuji@0 1155 Specifications: ABNF", STD 68, RFC 5234, January 2008.
yuuji@0 1156
yuuji@0 1157 [CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for
yuuji@0 1158 Conditional STORE Operation or Quick Flag Changes
yuuji@0 1159 Resynchronization", RFC 4551, June 2006.
yuuji@0 1160
yuuji@0 1161 [ENABLE] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP
yuuji@0 1162 ENABLE Extension", RFC 5161, March 2008.
yuuji@0 1163
yuuji@0 1164 [IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to
yuuji@0 1165 IMAP4 ABNF", RFC 4466, April 2006.
yuuji@0 1166
yuuji@0 1167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
yuuji@0 1168 Requirement Levels", BCP 14, RFC 2119, March 1997.
yuuji@0 1169
yuuji@0 1170 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
yuuji@0 1171 4rev1", RFC 3501, March 2003.
yuuji@0 1172
yuuji@0 1173 [UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) -
yuuji@0 1174 UIDPLUS extension", RFC 4315, December 2005.
yuuji@0 1175
yuuji@0 1176
yuuji@0 1177
yuuji@0 1178 Melnikov, et al. Standards Track [Page 21]
yuuji@0 1179
yuuji@0 1180 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 1181
yuuji@0 1182
yuuji@0 1183 10.2. Informative References
yuuji@0 1184
yuuji@0 1185 [IMAP-DISC] Melnikov, A., Ed., "Synchronization Operations For
yuuji@0 1186 Disconnected Imap4 Clients", RFC 4549, June 2006.
yuuji@0 1187
yuuji@0 1188 [UNSELECT] Melnikov, A., "Internet Message Access Protocol (IMAP)
yuuji@0 1189 UNSELECT command", RFC 3691, February 2004.
yuuji@0 1190
yuuji@0 1191 Authors' Addresses
yuuji@0 1192
yuuji@0 1193 Alexey Melnikov
yuuji@0 1194 Isode Ltd
yuuji@0 1195 5 Castle Business Village
yuuji@0 1196 36 Station Road
yuuji@0 1197 Hampton, Middlesex TW12 2BX
yuuji@0 1198 UK
yuuji@0 1199
yuuji@0 1200 EMail: Alexey.Melnikov@isode.com
yuuji@0 1201
yuuji@0 1202
yuuji@0 1203 Dave Cridland
yuuji@0 1204 Isode Ltd
yuuji@0 1205 5 Castle Business Village
yuuji@0 1206 36 Station Road
yuuji@0 1207 Hampton, Middlesex TW12 2BX
yuuji@0 1208 UK
yuuji@0 1209
yuuji@0 1210 EMail: dave.cridland@isode.com
yuuji@0 1211
yuuji@0 1212
yuuji@0 1213 Corby Wilson
yuuji@0 1214 Nokia
yuuji@0 1215 5 Wayside Rd.
yuuji@0 1216 Burlington, MA 01803
yuuji@0 1217 USA
yuuji@0 1218
yuuji@0 1219 EMail: corby@computer.org
yuuji@0 1220
yuuji@0 1221
yuuji@0 1222
yuuji@0 1223
yuuji@0 1224
yuuji@0 1225
yuuji@0 1226
yuuji@0 1227
yuuji@0 1228
yuuji@0 1229
yuuji@0 1230
yuuji@0 1231
yuuji@0 1232
yuuji@0 1233
yuuji@0 1234 Melnikov, et al. Standards Track [Page 22]
yuuji@0 1235
yuuji@0 1236 RFC 5162 IMAP Quick Mailbox Resync March 2008
yuuji@0 1237
yuuji@0 1238
yuuji@0 1239 Full Copyright Statement
yuuji@0 1240
yuuji@0 1241 Copyright (C) The IETF Trust (2008).
yuuji@0 1242
yuuji@0 1243 This document is subject to the rights, licenses and restrictions
yuuji@0 1244 contained in BCP 78, and except as set forth therein, the authors
yuuji@0 1245 retain all their rights.
yuuji@0 1246
yuuji@0 1247 This document and the information contained herein are provided on an
yuuji@0 1248 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
yuuji@0 1249 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
yuuji@0 1250 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
yuuji@0 1251 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
yuuji@0 1252 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
yuuji@0 1253 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
yuuji@0 1254
yuuji@0 1255 Intellectual Property
yuuji@0 1256
yuuji@0 1257 The IETF takes no position regarding the validity or scope of any
yuuji@0 1258 Intellectual Property Rights or other rights that might be claimed to
yuuji@0 1259 pertain to the implementation or use of the technology described in
yuuji@0 1260 this document or the extent to which any license under such rights
yuuji@0 1261 might or might not be available; nor does it represent that it has
yuuji@0 1262 made any independent effort to identify any such rights. Information
yuuji@0 1263 on the procedures with respect to rights in RFC documents can be
yuuji@0 1264 found in BCP 78 and BCP 79.
yuuji@0 1265
yuuji@0 1266 Copies of IPR disclosures made to the IETF Secretariat and any
yuuji@0 1267 assurances of licenses to be made available, or the result of an
yuuji@0 1268 attempt made to obtain a general license or permission for the use of
yuuji@0 1269 such proprietary rights by implementers or users of this
yuuji@0 1270 specification can be obtained from the IETF on-line IPR repository at
yuuji@0 1271 http://www.ietf.org/ipr.
yuuji@0 1272
yuuji@0 1273 The IETF invites any interested party to bring to its attention any
yuuji@0 1274 copyrights, patents or patent applications, or other proprietary
yuuji@0 1275 rights that may cover technology that may be required to implement
yuuji@0 1276 this standard. Please address the information to the IETF at
yuuji@0 1277 ietf-ipr@ietf.org.
yuuji@0 1278
yuuji@0 1279
yuuji@0 1280
yuuji@0 1281
yuuji@0 1282
yuuji@0 1283
yuuji@0 1284
yuuji@0 1285
yuuji@0 1286
yuuji@0 1287
yuuji@0 1288
yuuji@0 1289
yuuji@0 1290 Melnikov, et al. Standards Track [Page 23]
yuuji@0 1291

UW-IMAP'd extensions by yuuji