Subject: [lemonade] Regarding CONDSTORE IMAP extension

From: Samsung SVL <[email-masked]>
Date: Mon, 2 Dec 2013 13:51:24 -0800 (PST)

Hi All,

Kindly clarify my below query regarding "CONDSTORE" IMAP Extension.

When IMAP server advertises the "CONDSTORE" support as part of CAPABILITIES, client assumes that server support IMAP CONSTORE extension. 

As per RFC 4551,  client issues SELECT command  for a mailbox in the below format and receives the response with HIGHESTMODSEQ value as  "1"

C: A142 SELECT INBOX

During the subsequent SELECT command, client receives "HIGHESTMODSEQ" value always set to "1". Its not getting incremented with respect to the changes in the mailbox. 

Some IMAP server changes the HIGHESTMODSEQ value only when client issues SELECT command in the below format.

C:A142 SELECT "INBOX" (QRESYNC ("UIDVALIDITY" "HIGHESTMODSEQ"))

Kindly clarify which format is right one, because most of the IMAP server behaves differently. 

Regards,
Jay

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 3 Dec 2013 00:01:32 +0200

> Kindly clarify which format is right one, because most of the IMAP server behaves differently. 

If server advertises also ENABLE capability, you can send ENABLE CONDSTORE as your first command. Then all servers will work correctly.

---

From: Samsung SVL <[email-masked]>
Date: Mon, 2 Dec 2013 14:48:01 -0800 (PST)

Hi Timo,

Thanks for your response.

But if IMAP server does not support "ENABLE" command, what should be the client behavior ?

Regards,
Jay

>________________________________
> From: Timo Sirainen <[email-masked]>
>To: Samsung SVL <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Monday, 2 December 2013, 17:01
>Subject: Re: [lemonade] Regarding CONDSTORE IMAP extension
> 
>

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 3 Dec 2013 01:06:24 +0200

Likely you’re seeing this behavior only with Dovecot server, which enables modseq tracking lazily. And in Dovecot you can always work around that with the ENABLE CONDSTORE command (or any other CONDSTORE-enabling command).

On 3.12.2013, at 0.48, Samsung SVL <[email-masked]> wrote:

> _______________________________________________
> lemonade mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lemonade
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/lemonade

---

From: Chris Newman <[email-masked]>
Date: Mon, 02 Dec 2013 15:10:13 -0800

--On December 2, 2013 13:51:24 -0800 Samsung SVL <[email-masked]> 
wrote:

> When IMAP server advertises the "CONDSTORE" support as part of
> CAPABILITIES, client assumes that server support IMAP CONSTORE
> extension. 
>
> As per RFC 4551,  client issues SELECT command  for a mailbox in the
> below format and receives the response with HIGHESTMODSEQ value as  "1"
>
> C: A142 SELECT INBOX
>
> During the subsequent SELECT command, client receives "HIGHESTMODSEQ"
> value always set to "1". Its not getting incremented with respect to the
> changes in the mailbox. 
>

