166 lines
5.6 KiB
Plaintext
166 lines
5.6 KiB
Plaintext
MBOX-Line: From brong at fastmail.fm Wed Oct 8 15:16:08 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bron Gondwana <brong@fastmail.fm>
|
|
Date: Fri Jun 8 12:34:53 2018
|
|
Subject: [Imap-protocol] Gmail IMAP responses are sporadically missing
|
|
fields
|
|
In-Reply-To: <CABa8R6vHP9bgYe+7OW=HYt99VuFp2cRL6JF0Cx29QWCs+098dQ@mail.gmail.com>
|
|
References: <CAByrE3HvB=XbamJfTeDPPjLkYdhFOOz919GLJ5LN8xUgXBGpqA@mail.gmail.com>
|
|
<CABa8R6vvkxLipPcyzgAV7SfVMFVRdHpUjL6E=Z=GVdVwqOEhhg@mail.gmail.com>
|
|
<1412801845.1837100.176764181.7CE1D3B0@webmail.messagingengine.com>
|
|
<CABa8R6vHP9bgYe+7OW=HYt99VuFp2cRL6JF0Cx29QWCs+098dQ@mail.gmail.com>
|
|
Message-ID: <1412806568.1857112.176792729.78B7A333@webmail.messagingengine.com>
|
|
|
|
On Thu, Oct 9, 2014, at 08:07 AM, Brandon Long wrote:
|
|
|
|
Do you know which client has the problem with including the UID?
|
|
|
|
|
|
|
|
I'm sorry, it's well and truly forgotten in the mists of time. I rewrote that section of the code about 6 years ago now.
|
|
|
|
|
|
|
|
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).
|
|
|
|
|
|
|
|
I'm assuming you'll get the FLAGS if you fetch them, of course.
|
|
|
|
|
|
|
|
merging the fetch with the flags updates would be complicated without some much more heavy-weight changes.
|
|
|
|
|
|
|
|
Yeah, that's a pity. As you could see from the C blocks I pasted before, I refactored the datastructures in Cyrus to make it trivial, taking advantage of (I would say leveraging, but I can't quite drag myself that low) the CONDSTORE data to track exactly which changes have already been told, and automatically adding FLAGS to the response for any record where they have changed.
|
|
|
|
|
|
|
|
The other thing that might be worth trying is holding off on unsolicited updates until after the solicited ones are finished.
|
|
|
|
|
|
|
|
TAG UID FETCH 299 (X-GM-MSGID X-GM-THRID)
|
|
|
|
* 50 FETCH (UID 299 X-GM-MSGID 1231234123134 X-GM-THRID 1234123123413)
|
|
|
|
TAG OK Completed
|
|
|
|
* 50 FETCH (UID 299 FLAGS (\Seen))
|
|
|
|
|
|
|
|
Of course that won't avoid dumb clients just seeing it as part of the response to the NEXT command, so maybe that doesn't work either :( Bloody IMAP clients.
|
|
Bron.
|
|
|
|
|
|
|
|
Brandon
|
|
|
|
|
|
On Wed, Oct 8, 2014 at 1:57 PM, Bron Gondwana <[1]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);
|
|
/* [2]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
|
|
[3]brong@fastmail.fm
|
|
|
|
|
|
|
|
|
|
_______________________________________________
|
|
|
|
Imap-protocol mailing list
|
|
|
|
[4]Imap-protocol@u.washington.edu
|
|
|
|
[5]http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
|
|
|
|
|
|
|
|
|
--
|
|
Bron Gondwana
|
|
brong@fastmail.fm
|
|
|
|
References
|
|
|
|
1. mailto:brong@fastmail.fm
|
|
2. http://www.rfc-editor.org/errata_search.php?rfc=5162
|
|
3. mailto:brong@fastmail.fm
|
|
4. mailto:Imap-protocol@u.washington.edu
|
|
5. 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/20141009/35c7d67e/attachment.html>
|