I reported (but forgot to make publicly visible) bug 6326 in early March: the Zimbra IMAP server has a serious bug, IMO, in that it fails to add a newline to the end of messages which do not have a trailing newline in the Zimbra message store. While this bug doesn't cause problems with, e.g., Thunderbird, it does cause issues with fetchmail:

Code:
fetchmail: IMAP> A0008 FETCH 1 BODY.PEEK[TEXT]
fetchmail: IMAP< * 1 FETCH (BODY[TEXT] {1354}
 (1354 body octets) .fetchmail: IMAP< A0008 OK FETCH completed
fetchmail: message ericding@foo.net@mail.foo.net:1 was not the expected length (3338 actual != 3335 expected)
 not flushed
The visible result is that any such message (which includes, it seems, all messages from outside servers) winds up getting an extra right paren tagged on at the end. I'm fairly certain this is a bug in the Zimbra IMAP implementation, if I read RFC3501 properly:

All interactions transmitted by client and server are in the form of lines, that is, strings that end with a CRLF. The protocol receiver of an IMAP4rev1 client or server is either reading a line, or is reading a sequence of octets with a known count followed by a line.
So far, the bug remains unconfirmed in Bugzilla; should I just realistically expect that it remain so for the near future?