MBOX-Line: From blong at google.com  Wed Oct  8 14:07:18 2014
To: imap-protocol@u.washington.edu
From: Brandon Long <blong@google.com>
Date: Fri Jun  8 12:34:53 2018
Subject: [Imap-protocol] Gmail IMAP responses are sporadically missing
	fields
In-Reply-To: <1412801845.1837100.176764181.7CE1D3B0@webmail.messagingengine.com>
References: <CAByrE3HvB=XbamJfTeDPPjLkYdhFOOz919GLJ5LN8xUgXBGpqA@mail.gmail.com>
	<CABa8R6vvkxLipPcyzgAV7SfVMFVRdHpUjL6E=Z=GVdVwqOEhhg@mail.gmail.com>
	<1412801845.1837100.176764181.7CE1D3B0@webmail.messagingengine.com>
Message-ID: <CABa8R6vHP9bgYe+7OW=HYt99VuFp2cRL6JF0Cx29QWCs+098dQ@mail.gmail.com>

Do you know which client has the problem with including the UID?

It sounds like clients like the one that prompted this question may skip
results that don't have a UID in them, and of course you won't get these
updates on a regular FETCH (well, I guess you could, but our impl doesn't
do that since we rolled the flag updates into the sync point updates).

merging the fetch with the flags updates would be complicated without some
much more heavy-weight changes.

Brandon

On Wed, Oct 8, 2014 at 1:57 PM, Bron Gondwana <brong@fastmail.fm> wrote:

>  On Thu, Oct 9, 2014, at 07:37 AM, Brandon Long wrote:
>
> We're seeing several reports of programs not expected extra FETCH
> responses, which we rolled out on Monday.  We're rolling back soon, since
> older versions of a very popular client are having issues (though not to
> our knowledge with this part of things).
>
>
> Yeah, it's annoying that so many clients don't handle legal IMAP responses.
>
>
> If you do:
> UID FETCH 299 (X-GM-MSGID X-GM-THRID)
>
> You can get:
> * 50 FETCH (UID 299 X-GM-MSGID 1231234123134 X-GM-THRID 1234123123413)
> * 50 FETCH (UID 299 FLAGS (\Seen))
>
>
> IN _theory_ this should be:
>
> * 50 FETCH (UID 299 X-GM-MSGID 1231234123134 X-GM-THRID 1234123123413)
> * 50 FETCH (FLAGS (\Seen))
>
> I wanted to always include the UID, but apparently there are clients that
> have trouble with THAT too, which is why our index_printflags function in
> Cyrus (called for unsolicited updates) looks like this:
>
>     index_fetchflags(state, msgno);
>     /* http://www.rfc-editor.org/errata_search.php?rfc=5162
>      * Errata ID: 1807 - MUST send UID and MODSEQ to all
>      * untagged FETCH unsolicited responses */
>     if (usinguid || (client_capa & CAPA_QRESYNC))
>         prot_printf(state->out, " UID %u", im->uid);
>     if (printmodseq || (client_capa & CAPA_CONDSTORE))
>         prot_printf(state->out, " MODSEQ (" MODSEQ_FMT ")", im->modseq);
>     prot_printf(state->out, ")\r\n");
>
>
> if the user has just read the message.  I believe that's correctly in spec
> and that other IMAP servers would do the same, unless they suppress updates
> on FETCH responses.
>
>
> Yes, you're definitely allowed to either do that OR roll the FETCH update
> into the same response line. We roll them together in Cyrus.  The magic is
> here:
>
>     /* display flags if asked _OR_ if they've changed */
>     if (fetchitems & FETCH_FLAGS || im->told_modseq < record.modseq) {
>         index_fetchflags(state, msgno);
>         sepchar = ' ';
>     }
>
> And of course in index_fetchflags itself we keep track of the modseq we
> told.
>
> [...]
>     if (sepchar == '(') (void)prot_putc('(', state->out);
>     (void)prot_putc(')', state->out);
>     im->told_modseq = im->modseq;
> }
>
> The unsolicited updates loop itself does likewise:
>
>     /* print any changed message flags */
>     for (msgno = 1; msgno <= state->exists; msgno++) {
>         im = &state->map[msgno-1];
>
>         /* report if it's changed since last told */
>         if (im->modseq > im->told_modseq)
>             index_printflags(state, msgno, printuid, printmodseq);
>     }
>
> So I would recommend for your testing that you try not sending the UID
> with unsolicited flags responses (yeah, I know) if the client hasn't
> enabled
> QRESYNC.  Of course, if you can merge the responses, even better.
>
> Cheers,
>
> Bron.
>
> --
> Bron Gondwana
> brong@fastmail.fm
>
>
>
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20141008/f64dd200/attachment.html>
