There's nothing wrong with the order in which Zimbra is returning things.
That said, Gmail originally returned fetch attributes in the order they
were requested, but we ran into issues with some clients, so now we return
them in reverse sorted alphabetical order.
ahh, here's the bug we were working around:
https://bugzilla.mozilla.org/show_bug.cgi?id=272988
we needed to return RFC822.SIZE before BODY or Thunderbird had a cow.
Anyways, sorting also makes testing more consistent.
Anyhoo, you should be matching the parenthesis. IMAP responses, especially
FETCH ones, kind of require you to actually parse the results and not use
something simplistic.
Brandon
On Fri, Jan 30, 2015 at 2:52 PM, Rick Sanders <rfs9999@earthlink.net> wrote:
> Hi,
>
> This may be due to my incomplete understanding of the IMAP RFC. My
> apologies if that's the case.
>
> The most recent release of Zimbra has changed to the way it closes its
> response to FETCH. Previously when FETCHING various items the response for
> each message would be terminated by ')' on a new line. That's what I have
> used for years and it works for all other servers I have worked with
> (Gmail, Dovecot, CommuniGate, Openwave, etc). But not Zimbra now.
>
> >> 1 FETCH 1:* (uid flags internaldate RFC822.SIZE body.peek[header.fields
> (From Date Message-Id Subject)])
>
> For example here is what Gmail sends:
>
> << * 1 FETCH (UID 23910 RFC822.SIZE 17599 INTERNALDATE "16-Jan-2015
> 19:28:27 +0000" FLAGS (NonJunk) BODY[HEADER.FIELDS (From Date Message-Id
> Subject)] {211}
> << From: comp.mail.pine@googlegroups.com
> << Subject: Digest for comp.mail.pine@googlegroups.com - 2 updates
> << Message-ID: <e89a8f92403a1c5886050cc9fa6d@google.com>
> << Date: Fri, 16 Jan 2015 19:28:27 +0000
> <<
> << )
> << * 2 FETCH (UID 23911 RFC822.SIZE 14881 INTERNALDATE "16-Jan-2015
> 20:30:20 +0000" FLAGS (NonJunk) BODY[HEADER.FIELDS (From Date Message-Id
> Subject)] {210}
> << From: comp.mail.imap@googlegroups.com
> << Subject: Digest for comp.mail.imap@googlegroups.com - 1 update
> << Message-ID: <485b397dd00762fb3c050ccad70b@google.com>
> << Date: Fri, 16 Jan 2015 20:30:20 +0000
> <<
> << )
>
> In contrast Zimbra sends:
>
> << * 1 FETCH (UID 10191 INTERNALDATE "03-Dec-2014 10:10:53 -0200"
> RFC822.SIZE 9219 BODY[HEADER.FIELDS (FROM DATE MESSAGE-ID SUBJECT)] {238}
> << From: joe <joe@abc.com>>
> << Subject: test message
> << Date: Wed, 3 Dec 2014 10:10:07 -0200
> << Message-ID: <201412031009340.006629001417608574@pmta05>
> 01-30-2015.19:38:32 <<
> 01-30-2015.19:38:32 << FLAGS (\Recent))
> 01-30-2015.19:38:32 << 1 OK FETCH completed
>
> The last line of the response is FLAGS not ')'. I've had to add special
> logic when Zimbra is involved to consider FLAGS as the end.
>
> One of my customers recently upgraded to Zimbra and immediately the
> application had used for years stopped working. :-) And other Zimbra
> users have reported the problem to me as well.
>
> What am I missing or doing wrong?
>
> Thanks,
> Rick
>
> --
> Rick Sanders
> rfs9999@earthlink.net
> IMAP Tools http://www.athensfbc.com/imap-tools
> _______________________________________________
> 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/20150130/9fdec190/attachment.html>