100 lines
3.8 KiB
Plaintext
100 lines
3.8 KiB
Plaintext
MBOX-Line: From blong at google.com Fri Jan 30 15:23:17 2015
|
|
To: imap-protocol@u.washington.edu
|
|
From: Brandon Long <blong@google.com>
|
|
Date: Fri Jun 8 12:34:53 2018
|
|
Subject: [Imap-protocol] Zimbra and FETCH response
|
|
In-Reply-To: <54CC0B1A.5040701@earthlink.net>
|
|
References: <54CC0B1A.5040701@earthlink.net>
|
|
Message-ID: <CABa8R6uyNCm=fDhVk8-H5+-73kF_bjFu_Vijz7wVy1fSYaxRmw@mail.gmail.com>
|
|
|
|
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>
|