124 lines
4.3 KiB
Plaintext
124 lines
4.3 KiB
Plaintext
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>
|