IMAP Extensions for Conditional STORE Operation or Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)

The information below is for an old version of the document
Document Type None Internet-Draft (qresync WG)
Last updated 2014-01-09 (latest revision 2014-01-07)
Replaces draft-ietf-qresync-rfc4551bis, draft-melnikov-5162bis
Stream IETF
Intended RFC status Proposed Standard
Expired & archived
pdf htmlized bibtex
Additional URLs
- Mailing list discussion
Stream WG state (None)
Document shepherd Eliot Lear
Shepherd write-up Show (last changed 2014-01-07)
IESG IESG state Unknown state
Consensus Boilerplate Yes
Telechat date
Responsible AD Barry Leiba
Send notices to,

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at


Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox. Initially defined in RFC 4551, The Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to message state. This memo updates that mechanism and obsoletes RFC 4551, based on operational experience. This document additionally updates another IMAP extension, Quick Resynchronization, which builds on the Conditional Store extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round-trips. Hence this memo obsoletes RFC 5162. Finally, when these extensions are used, other mechanisms are updated. In particular, the line length recommendation in RFC 2863 is modified, the UID EXPUNGE command from RFC 4315 is modified, and the behavior of STORE/UID STORE/FETCH/UID FETCH/EXPUNGE commands from RFC 3501 is modified.


Alexey Melnikov (
Dave Cridland (

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)