MBOX-Line: From jguthrie at brokersys.com  Fri Jan 30 15:29:04 2015
To: imap-protocol@u.washington.edu
From: Jonathan Guthrie <jguthrie@brokersys.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: <54CC13C0.4010408@brokersys.com>

The closing parenthesis comes immediately after the last character of 
the last message attribute.  The message attribute before the 
parenthesis in the gmail responses is the message header, which ends in 
two newlines.  The last message attribute in the Zimbra response is the 
flags which ends in a parenthesis.

If Zimbra chose to respond with the message attributes in the same order 
as gmail, then it would look exactly the same as the gmail response.

So, assuming that the literal character counts in the gmail responses 
are accurate (I'm not going to count them to make sure) your response 
processing is broken.  When you get to the end of a message attribute, 
you should expect to either see a space, indicating that you haven't run 
out of message attributes, or a closing parenthesis.

On 1/30/2015 4:52 PM, Rick Sanders 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
>


