 Hey, not our bug!
I think you've misread RFC 3501. The RFC does not mandate that every piece of data returned by the server be CRLF-terminated, it just mandates that the server CRLF-terminate every server response, either tagged or untagged. The message body is *part* of a response, and thus the server really shouldn't be tacking on extra CRLFs.
For instance, if fetchmail had sent a command along the lines of
A0008 FETCH 1 (BODY.PEEK[TEXT] FLAGS)
the Zimbra IMAP server would have to respond with
* 1 FETCH (BODY[TEXT] {1354}<CRLF>
<the 1354 octets that comprise the message> FLAGS (\Sent))<CRLF>
The close-parenthesis you're seeing is the mate to the one after "* 1 FETCH " at the beginning of the untagged response.
It seems that fetchmail is not taking the octet count and reading that number of bytes off the wire, but is instead taking the octet count and reading *lines* until it fills its expected buffer. This is completely wrong. Thunderbird gets it right.
That being said, if fetchmail has this bug, Zimbra needs to work around it. (Which version of fetchmail are you running?) I *think* we can tack on an extra CRLF to all message bodies, but we'll need to make sure that we're not breaking anything else in the process... |