mailing list archives

meli community discussions

⚠️ if something does not work as intended when interracting with the mailing lists,
reach out Github mirror Gitea repo @epilys:matrix.org

E-mail headers
From: Jan Kundrát <jkt@flaska.net>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:50 -0000
Message-ID: 7237e649-33b3-47fb-a99a-4d3e7f28030f@flaska.net permalink / raw / eml / mbox
In-Reply-To: 201302081451.r18EpC0d010777@mxout11.cac.washington.edu
References: 201302081451.r18EpC0d010777@mxout11.cac.washington.edu
On Friday, 8 February 2013 15:50:38 CEST, Pete Maclean wrote:
> When a client has not enabled CONDSTORE and sends an ENABLE 
> QRESYNC command to a server that advertises QRESYNC capability, 
> should the untagged response say "* ENABLED QRESYNC" or "* 
> ENABLED QRESYNC CONDSTORE"?  My reading of the spec tells me the 
> latter but I observe that another server sends the former.

I believe that both of these are compliant. I haven't found a definitive answer on this in either 5161 (ENABLE) or 5162 (QRESYNC) RFCs.

I have one suggestion for the actual implementation: please don't ever send EXPUNGE when QRESYNC is enabled, and never reference other UIDs in VANISHED than those which have been just expunged. These restrictions are not mandated by the current version of the RFC, but are very important for clients (they prevent an ambiguous state where the client suddenly doesn't know which UIDs still remain in the mailbox).

Also, thanks for implementing QRESYNC; it's an extremely important RFC which improves the clients' behavior tremendously; the savings on traffic when opening mailboxes are huge. What IMAP server is the code you're working on?

With kind regards,
Jan

-- 
Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Reply