idnits 2.17.1 draft-ietf-qresync-rfc5162bis-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2683, but the abstract doesn't seem to directly say this. It does mention RFC2683 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2683, updated by this document, for RFC5378 checks: 1997-09-09) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 30, 2014) is 3738 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'UNSEEN 12' is mentioned on line 1985, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 1986, but not defined == Missing Reference: 'UIDNEXT 4392' is mentioned on line 952, but not defined == Missing Reference: 'HIGHESTMODSEQ 715194045007' is mentioned on line 955, but not defined == Missing Reference: 'HIGHESTMODSEQ 12111230047' is mentioned on line 490, but not defined == Missing Reference: 'MODIFIED 7' is mentioned on line 519, but not defined -- Looks like a reference, but probably isn't: '9' on line 519 == Missing Reference: 'MODIFIED 12' is mentioned on line 529, but not defined == Missing Reference: 'MODIFIED 101' is mentioned on line 622, but not defined == Missing Reference: 'MODIFIED 2' is mentioned on line 656, but not defined == Missing Reference: 'UIDNEXT 550' is mentioned on line 1221, but not defined == Missing Reference: 'HIGHESTMODSEQ 90060128194045007' is mentioned on line 1222, but not defined == Missing Reference: 'UIDVALIDITY 67890007' is mentioned on line 1369, but not defined == Missing Reference: 'UIDNEXT 30013' is mentioned on line 1370, but not defined == Missing Reference: 'HIGHESTMODSEQ 90060115205545359' is mentioned on line 1371, but not defined == Missing Reference: 'UNSEEN 7' is mentioned on line 1373, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715194045319' is mentioned on line 1588, but not defined == Missing Reference: 'HIGHESTMODSEQ 99' is mentioned on line 1909, but not defined == Missing Reference: 'MODIFIED 3' is mentioned on line 1905, but not defined == Missing Reference: 'HIGHESTMODSEQ 104' is mentioned on line 1913, but not defined == Missing Reference: 'UIDNEXT 201' is mentioned on line 1987, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715194045007' is mentioned on line 1990, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2683 ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 2 errors (**), 0 flaws (~~), 22 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode Ltd 4 Obsoletes: 4551, 5162 (if approved) D. Cridland 5 Updates: 2683 (if approved) Arcode Inc 6 Intended status: Standards Track January 30, 2014 7 Expires: August 3, 2014 9 IMAP Extensions for Conditional STORE Operation or Quick Flag Changes 10 Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization 11 (QRESYNC) 12 draft-ietf-qresync-rfc5162bis-10.txt 14 Abstract 16 Often, multiple IMAP (RFC 3501) clients need to coordinate changes to 17 a common IMAP mailbox. Examples include different clients working on 18 behalf of the same user, and multiple users accessing shared 19 mailboxes. These clients need a mechanism to efficiently synchronize 20 state changes for messages within the mailbox. 22 Initially defined in RFC 4551, The Conditional Store facility 23 provides a protected update mechanism for message state information 24 and a mechanism for requesting only changes to message state. This 25 memo updates that mechanism and obsoletes RFC 4551, based on 26 operational experience. 28 This document additionally updates another IMAP extension, Quick 29 Resynchronization, which builds on the Conditional Store extension to 30 provide an IMAP client the ability to fully resynchronize a mailbox 31 as part of the SELECT/EXAMINE command, without the need for 32 additional server-side state or client round-trips. Hence this memo 33 obsoletes RFC 5162. 35 Finally, this document also updates the line length recommendation in 36 Section 3.2.1.5 of RFC 2683. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on August 3, 2014. 55 Copyright Notice 57 Copyright (c) 2014 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 This document may contain material from IETF Documents or IETF 71 Contributions published or made publicly available before November 72 10, 2008. The person(s) controlling the copyright in some of this 73 material may not have granted the IETF Trust the right to allow 74 modifications of such material outside the IETF Standards Process. 75 Without obtaining an adequate license from the person(s) controlling 76 the copyright in such materials, this document may not be modified 77 outside the IETF Standards Process, and derivative works of it may 78 not be created outside the IETF Standards Process, except to format 79 it for publication as an RFC or to translate it into languages other 80 than English. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 85 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 86 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 5 87 3.1. CONDSTORE extension . . . . . . . . . . . . . . . . . . . 5 88 3.1.1. Advertising support for CONDSTORE . . . . . . . . . . 7 89 3.1.2. New OK Untagged Responses for SELECT and EXAMINE . . 8 90 3.1.3. STORE and UID STORE Commands . . . . . . . . . . . . 10 91 3.1.4. FETCH and UID FETCH Commands . . . . . . . . . . . . 16 92 3.1.5. MODSEQ Search Criterion in SEARCH . . . . . . . . . . 19 93 3.1.6. Modified SEARCH Untagged Response . . . . . . . . . . 20 94 3.1.7. HIGHESTMODSEQ Status Data Items . . . . . . . . . . . 20 95 3.1.8. CONDSTORE Parameter to SELECT and EXAMINE . . . . . . 21 96 3.1.9. Interaction with IMAP SORT and THREAD extensions . . 21 97 3.1.10. Interaction with IMAP ESORT and ESEARCH extensions . 22 98 3.1.11. Additional Quality-of-Implementation Issues . . . . . 22 99 3.1.12. CONDSTORE Server Implementation Considerations . . . 23 100 3.2. QRESYNC extension . . . . . . . . . . . . . . . . . . . . 24 101 3.2.1. Impact on CONDSTORE-only clients . . . . . . . . . . 24 102 3.2.2. Advertising support for QRESYNC . . . . . . . . . . . 25 103 3.2.3. Use of ENABLE . . . . . . . . . . . . . . . . . . . . 25 104 3.2.4. Additional requirements on QRESYNC servers . . . . . 26 105 3.2.5. QRESYNC Parameter to SELECT/EXAMINE . . . . . . . . . 26 106 3.2.6. VANISHED UID FETCH Modifier . . . . . . . . . . . . . 30 107 3.2.7. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 32 108 3.2.8. CLOSE Command . . . . . . . . . . . . . . . . . . . . 33 109 3.2.9. UID EXPUNGE Command . . . . . . . . . . . . . . . . . 34 110 3.2.10. VANISHED Response . . . . . . . . . . . . . . . . . . 35 111 3.2.11. CLOSED Response Code . . . . . . . . . . . . . . . . 38 112 4. Long Command Lines (Update to RFC 2683) . . . . . . . . . . . 38 113 5. QRESYNC Server Implementation Considerations . . . . . . . . 39 114 5.1. Server Implementations That Don't Store Extra State . . . 39 115 5.2. Server Implementations Storing Minimal State . . . . . . 39 116 5.3. Additional State Required on the Server . . . . . . . . . 40 117 6. Updated Synchronization Sequence . . . . . . . . . . . . . . 41 118 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 44 119 8. Security Considerations . . . . . . . . . . . . . . . . . . . 47 120 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 121 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 122 10.1. Normative References . . . . . . . . . . . . . . . . . . 48 123 10.2. Informative References . . . . . . . . . . . . . . . . . 49 124 Appendix A. Changes since RFC 4551 . . . . . . . . . . . . . . . 49 125 Appendix B. Changes since RFC 5162 . . . . . . . . . . . . . . . 50 126 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 51 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 129 1. Introduction 131 Often, multiple IMAP [RFC3501] clients need to coordinate changes to 132 a common IMAP mailbox. Examples include different clients working on 133 behalf of the same user, and client representing multiple users 134 accessing shared mailboxes. These clients need a mechanism to 135 synchronize state changes for messages within the mailbox. The 136 Conditional Store ("CONDSTORE") facility allows a client to quickly 137 resynchronize mailbox flag changes. 139 The Conditional Store facility also provides a protected update 140 mechanism for message state information that can detect and resolve 141 conflicts between multiple writing mail clients. The mechanism can 142 be used to guarantee that only one client can change message state at 143 any given time. For example, this can be used by multiple clients 144 which treat a mailbox as a message queue. 146 The Conditional Store facility is provided by associating a 147 modification sequence (mod-sequence) with every IMAP message. This 148 is updated whenever metadata (such as a message flag) is modified. 150 The CONDSTORE extension is described in more details in Section 3.1. 152 The CONDSTORE extension gives a disconnected client the ability to 153 quickly resynchronize IMAP flag changes for previously seen messages. 154 This can be done using the CHANGEDSINCE FETCH modifier once a mailbox 155 is opened. In order for the client to discover which messages have 156 been expunged, the client still has to issue a UID FETCH or a UID 157 SEARCH command. The QRESYNC ("quick resync") IMAP extension is an 158 extension to CONDSTORE that allows a reconnecting client to perform 159 full resynchronization, including discovery of expunged messages, in 160 a single round-trip. QRESYNC also introduces a new response, 161 VANISHED, that allows for a more compact representation of a list of 162 expunged messages. 164 QRESYNC can be useful for mobile clients that can experience frequent 165 disconnects caused by environmental factors (battery life, signal 166 strength, etc.). Such clients need a way to quickly reconnect to the 167 IMAP server, while minimizing delay experienced by the user as well 168 as the amount of traffic generated by resynchronization. 170 By extending the SELECT command to perform the additional 171 resynchronization, this also allows clients to reduce concurrent 172 connections to the IMAP server held purely for the sake of avoiding 173 the resynchronization. 175 The QRESYNC extension is described in more details in Section 3.2. 177 2. Requirements Notation 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in [RFC2119]. 183 In examples, "C:" and "S:" indicate lines sent by the client and 184 server respectively. If a single "C:" or "S:" label applies to 185 multiple lines, then the line breaks between those lines are for 186 editorial clarity only and are not part of the actual protocol 187 exchange. The five characters [...] means that something has been 188 elided. 190 Formal syntax is defined using ABNF [RFC5234]. 192 The term "metadata" or "metadata item" is used throughout this 193 document. It refers to any system- or user-defined keyword. If the 194 server supports IMAP ANNOTATE-EXPERIMENT-1 extension [RFC5257], then 195 metadata also includes message annotations. Future documents may 196 extend "metadata" to include other dynamic message data. 198 Some IMAP mailboxes are private, accessible only to the owning user. 199 Other mailboxes are not, either because the owner has set an Access 200 Control List [RFC4314] that permits access by other users, or because 201 it is a shared mailbox. Let's call a metadata item "shared" for the 202 mailbox if any changes to the metadata items are persistent and 203 visible to all other users accessing the mailbox. Otherwise, the 204 metadata item is called "private". Note that private metadata items 205 are still visible to all sessions accessing the mailbox as the same 206 user. Also note that different mailboxes may have different metadata 207 items as shared. 209 See Section 3.1 for the definition of a "CONDSTORE-aware client" and 210 a "CONDSTORE enabling command". 212 Understanding of the IMAP message sequence numbers and UIDs (see 213 [RFC3501], Section 2.3.1) and the EXPUNGE response (see [RFC3501], 214 Section 7.4.1) is essential when reading this document. 216 3. IMAP Protocol Changes 218 3.1. CONDSTORE extension 220 An IMAP server that supports CONDSTORE MUST associate a positive 221 unsigned 63-bit (*) value, called a modification sequence (mod- 222 sequence), with every IMAP message. This is an opaque value updated 223 by the server whenever a metadata item is modified. The server MUST 224 guarantee that each STORE command performed on the same mailbox 225 (including simultaneous stores to different metadata items from 226 different connections) will get a different mod-sequence value. 227 Also, for any two successful STORE operations performed in the same 228 session on the same mailbox, the mod-sequence of the second completed 229 operation MUST be greater than the mod-sequence of the first 230 completed. Note that the latter rule disallows the direct use of the 231 system clock as a mod-sequence, because if system time changes (e.g., 232 an NTP [NTP] client adjusting the time), the next generated value 233 might be less than the previous one. 235 (*) Note: RFC 4551 defined mod-sequences as unsigned 64-bit values. 236 In order to make implementations on various platforms (such as Java) 237 easier, this version of the document redefines them as unsigned 238 63-bit values. 240 These rules allow a client to list all metadata changes since a well 241 known point in time, as well as to perform conditional metadata 242 modifications based on an assumption that metadata state hasn't 243 changed for a particular message. 245 In particular, mod-sequences allow a client that supports the 246 CONDSTORE extension to determine if a message metadata has changed 247 since some known moment. Whenever the state of a flag changes (i.e., 248 the flag is added where previously it wasn't set, or the flag is 249 removed and before it was set) the value of the modification sequence 250 for the message MUST be updated. Setting a flag that is already set, 251 or clearing a flag that is not set, SHOULD NOT change the mod- 252 sequence. 254 When a message is appended to a mailbox (via the IMAP APPEND command, 255 COPY to the mailbox, or using an external mechanism) the server 256 generates a new modification sequence that is higher than the highest 257 modification sequence of all messages in the mailbox and assigns it 258 to the appended message. 260 The server MAY store separate (per-message) modification sequence 261 values for different metadata items. If the server does so, per- 262 message mod-sequence is the highest mod-sequence of all metadata 263 items accessible to the currently logged in user for the specified 264 message. 266 The server that supports CONDSTORE is not required to be able to 267 store mod-sequences for every available mailbox. Section 3.1.2.2 268 describes how the server may act if a particular mailbox doesn't 269 support the persistent storage of mod-sequences. 271 CONDSTORE makes the following changes to the IMAP4 protocol: 273 a. adds UNCHANGEDSINCE STORE modifier. 275 b. adds the MODIFIED response code which is used with an OK response 276 to the STORE command. (It can also be used in a NO response.) 278 c. adds a new MODSEQ message data item for use with the FETCH 279 command. 281 d. adds CHANGEDSINCE FETCH modifier. 283 e. adds a new MODSEQ search criterion. 285 f. extends the syntax of untagged SEARCH and ESEARCH responses to 286 include mod-sequence. 288 g. adds new OK untagged responses (HIGHESTMODSEQ and NOMODSEQ) for 289 the SELECT and EXAMINE commands. 291 h. defines an additional CONDSTORE parameter to SELECT/EXAMINE 292 commands. 294 i. adds the HIGHESTMODSEQ status data item to the STATUS command. 296 A client supporting CONDSTORE extension indicates its willingness to 297 receive mod-sequence updates in all untagged FETCH responses by 298 issuing one of the following, which are called "CONDSTORE enabling 299 commands": 301 o a SELECT or EXAMINE command with the CONDSTORE parameter, 303 o a STATUS (HIGHESTMODSEQ) command, 305 o a FETCH or SEARCH command that includes the MODSEQ message data 306 item, 308 o a FETCH command with the CHANGEDSINCE modifier, 310 o a STORE command with the UNCHANGEDSINCE modifier, or 312 o an ENABLE command containing "CONDSTORE" as one of the parameters. 313 (This option only applies when the client is communicating with a 314 server that also implements the ENABLE extension [RFC5161].) 316 Once a client issues a CONDSTORE enabling command, it has announced 317 itself as a "CONDSTORE-aware client". The server MUST then include 318 mod-sequence data in all subsequent untagged FETCH responses (until 319 the connection is closed), whether they were caused by a regular 320 STORE, a STORE with UNCHANGEDSINCE modifier, or an external agent. 322 A future extension to this document may extend the list of CONDSTORE 323 enabling commands. A first CONDSTORE enabling command executed in 324 the session with a mailbox selected MUST cause the server to return 325 HIGHESTMODSEQ (Section 3.1.2.1) for the mailbox (if any is selected), 326 unless the server has sent NOMODSEQ (Section 3.1.2.2) response code 327 when the currently selected mailbox was selected. 329 3.1.1. Advertising support for CONDSTORE 331 The Conditional STORE extension is present in any IMAP4 332 implementation that returns "CONDSTORE" as one of the supported 333 capabilities in the CAPABILITY command response. 335 3.1.2. New OK Untagged Responses for SELECT and EXAMINE 337 This document adds two new response codes, HIGHESTMODSEQ and 338 NOMODSEQ. One of these two response codes MUST be returned in an OK 339 untagged response for any successful SELECT/EXAMINE command issued 340 after a CONDSTORE enabling command. 342 When opening a mailbox, the server must check if the mailbox supports 343 the persistent storage of mod-sequences. If the mailbox supports the 344 persistent storage of mod-sequences and the mailbox open operation 345 succeeds, the server MUST send an OK untagged response including 346 HIGHESTMODSEQ response code. If the persistent storage for the 347 mailbox is not supported, the server MUST send an OK untagged 348 response including NOMODSEQ response code instead. 350 3.1.2.1. HIGHESTMODSEQ Response Code 352 This document adds a new response code that is returned in an OK 353 untagged response for the SELECT and EXAMINE commands. Once a 354 CONDSTORE enabling command is issued a server supporting the 355 persistent storage of mod-sequences for the mailbox MUST send an OK 356 untagged response including HIGHESTMODSEQ response code with every 357 successful SELECT or EXAMINE command: 359 OK [HIGHESTMODSEQ ] 361 where is the highest mod-sequence value of 362 all messages in the mailbox. When the server changes UIDVALIDITY 363 for a mailbox, it doesn't have to keep the same HIGHESTMODSEQ for 364 the mailbox. 366 Note that some existing CONDSTORE servers don't start tracking mod- 367 sequences or don't report them until after a CONDSTORE enabling 368 command is issued. Because of that, client wishing to receive 369 HIGHESTMODSEQ/NOMODSEQ information must first send a CONDSTORE 370 enabling command, for example by using SELECT/EXAMINE with CONDSTORE 371 parameter (see Section 3.1.8). 373 A disconnected client can use the value of HIGHESTMODSEQ to check if 374 it has to refetch metadata from the server. If the UIDVALIDITY value 375 has changed for the selected mailbox, the client MUST delete the 376 cached value of HIGHESTMODSEQ. If UIDVALIDITY for the mailbox is the 377 same, and if the HIGHESTMODSEQ value stored in the client's cache is 378 less than the value returned by the server, then some metadata items 379 on the server have changed since the last synchronization, and the 380 client needs to update its cache. The client MAY use SEARCH MODSEQ 381 (Section 3.1.5) to find out exactly which metadata items have 382 changed. Alternatively, the client MAY issue FETCH with the 383 CHANGEDSINCE modifier (Section 3.1.4.1) in order to fetch data for 384 all messages that have metadata items changed since some known 385 modification sequence. 387 C: A142 SELECT INBOX 388 S: * 172 EXISTS 389 S: * 1 RECENT 390 S: * OK [UNSEEN 12] Message 12 is first unseen 391 S: * OK [UIDVALIDITY 3857529045] UIDs valid 392 S: * OK [UIDNEXT 4392] Predicted next UID 393 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 394 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 395 S: * OK [HIGHESTMODSEQ 715194045007] 396 S: A142 OK [READ-WRITE] SELECT completed 398 Example 1 400 3.1.2.2. NOMODSEQ Response Code 402 Once a CONDSTORE enabling command is issued a server that doesn't 403 support the persistent storage of mod-sequences for the mailbox MUST 404 send an OK untagged response including NOMODSEQ response code with 405 every successful SELECT or EXAMINE command. Note that some existing 406 CONDSTORE servers don't return NOMODSEQ until after a CONDSTORE 407 enabling command is issued. Because of that, client wishing to 408 receive HIGHESTMODSEQ/NOMODSEQ information must first send a 409 CONDSTORE enabling command, for example by using SELECT/EXAMINE with 410 CONDSTORE parameter (see Section 3.1.8). 412 A server that returned NOMODSEQ response code for a mailbox MUST 413 reject (with a tagged BAD response) any of the following commands 414 while the mailbox remains selected: 416 o a FETCH command with the CHANGEDSINCE modifier, 418 o a FETCH or SEARCH command that includes the MODSEQ message data 419 item, or 421 o a STORE command with the UNCHANGEDSINCE modifier 422 C: A142 SELECT INBOX 423 S: * 172 EXISTS 424 S: * 1 RECENT 425 S: * OK [UNSEEN 12] Message 12 is first unseen 426 S: * OK [UIDVALIDITY 3857529045] UIDs valid 427 S: * OK [UIDNEXT 4392] Predicted next UID 428 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 429 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 430 S: * OK [NOMODSEQ] Sorry, this mailbox format doesn't support 431 modsequences 432 S: A142 OK [READ-WRITE] SELECT completed 434 Example 2 436 3.1.3. STORE and UID STORE Commands 438 This document defines the following STORE modifier (see Section 2.5 439 of [RFC4466]): 441 UNCHANGEDSINCE 443 For each message specified in the message set, the server performs 444 the following. If the mod-sequence of every metadata item of the 445 message affected by the STORE/UID STORE is equal to or less than the 446 specified UNCHANGEDSINCE value, then the requested operation (as 447 described by the message data item) is performed. If the operation 448 is successful, the server MUST update the mod-sequence attribute of 449 the message. An untagged FETCH response MUST be sent, even if the 450 .SILENT suffix is specified, and the response MUST include the MODSEQ 451 message data item. This is required to update the client's cache 452 with the correct mod-sequence values. See Section 3.1.4.2 for more 453 details. 455 However, if the mod-sequence of any metadata item of the message is 456 greater than the specified UNCHANGEDSINCE value, then the requested 457 operation MUST NOT be performed. In this case, the mod-sequence 458 attribute of the message is not updated, and the message number (or 459 unique identifier in the case of the UID STORE command) is added to 460 the list of messages that failed the UNCHANGEDSINCE test. 462 When the server finishes performing the operation on all the messages 463 in the message set, it checks for a non-empty list of messages that 464 failed the UNCHANGEDSINCE test. If this list is non-empty, the 465 server MUST return in the tagged response a MODIFIED response code. 466 The MODIFIED response code includes the message set (for STORE) or 467 set of UIDs (for UID STORE) of all messages that failed the 468 UNCHANGEDSINCE test. 470 All messages pass the UNCHANGEDSINCE test. 472 C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045) 473 +FLAGS.SILENT (\Deleted) 474 S: * 1 FETCH (UID 4 MODSEQ (12121231000)) 475 S: * 2 FETCH (UID 6 MODSEQ (12121230852)) 476 S: * 4 FETCH (UID 8 MODSEQ (12121230956)) 477 S: a103 OK Conditional Store completed 479 Example 3 481 C: a104 STORE * (UNCHANGEDSINCE 12121230045) +FLAGS.SILENT 482 (\Deleted $Processed) 483 S: * 50 FETCH (MODSEQ (12111230047)) 484 S: a104 OK Store (conditional) completed 486 Example 4 488 C: c101 STORE 50 (UNCHANGEDSINCE 12121230045) -FLAGS.SILENT 489 (\Deleted) 490 S: * OK [HIGHESTMODSEQ 12111230047] 491 S: * 50 FETCH (MODSEQ (12111230048)) 492 S: c101 OK Store (conditional) completed 494 HIGHESTMODSEQ response code was sent by the server presumably because 495 this was the first CONDSTORE enabling command. 497 Example 5 499 The failure of the conditional STORE operation for any particular 500 message or messages (7 in this example) does not stop the server from 501 finding all messages that fail the UNCHANGEDSINCE test. All such 502 messages are returned in the MODIFIED response code. 504 C: d105 STORE 7,5,9 (UNCHANGEDSINCE 320162338) 505 +FLAGS.SILENT (\Deleted) 506 S: * 5 FETCH (MODSEQ (320162350)) 507 S: d105 OK [MODIFIED 7,9] Conditional STORE failed 509 Example 6 511 Same as above, but the server follows the SHOULD recommendation in 512 Section 6.4.6 of [RFC3501]. 514 C: d105 STORE 7,5,9 (UNCHANGEDSINCE 320162338) 515 +FLAGS.SILENT (\Deleted) 516 S: * 7 FETCH (MODSEQ (320162342) FLAGS (\Seen \Deleted)) 517 S: * 5 FETCH (MODSEQ (320162350)) 518 S: * 9 FETCH (MODSEQ (320162349) FLAGS (\Answered)) 519 S: d105 OK [MODIFIED 7,9] Conditional STORE failed 521 Use of UNCHANGEDSINCE with a modification sequence of 0 always fails 522 if the metadata item exists. A system flag MUST always be considered 523 existent, whether it was set or not. 525 Example 7 527 C: a102 STORE 12 (UNCHANGEDSINCE 0) 528 +FLAGS.SILENT ($MDNSent) 529 S: a102 OK [MODIFIED 12] Conditional STORE failed 531 The client has tested the presence of the $MDNSent user-defined 532 keyword. 534 Example 8 536 Note: A client trying to make an atomic change to the state of a 537 particular metadata item (or a set of metadata items) MUST prepared 538 to deal with the case when the server returns the MODIFIED response 539 code if the state of the metadata item being watched hasn't changed 540 (but the state of some other metadata item has). This is necessary, 541 because some servers don't store separate mod-sequences for different 542 metadata items. However, a server implementation SHOULD avoid 543 generating spurious MODIFIED responses for +FLAGS/-FLAGS STORE 544 operations, even when the server stores a single mod-sequence per 545 message. Section 3.1.12 describes how this can be achieved. 547 Unless the server has included an unsolicited FETCH to update 548 client's knowledge about messages that have failed the UNCHANGEDSINCE 549 test, upon receipt of the MODIFIED response code the client SHOULD 550 try to figure out if the required metadata items have indeed changed 551 by issuing FETCH or NOOP command. It is RECOMMENDED that the server 552 avoids the need for the client to do that by sending an unsolicited 553 FETCH response (Examples 9 and 10). 555 If the required metadata items haven't changed, the client SHOULD 556 retry the command with the new mod-sequence. The client needs to 557 allow for a reasonable number of retries (at least 2). 559 In the example below, the server returns the MODIFIED response code 560 without sending information describing why the STORE UNCHANGEDSINCE 561 operation has failed. 563 C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) 564 +FLAGS.SILENT ($Processed) 565 S: * 100 FETCH (MODSEQ (303181230852)) 566 S: * 102 FETCH (MODSEQ (303181230852)) 567 ... 568 S: * 150 FETCH (MODSEQ (303181230852)) 569 S: a106 OK [MODIFIED 101] Conditional STORE failed 571 The flag $Processed was set on the message 101... 573 C: a107 NOOP 574 S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed)) 575 S: a107 OK 577 Example 9 579 Or the flag hasn't changed, but another has (note that this server 580 behaviour is discouraged. Server implementers should also see 581 Section 3.1.12)... 583 C: b107 NOOP 584 S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered)) 585 S: b107 OK 587 ...and the client retries the operation for the message 101 with 588 the updated UNCHANGEDSINCE value 590 C: b108 STORE 101 (UNCHANGEDSINCE 303011130956) 591 +FLAGS.SILENT ($Processed) 592 S: * 101 FETCH (MODSEQ (303181230852)) 593 S: b108 OK Conditional Store completed 594 Same as above, but the server avoids the need for the client to poll 595 for changes. 597 The flag $Processed was set on the message 101 by another 598 client... 600 C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) 601 +FLAGS.SILENT ($Processed) 602 S: * 100 FETCH (MODSEQ (303181230852)) 603 S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed)) 604 S: * 102 FETCH (MODSEQ (303181230852)) 605 ... 606 S: * 150 FETCH (MODSEQ (303181230852)) 607 S: a106 OK [MODIFIED 101] Conditional STORE failed 609 Example 10 611 Or the flag hasn't changed, but another has (note that this server 612 behaviour is discouraged. Server implementers should also see 613 Section 3.1.12)... 615 C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) 616 +FLAGS.SILENT ($Processed) 617 S: * 100 FETCH (MODSEQ (303181230852)) 618 S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered)) 619 S: * 102 FETCH (MODSEQ (303181230852)) 620 ... 621 S: * 150 FETCH (MODSEQ (303181230852)) 622 S: a106 OK [MODIFIED 101] Conditional STORE failed 624 ...and the client retries the operation for the message 101 with 625 the updated UNCHANGEDSINCE value 627 C: b108 STORE 101 (UNCHANGEDSINCE 303011130956) 628 +FLAGS.SILENT ($Processed) 629 S: * 101 FETCH (MODSEQ (303181230852)) 630 S: b108 OK Conditional Store completed 632 Or the flag hasn't changed, but another has (nice server behaviour. 633 Server implementers should also see Section 3.1.12)... 635 C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) 636 +FLAGS.SILENT ($Processed) 637 S: * 100 FETCH (MODSEQ (303181230852)) 638 S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed \Deleted 639 \Answered)) 640 S: * 102 FETCH (MODSEQ (303181230852)) 641 ... 642 S: * 150 FETCH (MODSEQ (303181230852)) 643 S: a106 OK Conditional STORE completed 645 The following example is based on the example from the Section 4.2.3 646 of [RFC2180] and demonstrates that the MODIFIED response code MAY be 647 also returned in the tagged NO response. 649 Client tries to conditionally STORE flags on a mixture of expunged 650 and non-expunged messages; one message fails the UNCHANGEDSINCE 651 test. 653 C: B001 STORE 1:7 (UNCHANGEDSINCE 320172338) +FLAGS (\SEEN) 654 S: * 1 FETCH (MODSEQ (320172342) FLAGS (\SEEN)) 655 S: * 3 FETCH (MODSEQ (320172342) FLAGS (\SEEN)) 656 S: B001 NO [MODIFIED 2] Some of the messages no longer exist. 658 C: B002 NOOP 659 S: * 4 EXPUNGE 660 S: * 4 EXPUNGE 661 S: * 4 EXPUNGE 662 S: * 4 EXPUNGE 663 S: * 2 FETCH (MODSEQ (320172340) FLAGS (\Deleted \Answered)) 664 S: B002 OK NOOP Completed. 666 By receiving FETCH responses for messages 1 and 3, and EXPUNGE 667 responses that indicate that messages 4 through 7 have been 668 expunged, the client retries the operation only for the message 2. 669 The updated UNCHANGEDSINCE value is used. 671 C: b003 STORE 2 (UNCHANGEDSINCE 320172340) +FLAGS (\Seen) 672 S: * 2 FETCH (MODSEQ (320180050) FLAGS (\SEEN \Flagged)) 673 S: b003 OK Conditional Store completed 675 Example 11 677 Note: If a message is specified multiple times in the message set, 678 and the server doesn't internally eliminate duplicates from the 679 message set, it MUST NOT fail the conditional STORE operation for the 680 second (or subsequent) occurrence of the message if the operation 681 completed successfully for the first occurrence. For example, if the 682 client specifies: 684 e105 STORE 7,3:9 (UNCHANGEDSINCE 12121230045) +FLAGS.SILENT 685 (\Deleted) 687 the server must not fail the operation for message 7 as part of 688 processing "3:9" if it succeeded when message 7 was processed the 689 first time. 691 As specified in Section 1, once the client specified the 692 UNCHANGEDSINCE modifier in a STORE command, the server starts 693 including the MODSEQ FETCH response data items in all subsequent 694 unsolicited FETCH responses. 696 This document also changes the behaviour of the server when it has 697 performed a STORE or UID STORE command and the UNCHANGEDSINCE 698 modifier is not specified. If the operation is successful for a 699 message, the server MUST update the mod-sequence attribute of the 700 message. The server is REQUIRED to include the mod-sequence value 701 whenever it decides to send the unsolicited FETCH response to all 702 CONDSTORE-aware clients that have opened the mailbox containing the 703 message. 705 Server implementers should also see Section 3.1.11 for additional 706 quality of implementation issues related to the STORE command. 708 3.1.4. FETCH and UID FETCH Commands 710 3.1.4.1. CHANGEDSINCE FETCH Modifier 712 This document defines the following FETCH modifier (see Section 2.4 713 of [RFC4466]): 715 CHANGEDSINCE CHANGEDSINCE FETCH modifier allows the 716 client to further subset the list of messages described by 717 sequence set. The information described by message data items is 718 only returned for messages that have mod-sequence bigger than 719 . 721 When CHANGEDSINCE FETCH modifier is specified, it implicitly adds 722 MODSEQ FETCH message data item (Section 3.1.4.2). 724 C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345) 725 S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen)) 726 S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted)) 727 S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk 728 $MDNSent)) 729 S: s100 OK FETCH completed 731 Example 12 733 3.1.4.2. MODSEQ Message Data Item in FETCH Command 735 CONDSTORE adds a MODSEQ message data item to the FETCH command. The 736 MODSEQ message data item allows clients to retrieve mod-sequence 737 values for a range of messages in the currently selected mailbox. 739 As specified in Section 3.1, once the client has specified the MODSEQ 740 message data item in a FETCH request, the server starts including the 741 MODSEQ FETCH response data items in all subsequent unsolicited FETCH 742 responses. 744 Syntax: MODSEQ 746 The MODSEQ message data item causes the server to return MODSEQ 747 FETCH response data items. 749 Syntax: MODSEQ ( ) 751 MODSEQ response data items contain per-message mod-sequences. 753 The MODSEQ response data item is returned if the client issued 754 FETCH with MODSEQ message data item. It also allows the server to 755 notify the client about mod-sequence changes caused by conditional 756 STOREs (Section 3.1.3) and/or changes caused by external sources. 758 C: a FETCH 1:3 (MODSEQ) 759 S: * 1 FETCH (MODSEQ (624140003)) 760 S: * 2 FETCH (MODSEQ (624140007)) 761 S: * 3 FETCH (MODSEQ (624140005)) 762 S: a OK Fetch complete 764 In this example, the client requests per-message mod-sequences for a 765 set of messages. 767 Example 13 769 Servers that only support the CONDSTORE extension (and not QRESYNC) 770 SHOULD comply with requirements from Section 3.2.4. 772 When a flag for a message is modified in a different session, the 773 server sends an unsolicited FETCH response containing the mod- 774 sequence for the message, as demonstrated in Example 14. Note that 775 when the server also supports the QRESYNC extension (Section 3.2.3) 776 and a "CONDSTORE enabling command" has been issued, all FETCH 777 responses in the Example 14 must also include UID FETCH items as 778 prescribed by Section 3.2.4. 780 (Session 1, authenticated as a user "alex"). The user adds a 781 shared flag \Deleted: 783 C: A142 SELECT INBOX 784 ... 785 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 786 S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \*)] Limited 787 ... 788 C: A160 STORE 7 +FLAGS.SILENT (\Deleted) 789 S: * 7 FETCH (MODSEQ (2121231000)) 790 S: A160 OK Store completed 792 (Session 2, also authenticated as the user "alex"). Any changes 793 to flags are always reported to all sessions authenticated as the 794 same user as in the session 1. 796 C: C180 NOOP 797 S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (12121231000)) 798 S: C180 OK Noop completed 800 (Session 3, authenticated as a user "andrew"). As \Deleted is a 801 shared flag, changes in session 1 are also reported in session 3: 803 C: D210 NOOP 804 S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (12121231000)) 805 S: D210 OK Noop completed 807 The user modifies a private flag \Seen in session 1... 809 C: A240 STORE 7 +FLAGS.SILENT (\Seen) 810 S: * 7 FETCH (MODSEQ (12121231777)) 811 S: A240 OK Store completed 813 ...which is only reported in session 2... 815 C: C270 NOOP 816 S: * 7 FETCH (FLAGS (\Deleted \Answered \Seen) MODSEQ 817 (12121231777)) 818 S: C270 OK Noop completed 820 ...but not in session 3. 822 C: D300 NOOP 823 S: D300 OK Noop completed 825 And finally, the user removes flags \Answered (shared) and \Seen 826 (private) in session 1. 828 C: A330 STORE 7 -FLAGS.SILENT (\Answered \Seen) 829 S: * 7 FETCH (MODSEQ (12121245160)) 830 S: A330 OK Store completed 832 Both changes are reported in the session 2... 834 C: C360 NOOP 835 S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160)) 836 S: C360 OK Noop completed 838 ...and only changes to shared flags are reported in session 3. 840 C: D390 NOOP 841 S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160)) 842 S: D390 OK Noop completed 844 Example 14 846 Server implementers should also see Section 3.1.11 for additional 847 quality of implementation issues related to the FETCH command. 849 3.1.5. MODSEQ Search Criterion in SEARCH 851 The MODSEQ criterion for the SEARCH (or UID SEARCH) command allows a 852 client to search for the metadata items that were modified since a 853 specified moment. 855 Syntax: MODSEQ [ ] 857 Messages that have modification values that are equal to or 858 greater than . This allows a client, for 859 example, to find out which messages contain metadata items that 860 have changed since the last time it updated its disconnected 861 cache. The client may also specify (name of metadata 862 item) and (type of metadata item) before . can be one of "shared", "priv" 864 (private), or "all". The last means that the server MUST use the 865 biggest value among "priv" and "shared" mod-sequences for the 866 metadata item. If the server doesn't store separate mod-sequences 867 for different metadata items, it MUST ignore and 868 . Otherwise, the server should use them to narrow 869 down the search. 871 For a flag , the corresponding has a form " 872 /flags/" as defined in [RFC4466]. Note that the leading 873 "\" character that denotes a system flag has to be escaped as per 874 Section 4.3 of [RFC3501], as uses the syntax for 875 quoted strings (see the examples below). 877 If client specifies a MODSEQ criterion in a SEARCH (or UID SEARCH) 878 command and the server returns a non-empty SEARCH result, the server 879 MUST also append (to the end of the untagged SEARCH response) the 880 highest mod-sequence for all messages being returned. See also 881 Section 3.1.6. Note that other IMAP extensions such as ESEARCH 882 [RFC4731] can override this requirement (see Section 3.1.10 for more 883 details.) 885 C: a SEARCH MODSEQ "/flags/\\draft" all 620162338 886 S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 917162500) 887 S: a OK Search complete 889 In the above example, the message numbers of any messages having a 890 mod-sequence equal to or greater than 620162338 for the "\Draft" flag 891 are returned in the search results. 893 Example 15 895 C: t SEARCH OR NOT MODSEQ 720162338 LARGER 50000 896 S: * SEARCH 897 S: t OK Search complete, nothing found 899 Example 16 901 3.1.6. Modified SEARCH Untagged Response 903 Data: zero or more numbers 904 mod-sequence value (omitted if no match) 906 This document extends syntax of the untagged SEARCH response to 907 include the highest mod-sequence for all messages being returned. 909 If a client specifies a MODSEQ criterion in a SEARCH (or UID SEARCH) 910 command and the server returns a non-empty SEARCH result, the server 911 MUST also append (to the end of the untagged SEARCH response) the 912 highest mod-sequence for all messages being returned. See 913 Section 3.1.5 for examples. 915 3.1.7. HIGHESTMODSEQ Status Data Items 917 This document defines a new status data item: 919 HIGHESTMODSEQ The highest mod-sequence value of all messages in the 920 mailbox. This is the same value that is returned by the server in 921 the HIGHESTMODSEQ response code in an OK untagged response (see 922 Section 3.1.2.1). If the server doesn't support the persistent 923 storage of mod-sequences for the mailbox (see Section 3.1.2.2), 924 the server MUST return 0 as the value of HIGHESTMODSEQ status data 925 item. 927 C: A042 STATUS blurdybloop (UIDNEXT MESSAGES HIGHESTMODSEQ) 928 S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292 929 HIGHESTMODSEQ 7011231777) 930 S: A042 OK STATUS completed 932 Example 17 934 3.1.8. CONDSTORE Parameter to SELECT and EXAMINE 936 The CONDSTORE extension defines a single optional select parameter, 937 "CONDSTORE", which tells the server that it MUST include the MODSEQ 938 FETCH response data items in all subsequent unsolicited FETCH 939 responses. 941 The CONDSTORE parameter to SELECT/EXAMINE helps avoid a race 942 condition that might arise when one or more metadata items are 943 modified in another session after the server has sent the 944 HIGHESTMODSEQ response code and before the client was able to issue a 945 CONDSTORE enabling command. 947 C: A142 SELECT INBOX (CONDSTORE) 948 S: * 172 EXISTS 949 S: * 1 RECENT 950 S: * OK [UNSEEN 12] Message 12 is first unseen 951 S: * OK [UIDVALIDITY 3857529045] UIDs valid 952 S: * OK [UIDNEXT 4392] Predicted next UID 953 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 954 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 955 S: * OK [HIGHESTMODSEQ 715194045007] 956 S: A142 OK [READ-WRITE] SELECT completed, CONDSTORE is now enabled 958 Example 18 960 3.1.9. Interaction with IMAP SORT and THREAD extensions 962 MODSEQ Search Criterion (see Section 3.1.5) causes modifications to 963 SORT [RFC5256] responses similar to modifications to SEARCH responses 964 defined in Section 3.1.6: 966 SORT response Data: zero or more numbers 967 mod-sequence value (omitted if no match) 969 This document extends syntax of the untagged SORT response to include 970 the highest mod-sequence for all messages being returned. 972 If a client specifies a MODSEQ criterion in a SORT (or UID SORT) 973 command and the server returns a non-empty SORT result, the server 974 MUST also append (to the end of the untagged SORT response) the 975 highest mod-sequence for all messages being returned. Note that 976 other IMAP extensions such as ESORT [RFC5267] can override this 977 requirement (see Section 3.1.10 for more details.) 979 THREAD commands which include a MODSEQ Search Criterion return THREAD 980 responses as specified in [RFC5256], i.e. THREAD responses are 981 unchanged by the CONDSTORE extension. 983 3.1.10. Interaction with IMAP ESORT and ESEARCH extensions 985 If a client specifies a MODSEQ criterion in an extended SEARCH (or 986 extended UID SEARCH) [RFC4731] command and the server returns a non- 987 empty SEARCH result, the server MUST return the ESEARCH response 988 containing the MODSEQ result option as defined in Section 3.2 of 989 [RFC4731]. 991 C: a SEARCH RETURN (ALL) MODSEQ 1234 992 S: * ESEARCH (TAG "a") ALL 1:3,5 MODSEQ 1236 993 S: a OK Extended SEARCH completed 995 Example 19 997 If a client specifies a MODSEQ criterion in an extended SORT (or 998 extended UID SORT) [RFC5267] command and the server returns a non- 999 empty SORT result, the server MUST return the ESEARCH response 1000 containing the MODSEQ result option defined in Section 3.2 of 1001 [RFC4731]. 1003 C: a SORT RETURN (ALL) (DATE) UTF-8 MODSEQ 1234 1004 S: * ESEARCH (TAG "a") ALL 5,3,2,1 MODSEQ 1236 1005 S: a OK Extended SORT completed 1007 Example 20 1009 3.1.11. Additional Quality-of-Implementation Issues 1011 Server implementations should follow the following rule, which 1012 applies to any successfully completed STORE/UID STORE (with and 1013 without UNCHANGEDSINCE modifier), as well as to a FETCH command that 1014 implicitly sets \Seen flag: 1016 Adding the flag when it is already present or removing when it is 1017 not present SHOULD NOT change the mod-sequence. 1019 This will prevent spurious client synchronization requests. 1021 However, note that client implementers MUST NOT rely on this server 1022 behavior. A client can't distinguish between the case when a server 1023 has violated the SHOULD mentioned above, and that when one or more 1024 clients set and unset (or unset and set) the flag in another session. 1026 3.1.12. CONDSTORE Server Implementation Considerations 1028 This section describes how a server implementation that doesn't store 1029 separate per-metadata mod-sequences for different metadata items can 1030 avoid sending the MODIFIED response to any of the following 1031 conditional STORE operations: 1033 +FLAGS 1035 -FLAGS 1037 +FLAGS.SILENT 1039 -FLAGS.SILENT 1041 Note that the optimization described in this section can't be 1042 performed in case of a conditional STORE FLAGS (without "+" or "-") 1043 operation. 1045 Let's use the following example. The client has issued 1047 C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) 1048 +FLAGS.SILENT ($Processed) 1050 When the server receives the command and parses it successfully, it 1051 iterates through the message set and tries to execute the conditional 1052 STORE command for each message. 1054 Each server internally works as a client, i.e., it has to cache the 1055 current state of all IMAP flags as it is known to the client. In 1056 order to report flag changes to the client, the server compares the 1057 cached values with the values in its database for IMAP flags. 1059 Imagine that another client has changed the state of a flag \Deleted 1060 on the message 101 and that the change updated the mod-sequence for 1061 the message. The server knows that the mod-sequence for the mailbox 1062 has changed; however, it also knows that: 1064 a. the client is not interested in \Deleted flag, as it hasn't 1065 included it in +FLAGS.SILENT operation; and 1067 b. the state of the flag $Processed hasn't changed (the server can 1068 determine this by comparing cached flag state with the state of 1069 the flag in the database). 1071 Therefore, the server doesn't have to report MODIFIED to the client. 1072 Instead, the server may set $Processed flag, update the mod-sequence 1073 for the message 101 once again and send an untagged FETCH response 1074 with new mod-sequence and flags: 1076 S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed \Deleted 1077 \Answered)) 1079 See also Section 3.1.11 for additional quality-of-implementation 1080 issues. 1082 3.2. QRESYNC extension 1084 All protocol changes and requirements specified for the CONDSTORE 1085 extension are also a part of the QRESYNC extension. 1087 The QRESYNC extension puts additional requirements on a server 1088 implementing the CONDSTORE extension. Each mailbox that supports 1089 persistent storage of mod-sequences, i.e., for which the server would 1090 send a HIGHESTMODSEQ untagged OK response code on a successful SELECT 1091 /EXAMINE, MUST increment the per-mailbox mod-sequence when one or 1092 more messages are expunged due to EXPUNGE, UID EXPUNGE, CLOSE or MOVE 1093 [RFC6851]; the server MUST associate the incremented mod-sequence 1094 with the UIDs of the expunged messages. Additionally, if the server 1095 also supports the IMAP METADATA extension [RFC5464], it MUST 1096 increment the per-mailbox mod-sequence when SETMETADATA successfully 1097 changes an annotation on the corresponding mailbox. 1099 A server implementing QRESYNC MUST send untagged events to a client 1100 in a way that the client doesn't lose any changes in case of 1101 connectivity loss. In particular this means that if the server sends 1102 MODSEQ FETCH data items while EXPUNGE (or VANISHED) replies with 1103 lower mod-sequences are being delayed, the server MUST send 1104 HIGHESTMODSEQ response code with a lower value than the EXPUNGE's 1105 mod-sequence. See example in Section 6. 1107 3.2.1. Impact on CONDSTORE-only clients 1109 A client that supports CONDSTORE but not QRESYNC might resynchronize 1110 a mailbox and discover that its HIGHESTMODSEQ has increased from the 1111 value cached by the client. If the increase is only due to messages 1112 having been expunged since the client last synchronized, the client 1113 is likely to send a FETCH ... CHANGEDSINCE command that returns no 1114 data. Thus, a client that supports CONDSTORE but not QRESYNC might 1115 incur a penalty of an unneeded round-trip when resynchronizing some 1116 mailboxes (those that have had messages expunged but no flag changes 1117 since the last synchronization). 1119 This extra round-trip is only incurred by clients that support 1120 CONDSTORE but not QRESYNC, and only when a mailbox has had messages 1121 expunged but no flag changes to non-expunged messages. Since 1122 CONDSTORE is a relatively new extension, it is strongly encouraged 1123 that clients that support it also support QRESYNC. 1125 3.2.2. Advertising support for QRESYNC 1127 The quick resync IMAP extension is present if an IMAP4 server returns 1128 "QRESYNC" as one of the supported capabilities to the CAPABILITY 1129 command. 1131 For compatibility with clients that only support the CONDSTORE IMAP 1132 extension, servers SHOULD also advertise "CONDSTORE" in the 1133 CAPABILITY response. 1135 3.2.3. Use of ENABLE 1137 Servers supporting QRESYNC MUST implement and advertise support for 1138 the ENABLE [RFC5161] IMAP extension. Also, the presence of the 1139 "QRESYNC" capability implies support for the CONDSTORE IMAP extension 1140 even if the "CONDSTORE" capability isn't advertised. A server 1141 compliant with this specification is REQUIRED to support "ENABLE 1142 QRESYNC" and "ENABLE QRESYNC CONDSTORE" (which are "CONDSTORE 1143 enabling commands", see Section 3.1), and have identical results. 1144 Note that the order of parameters is not significant), but there is 1145 no requirement for a compliant server to support "ENABLE CONDSTORE" 1146 by itself. The "ENABLE QRESYNC"/"ENABLE QRESYNC CONDSTORE" command 1147 also tells the server that it MUST start sending VANISHED responses 1148 (see Section 3.2.10) instead of EXPUNGE responses for all mailboxes 1149 for which the server doesn't return the NOMODSEQ response code. This 1150 change remains in effect until the connection is closed. 1152 A client making use of QRESYNC MUST issue "ENABLE QRESYNC" once it is 1153 authenticated. A server MUST respond with a tagged BAD response if 1154 the QRESYNC parameter to the SELECT/EXAMINE command or the VANISHED 1155 UID FETCH modifier is specified and the client hasn't issued "ENABLE 1156 QRESYNC", or the server has not positively responded (in the current 1157 connection) to that command with the untagged ENABLED response 1158 containing QRESYNC. 1160 3.2.4. Additional requirements on QRESYNC servers 1162 Once a "CONDSTORE enabling command" is issued by the client, the 1163 server MUST automatically include both UID and mod-sequence data in 1164 all subsequent untagged FETCH responses (until the connection is 1165 closed), whether they were caused by a regular STORE/UID STORE, a 1166 STORE/UID STORE with UNCHANGEDSINCE modifier, FETCH/UID FETCH that 1167 implicitly set \Seen flag or an external agent. Note that this rule 1168 doesn't affect untagged FETCH responses caused by a FETCH command 1169 that doesn't include UID and/or MODSEQ FETCH data item (and doesn't 1170 implicitly set \Seen flag), or UID FETCH without the MODSEQ FETCH 1171 data item. 1173 3.2.5. QRESYNC Parameter to SELECT/EXAMINE 1175 The Quick Resynchronization parameter to SELECT/EXAMINE commands has 1176 four arguments: 1178 o the last known UIDVALIDITY, 1180 o the last known modification sequence, 1182 o the optional set of known UIDs, and 1184 o an optional parenthesized list of known sequence ranges and their 1185 corresponding UIDs. 1187 A server MUST respond with a tagged BAD response if the Quick 1188 Resynchronization parameter to SELECT/EXAMINE command is specified 1189 and the client hasn't issued "ENABLE QRESYNC" in the current 1190 connection, or the server has not positively responded to that 1191 command with the untagged ENABLED response containing QRESYNC. 1193 Before opening the specified mailbox, the server verifies all 1194 arguments for syntactic validity. If any parameter is not 1195 syntactically valid, the server returns the tagged BAD response, and 1196 the mailbox remains unselected. Once the check is done, the server 1197 opens the mailbox as if no SELECT/EXAMINE parameters are specified 1198 (this is subject to processing of other parameters as defined in 1199 other extensions). In particular this means that the server MUST 1200 send all untagged responses as specified in Sections 6.3.1 and 6.3.2 1201 of [RFC3501]. 1203 After that, the server checks the UIDVALIDITY value provided by the 1204 client. If the provided UIDVALIDITY doesn't match the UIDVALIDITY 1205 for the mailbox being opened, then the server MUST ignore the 1206 remaining parameters and behave as if no dynamic message data 1207 changed. The client can discover this situation by comparing the 1208 UIDVALIDITY value returned by the server. This behavior allows the 1209 client not to synchronize the mailbox or decide on the best 1210 synchronization strategy. 1212 Example: Attempting to resynchronize INBOX, but the provided 1213 UIDVALIDITY parameter doesn't match the current UIDVALIDITY 1214 value. 1216 C: A02 SELECT INBOX (QRESYNC (67890007 20050715194045000 1217 41,43:211,214:541)) 1218 S: * 464 EXISTS 1219 S: * 3 RECENT 1220 S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY 1221 S: * OK [UIDNEXT 550] Predicted next UID 1222 S: * OK [HIGHESTMODSEQ 90060128194045007] Highest mailbox 1223 mod-sequence 1224 S: * OK [UNSEEN 12] Message 12 is first unseen 1225 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 1226 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 1227 \Deleted \Seen \*)] Permanent flags 1228 S: A02 OK [READ-WRITE] Sorry, UIDVALIDITY mismatch 1230 Remaining parameters are described in the following subsections. 1232 3.2.5.1. Modification Sequence and UID Parameters 1234 A server that doesn't support the persistent storage of mod-sequences 1235 for the mailbox MUST send an OK untagged response including the 1236 NOMODSEQ response code with every successful SELECT or EXAMINE 1237 command (see Section 3.1.2.2). Such a server doesn't need to 1238 remember mod-sequences for expunged messages in the mailbox. It MUST 1239 ignore the remaining parameters and behave as if no dynamic message 1240 data changed. 1242 If the provided UIDVALIDITY matches that of the selected mailbox, the 1243 server then checks the last known modification sequence. 1244 The server sends the client any pending flag changes (using FETCH 1245 responses that MUST contain UIDs) and expunges those that have 1246 occurred in this mailbox since the provided modification sequence. 1248 If the list of known UIDs was also provided, the server should only 1249 report flag changes and expunges for the specified messages. If the 1250 client did not provide the list of UIDs, the server acts as if the 1251 client has specified "1:", where is the mailbox's 1252 UIDNEXT value minus 1. If the mailbox is empty and never had any 1253 messages in it, then lack of the list of UIDs is interpreted as an 1254 empty set of UIDs. 1256 Thus, the client can process just these pending events and need not 1257 perform a full resynchronization. Without the message sequence 1258 number matching information, the result of this step is semantically 1259 equivalent to the client issuing: 1260 tag1 UID FETCH "known-uids" (FLAGS) (CHANGEDSINCE "mod-sequence- 1261 value" VANISHED) 1263 In particular this means that all requirement specified in 1264 Section 3.2.6 apply. 1266 Example: 1268 Example: 1270 C: A03 SELECT INBOX (QRESYNC (67890007 1271 90060115194045000 41:211,214:541)) 1272 S: * OK [CLOSED] 1273 S: * 100 EXISTS 1274 S: * 11 RECENT 1275 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 1276 S: * OK [UIDNEXT 600] Predicted next UID 1277 S: * OK [HIGHESTMODSEQ 90060115205545359] Highest 1278 mailbox mod-sequence 1279 S: * OK [UNSEEN 7] There are some unseen 1280 messages in the mailbox 1281 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 1282 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 1283 \Deleted \Seen \*)] Permanent flags 1284 S: * VANISHED (EARLIER) 41,43:116,118,120:211,214:540 1285 S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered) MODSEQ 1286 (90060115194045001)) 1287 S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent) MODSEQ 1288 (90060115194045308)) 1289 S: * 51 FETCH (UID 541 FLAGS (\Seen $Forwarded) MODSEQ 1290 (90060115194045001)) 1291 S: A03 OK [READ-WRITE] mailbox selected 1293 In the above example flag information for the UID 42 is not returned, 1294 presumably because its flags haven't changed since the MODSEQ 1295 90060115194045000. 1297 3.2.5.2. Message sequence match data 1299 A client MAY provide a parenthesized list of a message sequence set 1300 and the corresponding UID sets. Both MUST be provided in ascending 1301 order. The server uses this data to restrict the range for which it 1302 provides expunged message information. 1304 Conceptually, the client provides a small sample of sequence numbers 1305 for which it knows the corresponding UIDs. The server then compares 1306 each sequence number and UID pair the client provides with the 1307 current state of the mailbox. If a pair matches, then the client 1308 knows of any expunges up to, and including, the message, and thus 1309 will not include that range in the VANISHED response, even if the 1310 "mod-sequence-value" provided by the client is too old for the server 1311 to have data of when those messages were expunged. 1313 Thus, if the Nth message number in the first set in the list is 4, 1314 and the Nth UID in the second set in the list is 8, and the mailbox's 1315 fourth message has UID 8, then no UIDs equal to or less than 8 are 1316 present in the VANISHED response. If the (N+1)th message number is 1317 12, and the (N+1)th UID is 24, and the (N+1)th message in the mailbox 1318 has UID 25, then the lowest UID included in the VANISHED response 1319 would be 9. 1321 In the following two examples, the server is unable to remember 1322 expunges at all, and only UIDs with messages divisible by three are 1323 present in the mailbox. In the first example, the client does not 1324 use the fourth parameter; in the second, it provides it. This 1325 example is somewhat extreme, but shows that judicious usage of the 1326 sequence match data can save a substantial amount of bandwidth. 1328 Example: 1330 Example: 1332 C: A04 SELECT INBOX (QRESYNC (67890007 1333 90060115194045000 1:29997)) 1334 S: * 10003 EXISTS 1335 S: * 4 RECENT 1336 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 1337 S: * OK [UIDNEXT 30013] Predicted next UID 1338 S: * OK [HIGHESTMODSEQ 90060115205545359] Highest mailbox mod- 1339 sequence 1340 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox 1341 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 1342 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 1343 \Deleted \Seen \*)] Permanent flags 1344 S: * VANISHED (EARLIER) 1:2,4:5,7:8,10:11,13:14,[...], 1345 29668:29669,29671:29996 1346 S: * 1 FETCH (UID 3 FLAGS (\Seen \Answered $Important) MODSEQ 1347 (90060115194045001)) 1348 S: ... 1349 S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ 1350 (90060115194045027)) 1352 S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ 1353 (90060115194045028)) 1354 S: ... 1355 S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ 1356 (90060115194045031)) 1357 S: A04 OK [READ-WRITE] mailbox selected 1359 Example: 1361 Example: 1363 C: B04 SELECT INBOX (QRESYNC (67890007 1364 90060115194045000 1:29997 (5000,7500,9000,9990:9999 15000, 1365 22500,27000,29970,29973,29976,29979,29982,29985,29988,29991, 1366 29994,29997))) 1367 S: * 10003 EXISTS 1368 S: * 4 RECENT 1369 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 1370 S: * OK [UIDNEXT 30013] Predicted next UID 1371 S: * OK [HIGHESTMODSEQ 90060115205545359] Highest mailbox mod- 1372 sequence 1373 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox 1374 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 1375 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 1376 \Deleted \Seen \*)] Permanent flags 1377 S: * 1 FETCH (UID 3 FLAGS (\Seen \Answered $Important) MODSEQ 1378 (90060115194045001)) 1379 S: ... 1380 S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ 1381 (90060115194045027)) 1382 S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ 1383 (90060115194045028)) 1384 S: ... 1385 S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ 1386 (90060115194045031)) 1387 S: B04 OK [READ-WRITE] mailbox selected 1389 3.2.6. VANISHED UID FETCH Modifier 1391 [RFC4466] has extended the syntax of the FETCH and UID FETCH commands 1392 to include an optional FETCH modifier. This document defines a new 1393 UID FETCH modifier: VANISHED. 1395 Note, that the VANISHED UID FETCH modifier is NOT allowed with a 1396 FETCH command. The server MUST return a tagged BAD response if this 1397 response is specified as a modifier to the FETCH command. 1399 A server MUST respond with a tagged BAD response if the VANISHED UID 1400 FETCH modifier is specified and the client hasn't issued "ENABLE 1401 QRESYNC" in the current connection. 1403 The VANISHED UID FETCH modifier MUST only be specified together with 1404 the CHANGEDSINCE UID FETCH modifier. If the VANISHED UID FETCH 1405 modifier is used without the CHANGEDSINCE UID FETCH modifier the 1406 server MUST respond with a tagged BAD response. 1408 The VANISHED UID FETCH modifier instructs the server to report those 1409 messages from the UID set parameter that have been expunged and whose 1410 associated mod-sequence is larger than the specified mod-sequence. 1411 That is, the client requests to be informed of messages from the 1412 specified set that were expunged since the specified mod-sequence. 1413 Note that the mod-sequence(s) associated with these messages were 1414 updated when the messages were expunged (as described above). The 1415 expunged messages are reported using the VANISHED (EARLIER) response 1416 as described in Section 3.2.10.1. Any VANISHED (EARLIER) responses 1417 MUST be returned before any FETCH responses, as otherwise the client 1418 might get confused about how message numbers map to UIDs. 1420 Note: A server that receives a mod-sequence smaller than , 1421 where is the value of the smallest expunged mod-sequence 1422 it remembers minus one, MUST behave as if it was requested to report 1423 all expunged messages from the provided UID set parameter. 1425 Example 1: Without the VANISHED UID FETCH modifier, a CONDSTORE-aware 1426 client needs to issue separate commands to learn of flag changes and 1427 expunged messages since the last synchronization: 1429 C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345) 1430 S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen)) 1431 S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted)) 1432 S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk 1433 $AutoJunk $MDNSent)) 1434 S: s100 OK FETCH completed 1435 C: s101 UID SEARCH 300:500 1436 S: * SEARCH 404 406 407 408 410 412 1437 S: s101 OK search completed 1439 Where 300 and 500 are the lowest and highest UIDs from client's 1440 cache. The second SEARCH response tells the client that the messages 1441 with UIDs 407, 410, and 412 are still present, but their flags 1442 haven't changed since the specified modification sequence. 1444 Using the VANISHED UID FETCH modifier, it is sufficient to issue only 1445 a single command: 1447 C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345 1448 VANISHED) 1449 S: * VANISHED (EARLIER) 300:310,405,411 1450 S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen)) 1451 S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted)) 1452 S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk 1453 $AutoJunk $MDNSent)) 1454 S: s100 OK FETCH completed 1456 3.2.7. EXPUNGE Command 1458 Arguments: none 1460 Responses: untagged responses: EXPUNGE or VANISHED 1462 Result: OK - expunge completed 1463 NO - expunge failure: can't expunge (e.g., permission denied) 1464 BAD - command unknown or arguments invalid 1466 This section updates the definition of the EXPUNGE command described 1467 in Section 6.4.3 of [RFC3501]. 1469 The EXPUNGE command permanently removes all messages that have the 1470 \Deleted flag set from the currently selected mailbox. Before 1471 returning an OK to the client, those messages that are removed are 1472 reported using a VANISHED response or EXPUNGE responses. 1474 If the server is capable of storing modification sequences for the 1475 selected mailbox, it MUST increment the per-mailbox mod-sequence if 1476 at least one message was permanently removed due to the execution of 1477 the EXPUNGE command. For each permanently removed message, the 1478 server MUST remember the incremented mod-sequence and corresponding 1479 UID. If at least one message got expunged and QRESYNC was enabled, 1480 the server MUST send the updated per-mailbox modification sequence 1481 using the HIGHESTMODSEQ response code (see Section 3.1.2.1) in the 1482 tagged OK response. 1484 Example: C: A202 EXPUNGE 1485 S: * 3 EXPUNGE 1486 S: * 3 EXPUNGE 1487 S: * 5 EXPUNGE 1488 S: * 8 EXPUNGE 1489 S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged 1491 Note: In this example the client hasn't enabled QRESYNC, so the 1492 server is still using untagged EXPUNGE responses. Note that the 1493 presence of HIGHESTMODSEQ response code is optional in this case. If 1494 the selected mailbox returned NOMODSEQ, the HIGHESTMODSEQ response 1495 code will be absent. In this example, messages 3, 4, 7, and 11 had 1496 the \Deleted flag set. The first "* 3 EXPUNGE" reports message # 3 1497 as expunged. The second "* 3 EXPUNGE" reports message # 4 as 1498 expunged (the message number got decremented due to the previous 1499 EXPUNGE response). See the description of the EXPUNGE response in 1500 [RFC3501] for further explanation. 1502 Once the client enables QRESYNC, the the server will always send 1503 VANISHED responses instead of EXPUNGE responses for mailboxes that 1504 support storing of modification sequences, so the previous example 1505 might look like this: 1507 Example: C: B202 EXPUNGE 1508 S: * VANISHED 405,407,410,425 1509 S: B202 OK [HIGHESTMODSEQ 20010715194045319] expunged 1511 Here messages with message numbers 3, 4, 7, and 11 have respective 1512 UIDs 405, 407, 410, and 425. 1514 3.2.8. CLOSE Command 1516 Arguments: none 1518 Responses: no specific responses for this command 1520 Result: OK - close completed, now in authenticated state 1521 BAD - command unknown or arguments invalid 1523 This section updates the definition of the CLOSE command described in 1524 Section 6.4.2 of [RFC3501]. 1526 The CLOSE command permanently removes all messages that have the 1527 \Deleted flag set from the currently selected mailbox, and returns to 1528 the authenticated state from the selected state. No untagged EXPUNGE 1529 (or VANISHED) responses are sent. 1531 If the server is capable of storing modification sequences for the 1532 selected mailbox, it MUST increment the per-mailbox mod-sequence if 1533 at least one message was permanently removed due to the execution of 1534 the CLOSE command. For each permanently removed message, the server 1535 MUST remember the incremented mod-sequence and corresponding UID. 1536 The server MUST NOT send the updated per-mailbox modification 1537 sequence using the HIGHESTMODSEQ response code (see Section 3.1.2.1) 1538 in the tagged OK response, as this might cause loss of 1539 synchronization on the client. 1541 Example: C: A202 CLOSE 1542 S: A202 OK done 1544 3.2.9. UID EXPUNGE Command 1546 Arguments: message set 1548 Responses: untagged responses: EXPUNGE or VANISHED 1550 Result: OK - expunge completed 1551 NO - expunge failure: can't expunge (e.g., permission denied) 1552 BAD - command unknown or arguments invalid 1554 This section updates the definition of the UID EXPUNGE command 1555 described in Section 2.1 of [UIDPLUS]. Servers that implement both 1556 [UIDPLUS] and QRESYNC extensions must implement UID EXPUNGE as 1557 described in this section. 1559 The UID EXPUNGE command permanently removes from the currently 1560 selected mailbox all messages that both have the \Deleted flag set 1561 and have a UID that is included in the specified message set. If a 1562 message either does not have the \Deleted flag set or has a UID that 1563 is not included in the specified message set, it is not affected. 1565 This command is particularly useful for disconnected mode clients. 1566 By using UID EXPUNGE instead of EXPUNGE when resynchronizing with the 1567 server, the client can avoid inadvertently removing any messages that 1568 have been marked as \Deleted by other clients between the time that 1569 the client was last connected and the time the client resynchronizes. 1571 Before returning an OK to the client, those messages that are removed 1572 are reported using a VANISHED response or EXPUNGE responses. 1574 If the server is capable of storing modification sequences for the 1575 selected mailbox, it MUST increment the per-mailbox mod-sequence if 1576 at least one message was permanently removed due to the execution of 1577 the UID EXPUNGE command. For each permanently removed message, the 1578 server MUST remember the incremented mod-sequence and corresponding 1579 UID. If at least one message got expunged and QRESYNC was enabled, 1580 the server MUST send the updated per-mailbox modification sequence 1581 using the HIGHESTMODSEQ response code (see Section 3.1.2.1) in the 1582 tagged OK response. 1584 Example: C: . UID EXPUNGE 3000:3002 1585 S: * 3 EXPUNGE 1586 S: * 3 EXPUNGE 1587 S: * 3 EXPUNGE 1588 S: . OK [HIGHESTMODSEQ 20010715194045319] Ok 1590 Note: In this example the client hasn't enabled QRESYNC, so the 1591 server is still using untagged EXPUNGE responses instead of VANISHED 1592 responses. Note that the presence of HIGHESTMODSEQ response code is 1593 optional. If the selected mailbox returned NOMODSEQ, the 1594 HIGHESTMODSEQ response code will be absent. In this example, at 1595 least messages with message numbers 3, 4, and 5 (UIDs 3000 to 3002) 1596 had the \Deleted flag set. The first "* 3 EXPUNGE" reports message # 1597 3 as expunged. The second "* 3 EXPUNGE" reports message # 4 as 1598 expunged (the message number got decremented due to the previous 1599 EXPUNGE response). See the description of the EXPUNGE response in 1600 [RFC3501] for further explanation. 1602 3.2.10. VANISHED Response 1604 The VANISHED response reports that the specified UIDs have been 1605 permanently removed from the mailbox. This response is similar to 1606 the EXPUNGE response [RFC3501]; however, it can return information 1607 about multiple messages, and it returns UIDs instead of message 1608 numbers. The first benefit saves bandwidth, while the second is more 1609 convenient for clients that only use UIDs to access the IMAP server. 1611 The VANISHED response has the same restrictions on when it can be 1612 sent as does the EXPUNGE response (see below). Once a client has 1613 issued "ENABLE QRESYNC" (and the server has positively responded to 1614 that command with the untagged ENABLED response containing QRESYNC), 1615 the server MUST use the VANISHED response without the EARLIER tag 1616 instead of the EXPUNGE response for all mailboxes that don't return 1617 NOMODSEQ when selected. The server continues using VANISHED in lieu 1618 of EXPUNGE for the duration of the connection. In particular, this 1619 affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as 1620 well as messages expunged in other connections. Such a VANISHED 1621 response MUST NOT contain the EARLIER tag. 1623 The VANISHED response has two forms. The first form contains the 1624 EARLIER tag, which signifies that the response was caused by a UID 1625 FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. The second 1626 form doesn't contain the EARLIER tag and is used for announcing 1627 message removals within an already selected mailbox. 1629 Because clients handle the two different forms of the VANISHED 1630 response differently, servers MUST NOT combine them: messages are 1631 reported in VANISHED responses with or without the EARLIER tag, as 1632 appropriate to the cause, and, if necessary, two VANISHED responses 1633 are sent (one with EARLIER and one without). 1635 3.2.10.1. VANISHED (EARLIER) Response 1637 Contents: an EARLIER tag 1639 list of UIDs 1641 The VANISHED (EARLIER) response is caused by a UID FETCH (VANISHED) 1642 or a SELECT/EXAMINE (QRESYNC) command. This response is sent if the 1643 UID set parameter to the UID FETCH (VANISHED) command includes UIDs 1644 of messages that are no longer in the mailbox. When the client sees 1645 a VANISHED EARLIER response, it MUST NOT decrement message sequence 1646 numbers for each successive message in the mailbox. 1648 3.2.10.2. VANISHED Response without the (EARLIER) Tag 1650 Contents: list of UIDs 1652 Once a client has issued "ENABLE QRESYNC" (and the server has 1653 positively responded to that command with the untagged ENABLED 1654 response containing QRESYNC), the server MUST use the VANISHED 1655 response without the EARLIER tag instead of the EXPUNGE response for 1656 all mailboxes that don't return NOMODSEQ when selected. The server 1657 continues using VANISHED in lieu of EXPUNGE for the duration of the 1658 connection. In particular, this affects the EXPUNGE [RFC3501] and 1659 UID EXPUNGE [UIDPLUS] commands, as well as messages expunged in other 1660 connections. Such a VANISHED response MUST NOT contain the EARLIER 1661 tag. 1663 Unlike the VANISHED (EARLIER), this response also decrements the 1664 number of messages in the mailbox, and adjusts the message sequence 1665 numbers for the messages remaining in the mailbox to account for the 1666 expunged messages. Because of this housekeeping, it is not necessary 1667 for the server to send an EXISTS response the report the new message 1668 count. See the example at the end of this section). 1670 A VANISHED response without the EARLIER tag MUST refer only to 1671 messages that are visible to the client in the current session at the 1672 time the VANISHED response is sent. That is, servers MUST NOT send 1673 UIDs for previously expunged messages, or messages which were not 1674 announced to the client via EXISTS. This means that each UID listed 1675 in a VANISHED response results in the client decrementing the message 1676 count by one. This is required to prevent a possible race condition 1677 where new arrivals for which the UID is not yet known by the client 1678 are immediately expunged. 1680 A VANISHED response MUST NOT be sent when no command is in progress, 1681 nor while responding to a FETCH, STORE, or SEARCH command. This rule 1682 is necessary to prevent a loss of synchronization of message sequence 1683 numbers between client and server. A command is not "in progress" 1684 until the complete command has been received; in particular, a 1685 command is not "in progress" during the negotiation of command 1686 continuation. 1688 Note: UID FETCH, UID STORE, and UID SEARCH are different commands 1689 from FETCH, STORE, and SEARCH. A VANISHED response MAY be sent 1690 during a UID command. However, the VANISHED response MUST NOT be 1691 sent during a UID SEARCH command that contains message numbers in the 1692 search criteria. 1694 The update from the VANISHED response MUST be recorded by the client. 1696 Example: Let's assume that there is the following mapping between 1697 message numbers and UIDs in the currently selected mailbox (here "D" 1698 marks messages with the \Deleted flag set, and "x" represents UIDs 1699 which are not relevant for the example): 1701 Message numbers: 1 2 3 4 5 6 7 8 9 10 11 1702 UIDs: x 504 505 507 508 x 510 x x x 625 1703 \Deleted messages: D D D D 1705 In the presence of the extension defined in this document: 1707 C: A202 EXPUNGE 1708 S: * VANISHED 505,507,510,625 1709 S: A202 OK EXPUNGE completed 1711 Without the QRESYNC extension, the same example might look like: 1713 C: A202 EXPUNGE 1714 S: * 3 EXPUNGE 1715 S: * 3 EXPUNGE 1716 S: * 5 EXPUNGE 1717 S: * 8 EXPUNGE 1718 S: A202 OK EXPUNGE completed 1719 (Continuing previous example) If subsequently messages with UIDs 504 1720 and 508 got marked as \Deleted: 1722 C: A210 EXPUNGE 1723 S: * VANISHED 504,508 1724 S: A210 OK EXPUNGE completed 1726 i.e., the last VANISHED response only contains UIDs of messages 1727 expunged since the previous VANISHED response. 1729 To illustrate the difference between the VANISHED and VANISHED 1730 (EARLIER), suppose the mailbox contains UIDs 2 and 4. Any of the 1731 following responses would consitute a broken server implementation: 1733 S: * VANISHED 1 1734 S: * VANISHED 3 1735 S: * VANISHED 5 1737 However, any of these UIDs can easily be referenced by the VANISHED 1738 (EARLIER) response. 1740 3.2.11. CLOSED Response Code 1742 The CLOSED response code has no parameters. A server implementing 1743 the extension defined in this document MUST return the CLOSED 1744 response code when the currently selected mailbox is closed 1745 implicitly using the SELECT/EXAMINE command on another mailbox. The 1746 CLOSED response code serves as a boundary between responses for the 1747 previously opened mailbox (which was closed) and the newly selected 1748 mailbox: all responses before the CLOSED response code relate to the 1749 mailbox that was closed, and all subsequent responses relate to the 1750 newly opened mailbox. 1752 There is no need to return the CLOSED response code on completion of 1753 the CLOSE or the UNSELECT [UNSELECT] command (or similar) whose 1754 purpose is to close the currently selected mailbox without opening a 1755 new one. 1757 4. Long Command Lines (Update to RFC 2683) 1759 While [RFC3501] doesn't specify a specific line length limit, several 1760 server implementations chose to implement the recommended line length 1761 limit suggested in Section 3.2.1.5 of [RFC2683] in order to protect 1762 from Denial-of-Service attacks. When the line length limit is 1763 exceeded such servers return BAD response (as required by [RFC3501] 1764 in case of a syntactic error) and may even close the connection. 1765 Clients that support CONDSTORE/QRESYNC extensions can trigger this 1766 limit by sending a long UID sequence (previously returned by the 1767 server) in an extended SELECT or FETCH command. 1769 This document updates recommended line length limits specified in 1770 Section 3.2.1.5 of [RFC2683]. While the advice in the first 1771 paragraph of that section still applies ("use compact message/UID set 1772 representations"), the 1000 octet limit suggested in the second 1773 paragraph turned out to be quite problematic when the CONDSTORE and/ 1774 or QRESYNC extension is used. 1776 The updated recommendation is as follows: a client should limit the 1777 length of the command lines it generates to approximately 8192 octets 1778 (including all quoted strings but not including literals). If the 1779 client is unable to group things into ranges so that the command line 1780 is within that length, it should split the request into multiple 1781 commands. The client should use literals instead of long quoted 1782 strings, in order to keep the command length down. 1784 5. QRESYNC Server Implementation Considerations 1786 This section describes a minimalist implementation, a moderate 1787 implementation, and an example of a full implementation. 1789 5.1. Server Implementations That Don't Store Extra State 1791 Strictly speaking, a server implementation that doesn't remember mod- 1792 sequences associated with expunged messages can be considered 1793 compliant with this specification. Such implementations return all 1794 expunged messages specified in the UID set of the UID FETCH 1795 (VANISHED) command every time, without paying attention to the 1796 specified CHANGEDSINCE mod-sequence. Such implementations are 1797 discouraged, as they can end up returning VANISHED responses that are 1798 bigger than the result of a UID SEARCH command for the same UID set. 1800 A client can substantially reduce the size of VANISHED responses by 1801 providing the server with message sequence match data (see 1802 Section 3.2.5.2). This is especially effective in the typical case 1803 where no messages have been expunged, or all expunges were toward the 1804 end of the mailbox. 1806 5.2. Server Implementations Storing Minimal State 1808 A server that stores the HIGHESTMODSEQ value at the time of the last 1809 EXPUNGE can omit the VANISHED response when a client provides a 1810 MODSEQ value that is equal to, or higher than that HIGHESTMODSEQ 1811 value, because there have been no messages expunged during the time 1812 period the client is concerned about. 1814 A client providing message sequence match data can reduce the scope 1815 as above. In the case where there have been no expunges, the server 1816 can ignore this data. 1818 5.3. Additional State Required on the Server 1820 When compared to the CONDSTORE extension, QRESYNC requires servers to 1821 store additional state associated with expunged messages. Note that 1822 implementations are not required to store this state in persistent 1823 storage; however, use of persistent storage is advisable. 1825 One possible way to correctly implement QRESYNC is to store a queue 1826 of pairs. can be represented as a 1827 sequence of pairs. 1829 When messages are expunged, one or more entries are added to the 1830 queue tail. 1832 When the server receives a request to return messages expunged since 1833 a given mod-sequence, it will search the queue from the tail (i.e., 1834 going from the highest expunged mod-sequence to the lowest) until it 1835 sees the first record with a mod-sequence less than or equal to the 1836 given mod-sequence or it reaches the head of the queue. 1838 Note that indefinitely storing information about expunged messages 1839 can cause storage and related problems for an implementation. In the 1840 worst case, this could result in almost 64Gb of storage for each IMAP 1841 mailbox. For example, consider an implementation that stores triples for each range of messages 1843 expunged at the same time. Each triple requires 16 octets: 4 octets 1844 for each of the two UIDs, and 8 octets for the mod-sequence. Assume 1845 that there is a mailbox containing a single message with a UID of 1846 2**32-1 (the maximum possible UID value), where messages had 1847 previously existed with UIDs starting at 1, and have been expunged 1848 one at a time. For this mailbox alone, storage is required for the 1849 triples <1, 1, modseq1>, <2, 2, modseq2>, ..., <2**32-2, 2**32-2, 1850 modseq4294967294>. 1852 Hence, implementations are encouraged to adopt strategies to protect 1853 against such storage problems, such as limiting the size of the queue 1854 used to store mod-sequences for expunged messages and "expiring" 1855 older records when this limit is reached. When the selected 1856 implementation-specific queue limit is reached, the oldest record(s) 1857 are deleted from the queue (note that such records are located at the 1858 queue head). For all such "expired" records, the server needs to 1859 store a single mod-sequence, which is the highest mod-sequence for 1860 all "expired" expunged messages. 1862 If the client provides the message sequence match data, this can 1863 heavily reduce the data cost of sending a complete set of missing 1864 UIDs; thus, reducing the problems for clients if a server is unable 1865 to persist much of this queue. If the queue contains data back to 1866 the requested mod-sequence, this data can be ignored. 1868 Also, note that if the UIDVALIDITY of the mailbox changes or if the 1869 mailbox is deleted, then any state associated with expunged messages 1870 doesn't need to be preserved and SHOULD be deleted. 1872 6. Updated Synchronization Sequence 1874 This section updates the description of optimized synchronization in 1875 Section 6.1 of the [IMAP-DISC]. 1877 An advanced disconnected mail client SHOULD use the QRESYNC extension 1878 when it is supported by the server, and SHOULD use CONDSTORE if it is 1879 supported and QRESYNC is not. The client uses the value from the 1880 HIGHESTMODSEQ OK response code received on mailbox opening to 1881 determine if it needs to resynchronize. Once the synchronization is 1882 complete, it MUST cache the received value (unless the mailbox 1883 UIDVALIDITY value has changed; see below). The client MUST update 1884 its copy of the HIGHESTMODSEQ value whenever the server sends a 1885 subsequent HIGHESTMODSEQ OK response code. 1887 After completing a full synchronization, the client MUST also take 1888 note of any unsolicited MODSEQ FETCH data items and HIGHESTMODSEQ 1889 response codes received from the server. Whenever the client 1890 receives a tagged response to a command, it checks the received 1891 unsolicited responses to calculate the new HIGHESTMODSEQ value. If 1892 the HIGHESTMODSEQ response code is received, the client MUST use it 1893 even if it has seen higher mod-sequences. Otherwise, the client 1894 calculates the highest value among all MODSEQ FETCH data items 1895 received since the last tagged response. If this value is bigger 1896 than the client's copy of the HIGHESTMODSEQ value, then the client 1897 MUST use this value as its new HIGHESTMODSEQ value. 1899 Example: 1901 C: A150 STORE 1:2 (UNCHANGEDSINCE 96) +FLAGS.SILENT \Seen 1902 S: * 1 FETCH (UID 6 MODSEQ (103)) 1903 S: * 2 FETCH (UID 7 MODSEQ (101)) 1904 S: * OK [HIGHESTMODSEQ 99] VANISHED reply with MODSEQ 100 is delayed 1905 S: A150 OK [MODIFIED 3] done 1907 C: A151 STORE 3 +FLAGS.SILENT \Seen 1908 S: * 3 FETCH (UID 8 MODSEQ (104)) 1909 S: A151 OK [HIGHESTMODSEQ 99] Still delaying VANISHED 1911 C: A152 NOOP 1912 S: * VANISHED 8 1913 S: A153 OK [HIGHESTMODSEQ 104] done 1915 Note: It is not safe to update the client's copy of the HIGHESTMODSEQ 1916 value with a MODSEQ FETCH data item value as soon as it is received 1917 because servers are not required to send MODSEQ FETCH data items in 1918 increasing modseqence order. Some commands may also delay EXPUNGE 1919 (or VANISHED) replies with smaller mod-sequences. These can lead to 1920 the client missing some changes in case of connectivity loss. 1922 When opening the mailbox for synchronization, the client uses the 1923 QRESYNC parameter to the SELECT/EXAMINE command. The QRESYNC 1924 parameter is followed by the UIDVALIDITY and mailbox HIGHESTMODSEQ 1925 values, as known to the client. It can be optionally followed by the 1926 set of UIDs, for example, if the client is only interested in partial 1927 synchronization of the mailbox. The client may also transmit a list 1928 containing its knowledge of message numbers. 1930 If the SELECT/EXAMINE command is successful, the client compares 1931 UIDVALIDITY as described in step d)1) in Section 3 of the 1932 [IMAP-DISC]. If the cached UIDVALIDITY value matches the one 1933 returned by the server and the server also returns the HIGHESTMODSEQ 1934 response code, then the server reports expunged messages and returns 1935 flag changes for all messages specified by the client in the UID set 1936 parameter (or for all messages in the mailbox, if the client omitted 1937 the UID set parameter). At this point, the client is synchronized, 1938 except for maybe the new messages. 1940 If upon a successful SELECT/EXAMINE (QRESYNC) command the client 1941 receives a NOMODSEQ OK untagged response (instead of the 1942 HIGHESTMODSEQ response code), it MUST remove the last known 1943 HIGHESTMODSEQ value from its cache and follow the more general 1944 instructions in Section 3 of the [IMAP-DISC]. 1946 At this point, the client is in sync with the server regarding old 1947 messages. This client can now fetch information about new messages 1948 (if requested by the user). 1950 Step d) ("Server-to-client synchronization") in Section 4 of the 1951 [IMAP-DISC] in the presence of the QRESYNC & CONDSTORE extensions is 1952 amended as follows: 1954 d) "Server-to-client synchronization" -- for each mailbox that 1955 requires synchronization, do the following: 1957 1a) Check the mailbox UIDVALIDITY (see Section 4.1 of the [IMAP-DISC] 1958 for more details) after issuing SELECT/EXAMINE (QRESYNC) command. 1960 If the UIDVALIDITY value returned by the server differs, the 1961 client MUST 1963 * empty the local cache of that mailbox; 1965 * "forget" the cached HIGHESTMODSEQ value for the mailbox; 1967 * remove any pending "actions" which refer to UIDs in that 1968 mailbox. Note, this doesn't affect actions performed on 1969 client generated fake UIDs (see Section 5 of the [IMAP-DISC]); 1971 2) Fetch the current "descriptors"; 1973 I) Discover new messages. 1975 3) Fetch the bodies of any "interesting" messages that the client 1976 doesn't already have. 1978 Example: The UIDVALIDITY value is the same, but the HIGHESTMODSEQ 1979 value has changed on the server while the client was 1980 offline: 1982 C: A142 SELECT INBOX (QRESYNC (3857529045 20010715194032001 1:198)) 1983 S: * 172 EXISTS 1984 S: * 1 RECENT 1985 S: * OK [UNSEEN 12] Message 12 is first unseen 1986 S: * OK [UIDVALIDITY 3857529045] UIDs valid 1987 S: * OK [UIDNEXT 201] Predicted next UID 1988 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 1989 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 1990 S: * OK [HIGHESTMODSEQ 20010715194045007] Highest 1991 mailbox mod-sequence 1992 S: * VANISHED (EARLIER) 1:5,7:8,10:15 1993 S: * 2 FETCH (UID 6 MODSEQ (20010715205008000) 1994 FLAGS (\Deleted)) 1995 S: * 5 FETCH (UID 9 MODSEQ (20010715195517000) 1996 FLAGS ($NoJunk $AutoJunk $MDNSent)) 1997 ... 1998 S: A142 OK [READ-WRITE] SELECT completed 2000 7. Formal Syntax 2002 The following syntax specification uses the Augmented Backus-Naur 2003 Form (ABNF) notation as specified in [RFC5234]. 2005 Non-terminals referenced but not defined below are as defined by 2006 [RFC5234], [RFC3501], or [RFC4466]. 2008 Except as noted otherwise, all alphabetic characters are case- 2009 insensitive. The use of upper or lower case characters to define 2010 token strings is for editorial clarity only. Implementations MUST 2011 accept these strings in a case-insensitive fashion. 2013 capability =/ "CONDSTORE" / "QRESYNC" 2015 status-att =/ "HIGHESTMODSEQ" 2016 ;; extends non-terminal defined in [RFC3501]. 2018 status-att-val =/ "HIGHESTMODSEQ" SP mod-sequence-valzer 2019 ;; extends non-terminal defined in [RFC4466]. 2020 ;; Value 0 denotes that the mailbox doesn't 2021 ;; support persistent mod-sequences 2022 ;; as described in Section 3.1.2.2 2024 store-modifier =/ "UNCHANGEDSINCE" SP mod-sequence-valzer 2025 ;; Only a single "UNCHANGEDSINCE" may be 2026 ;; specified in a STORE operation 2028 fetch-modifier =/ chgsince-fetch-mod 2029 ;; conforms to the generic "fetch-modifier" 2030 ;; syntax defined in [RFC4466]. 2032 chgsince-fetch-mod = "CHANGEDSINCE" SP mod-sequence-value 2033 ;; CHANGEDSINCE FETCH modifier conforms to 2034 ;; the fetch-modifier syntax 2036 fetch-att =/ fetch-mod-sequence 2037 ;; modifies original IMAP4 fetch-att 2039 fetch-mod-sequence = "MODSEQ" 2041 fetch-mod-resp = "MODSEQ" SP "(" permsg-modsequence ")" 2043 msg-att-dynamic =/ fetch-mod-resp 2045 search-key =/ search-modsequence 2046 ;; modifies original IMAP4 search-key 2047 ;; 2048 ;; This change applies to all commands 2049 ;; referencing this non-terminal, in 2050 ;; particular SEARCH, SORT and THREAD. 2052 search-modsequence = "MODSEQ" [search-modseq-ext] SP 2053 mod-sequence-valzer 2055 search-modseq-ext = SP entry-name SP entry-type-req 2057 resp-text-code =/ "HIGHESTMODSEQ" SP mod-sequence-value / 2058 "NOMODSEQ" / 2059 "MODIFIED" SP sequence-set 2061 entry-name = entry-flag-name 2063 entry-flag-name = DQUOTE "/flags/" attr-flag DQUOTE 2064 ;; each system or user defined flag 2065 ;; is mapped to "/flags/". 2066 ;; 2067 ;; follows the escape rules 2068 ;; used by "quoted" string as described in 2069 ;; Section 4.3 of [RFC3501], e.g., for the 2070 ;; flag \Seen the corresponding 2071 ;; is "/flags/\\seen", and for the flag 2072 ;; $MDNSent, the corresponding 2073 ;; is "/flags/$mdnsent". 2075 entry-type-resp = "priv" / "shared" 2076 ;; metadata item type 2078 entry-type-req = entry-type-resp / "all" 2079 ;; perform SEARCH operation on private 2080 ;; metadata item, shared metadata item or both 2082 permsg-modsequence = mod-sequence-value 2083 ;; per message mod-sequence 2085 mod-sequence-value = 1*DIGIT 2086 ;; Positive unsigned 63-bit integer 2087 ;; (mod-sequence) 2088 ;; (1 <= n <= 9,223,372,036,854,775,807) 2090 mod-sequence-valzer = "0" / mod-sequence-value 2092 search-sort-mod-seq = "(" "MODSEQ" SP mod-sequence-value ")" 2094 select-param =/ condstore-param 2095 ;; conforms to the generic "select-param" 2096 ;; non-terminal syntax defined in [RFC4466]. 2098 condstore-param = "CONDSTORE" 2100 mailbox-data =/ "SEARCH" [1*(SP nz-number) SP 2101 search-sort-mod-seq] 2103 sort-data = "SORT" [1*(SP nz-number) SP 2104 search-sort-mod-seq] 2105 ; Updates SORT response from RFC 5256 2107 attr-flag = "\\Answered" / "\\Flagged" / "\\Deleted" / 2108 "\\Seen" / "\\Draft" / attr-flag-keyword / 2109 attr-flag-extension 2110 ;; Does not include "\\Recent" 2112 attr-flag-extension = "\\" atom 2113 ;; Future expansion. Client implementations 2114 ;; MUST accept flag-extension flags. Server 2115 ;; implementations MUST NOT generate 2116 ;; flag-extension flags except as defined by 2117 ;; future standard or standards-track 2118 ;; revisions of [RFC3501]. 2120 attr-flag-keyword = atom 2122 select-param = "QRESYNC" SP "(" uidvalidity SP 2123 mod-sequence-value [SP known-uids] 2124 [SP seq-match-data] ")" 2125 ;; conforms to the generic select-param 2126 ;; syntax defined in [RFC4466] 2128 seq-match-data = "(" known-sequence-set SP known-uid-set ")" 2130 uidvalidity = nz-number 2132 known-uids = sequence-set 2133 ;; sequence of UIDs, "*" is not allowed 2135 known-sequence-set = sequence-set 2136 ;; set of message numbers corresponding to 2137 ;; the UIDs in known-uid-set, in ascending order. 2138 ;; * is not allowed. 2140 known-uid-set = sequence-set 2141 ;; set of UIDs corresponding to the messages in 2142 ;; known-sequence-set, in ascending order. 2143 ;; * is not allowed. 2145 message-data =/ expunged-resp 2147 expunged-resp = "VANISHED" [SP "(EARLIER)"] SP known-uids 2149 rexpunges-fetch-mod = "VANISHED" 2150 ;; VANISHED UID FETCH modifier conforms 2151 ;; to the fetch-modifier syntax 2152 ;; defined in [RFC4466]. It is only 2153 ;; allowed in the UID FETCH command. 2155 resp-text-code =/ "CLOSED" 2157 8. Security Considerations 2159 As always, it is important to thoroughly test clients and servers 2160 implementing QRESYNC, as it changes how the server reports expunged 2161 messages to the client. 2163 It is believed that the CONDSTORE or the QRESYNC extensions don't 2164 raise any new security concerns that are not already discussed in 2165 [RFC3501]. However, the availability of CONDSTORE may make it 2166 possible for IMAP4 to be used in critical applications it could not 2167 be used for previously, making correct IMAP server implementation and 2168 operation even more important. 2170 9. IANA Considerations 2172 IMAP4 capabilities are registered by publishing a standards track or 2173 IESG approved experimental RFC. The registry is currently located 2174 at: 2176 http://www.iana.org/assignments/imap4-capabilities 2178 This document defines the CONDSTORE and QRESYNC IMAP capabilities. 2179 IANA is requested to update references for both extensions to point 2180 to this document. 2182 10. References 2184 10.1. Normative References 2186 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2187 Requirement Levels", BCP 14, RFC 2119, March 1997. 2189 [RFC2683] Leiba, B., "IMAP4 Implementation Recommendations", RFC 2190 2683, September 1999. 2192 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 2193 4rev1", RFC 3501, March 2003. 2195 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 2196 ABNF", RFC 4466, April 2006. 2198 [RFC5161] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE 2199 Extension", RFC 5161, March 2008. 2201 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2202 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2204 [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access 2205 Protocol - SORT and THREAD Extensions", RFC 5256, June 2206 2008. 2208 [RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464, 2209 February 2009. 2211 [UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - 2212 UIDPLUS extension", RFC 4315, December 2005. 2214 10.2. Informative References 2216 [IMAP-DISC] 2217 Melnikov, A., Ed., "Synchronization Operations For 2218 Disconnected Imap4 Clients", RFC 4549, June 2006. 2220 [NTP] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 2221 Time Protocol Version 4: Protocol and Algorithms 2222 Specification", RFC 5905, June 2010. 2224 [RFC2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 2225 2180, July 1997. 2227 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 2228 RFC 4314, December 2005. 2230 [RFC4731] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH 2231 Command for Controlling What Kind of Information Is 2232 Returned", RFC 4731, November 2006. 2234 [RFC5257] Daboo, C. and R. Gellens, "Internet Message Access 2235 Protocol - ANNOTATE Extension", RFC 5257, June 2008. 2237 [RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, 2238 July 2008. 2240 [RFC6851] Gulbrandsen, A. and N. Freed, "Internet Message Access 2241 Protocol (IMAP) - MOVE Extension", RFC 6851, January 2013. 2243 [UNSELECT] 2244 Melnikov, A., "Internet Message Access Protocol (IMAP) 2245 UNSELECT command", RFC 3691, February 2004. 2247 Appendix A. Changes since RFC 4551 2249 Changed mod-sequences to be unsigned 63-bit values (instead of 2250 unsigned 64-bit values). 2252 Fixed errata 3401 ("several typos in UNCHANGEDSINCE spelling"), 3506 2253 ("invalid ABNF for the MODIFIED response code") and 3509 ("correction 2254 to an example"). 2256 Clarified that returning of HIGHESTMODSEQ/NOMODSEQ response codes is 2257 only required once a CONDSTORE enabling command was issued. 2259 Clarified that if multiple mod-sequences (for different metadata 2260 items) are associated with a message, then all of them affecting a 2261 particular STORE UNCHANGEDSINCE must be checked. 2263 Updated references. 2265 Editorial corrections. 2267 Appendix B. Changes since RFC 5162 2269 Changed mod-sequences to be unsigned 63-bit values (instead of 2270 unsigned 64-bit values). 2272 Addressed erratum #1365: http://www.rfc-editor.org/ 2273 errata_search.php?eid=1365 2275 Addressed erratum #1807: http://www.rfc-editor.org/ 2276 errata_search.php?eid=1807 2278 Addressed erratum #1808: http://www.rfc-editor.org/ 2279 errata_search.php?eid=1808 2281 Addressed erratum #1809: http://www.rfc-editor.org/ 2282 errata_search.php?eid=1809 2284 Addressed erratum #1810: http://www.rfc-editor.org/ 2285 errata_search.php?eid=1810 2287 Addressed erratum #3322: http://www.rfc-editor.org/ 2288 errata_search.php?eid=3322 2290 Clarified that ENABLE QRESYNC CONDSTORE and ENABLE CONDSTORE QRESYNC 2291 are equivalent. 2293 Changed the requirement to return VANISHED from SHOULD to MUST as per 2294 the mailing list discussion. The only exception is for mailboxes 2295 that return NOMODSEQ response code when they are selected. 2297 Specified that IMAP SETMETADATA changes update per-mailbox 2298 HIGHESTMODSEQ. 2300 Clarified that per-message annotations are also considered 2301 "metadata". 2303 Fixed some examples to report data that match requirements specified 2304 in the document. 2306 Clarified some text and made some requirements normative. Also 2307 corrected a couple of SHOULDs to be MUSTs. 2309 Updated references. 2311 Editorial corrections. 2313 Appendix C. Acknowledgements 2315 Thank you to Steve Hole for co-editing RFC 4551. 2317 In this revision of the document the authors also acknowledge the 2318 feedback provided by Timo Sirainen, Jan Kundrat, Pete Maclean, Barry 2319 Leiba, Eliot Lear, Chris Newman, Claudio Allocchio, Michael Slusarz, 2320 Bron Gondwana, Arnt Gulbrandsen, David Black and Hoa V. DINH. 2322 Mark Crispin contributed to RFC 4551 and RFC 5162 that this document 2323 is replacing, and that much of his contribution remains in this 2324 merged document. 2326 See also RFC 4551 for the list of people who contributed to earlier 2327 version of this RFC. 2329 Authors' Addresses 2331 Alexey Melnikov 2332 Isode Ltd 2333 5 Castle Business Village 2334 36 Station Road 2335 Hampton, Middlesex TW12 2BX 2336 UK 2338 Email: Alexey.Melnikov@isode.com 2340 Dave Cridland 2341 Arcode Inc 2342 4304 East West Highway 2343 Bethesda, MD 20814 2344 US 2346 Email: dcridland@arcode.com