Technically, the former command is correct only if you've previously issued 
a condstore-enabling command (or don't want to use condstore) and the 
latter is correct only if the server advertises QRESYNC and you have issued 
"ENABLE QRESYNC" previously. For more details see RFC 4551 and RFC 5162.

Have you tried using:

 C: A142 SELECT INBOX (CONDSTORE)

That's a condstore-enabling command that servers advertising the CONDSTORE 
capability are required to support. Servers are free to not return 
HIGHESTMODSEQ at all until a condstore-enabling command occurs, and then 
they MUST return either HIGHESTMODSEQ or NOMODSEQ.

Of course, if a server is returning HIGHESTMODSEQ and not updating it after 
flag changes, that server may have a bug, so you may have to fallback to 
not using CONDSTORE with that server and just do a full resync every time. 
You might want to report that bug to the server vendor so they have the 
opportunity to fix it in a subsequent release.

		- Chris

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 3 Dec 2013 01:23:11 +0200

On 3.12.2013, at 1.10, Chris Newman <[email-masked]> wrote:

> Servers are free to not return HIGHESTMODSEQ at all until a condstore-enabling command occurs, and then they MUST return either HIGHESTMODSEQ or NOMODSEQ.

Ah. Hmm. I guess I missed that part when originally implementing it because of these two paragraphs below. Maybe rfc5162bis should clarify these a bit? Oh, and looks like Dovecot is actually first returning NOMODSEQ, not HIGHESTMODSEQ 1 as Samsung’s message said. Maybe that server isn’t Dovecot after all. Anyway, with this great new info I’ll just have Dovecot not send either NOMODSEQ or HIGHESTMODSEQ until CONDSTORE/QRESYNC is enabled, although of course that won’t help with any old installations.

3.1.  New OK Untagged Responses for SELECT and EXAMINE

   When opening a mailbox, the server must check if the mailbox supports
   the persistent storage of mod-sequences.  If the mailbox supports the
   persistent storage of mod-sequences and the mailbox open operation
   succeeds, the server MUST send the OK untagged response including
   HIGHESTMODSEQ response code.  If the persistent storage for the
   mailbox is not supported, the server MUST send the OK untagged
   response including NOMODSEQ response code instead.

3.1.1.  HIGHESTMODSEQ Response Code

   This document adds a new response code that is returned in the OK
   untagged response for the SELECT and EXAMINE commands.  A server
   supporting the persistent storage of mod-sequences for the mailbox
   MUST send the OK untagged response including HIGHESTMODSEQ response
   code with every successful SELECT or EXAMINE command:

---

From: Samsung SVL <[email-masked]>
Date: Mon, 2 Dec 2013 16:02:29 -0800 (PST)

Hi Chris,

Thanks for your clarification.

Regards,
Jay

> From: Chris Newman <[email-masked]>
>To: Samsung SVL <[email-masked]>; [email-masked] 
>Sent: Monday, 2 December 2013, 18:10

---

From: Dave Cridland <[email-masked]>
Date: Tue, 3 Dec 2013 05:52:27 +0000

Just to remind folk, the update to RFC 4551 - now also documenting QRESYNC
as well - is currently in Working Group Last Call, which ends on the 6th of
December.

https://ietf.org/doc/draft-ietf-qresync-rfc5162bis/

If you think this needs to be clearer in the new document, please let the
document authors, and the mailing list at [email-masked] know.

On Tue, Dec 3, 2013 at 12:02 AM, Samsung SVL <[email-masked]> wrote:

>   ------------------------------
>  *From:* Chris Newman <[email-masked]>
> *To:* Samsung SVL <[email-masked]>; [email-masked]
> *Sent:* Monday, 2 December 2013, 18:10
>
> *Subject:* Re: [lemonade] Regarding CONDSTORE IMAP extension
>

---

From: Samsung SVL <[email-masked]>
Date: Tue, 3 Dec 2013 14:21:17 -0800 (PST)

Hi Dave/Alexy,

I have gone through the https://ietf.org/doc/draft-ietf-qresync-rfc5162bis/ draft. Regarding the issue reported earlier, some server explicitly expects ENABLE command to increment the HIGHESTMODSEQ and some server automatically increments. To make the thing clear and also to follow the consistent behavior across various IMAP clients. It would be better to insist a point about enabling the CONDSTORE service in the server by sending ENABLE CONDSTORE command.

So, even-though server advertises the supported capability, its client responsibility to send ENABLE CONDSTORE command to enable the service. In case, if IMAP server did not support the ENABLE extension, then how client should enable the service can also mentioned to make it clear for client implementation. 

Please consider and if you feel its worthy, kindly update the draft. 

Regards,
Jay

> From: Dave Cridland <[email-masked]>
>Cc: Chris Newman <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Tuesday, 3 December 2013, 0:52
>Just to remind folk, the update to RFC 4551 - now also documenting QRESYNC as well - is currently in Working Group Last Call, which ends on the 6th of December.
>
>
>If you think this needs to be clearer in the new document, please let the document authors, and the mailing list at [email-masked] know.
>
>
>
>>>> As
 per RFC 4551,  client issues SELECT command  for a mailbox in the
>>>flag
 changes, that server may have a bug, so you may have to fallback to