149 lines
3.5 KiB
Plaintext
149 lines
3.5 KiB
Plaintext
MBOX-Line: From brong at fastmail.fm Wed Oct 8 13:57:25 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: <CABa8R6vvkxLipPcyzgAV7SfVMFVRdHpUjL6E=Z=GVdVwqOEhhg@mail.gmail.com>
|
|
References: <CAByrE3HvB=XbamJfTeDPPjLkYdhFOOz919GLJ5LN8xUgXBGpqA@mail.gmail.com>
|
|
<CABa8R6vvkxLipPcyzgAV7SfVMFVRdHpUjL6E=Z=GVdVwqOEhhg@mail.gmail.com>
|
|
Message-ID: <1412801845.1837100.176764181.7CE1D3B0@webmail.messagingengine.com>
|
|
|
|
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);
|
|
|
|
/* [1]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
|
|
|
|
References
|
|
|
|
1. http://www.rfc-editor.org/errata_search.php?rfc=5162
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20141009/10b1a332/attachment.html>
|