Ok, upgraded a while ago but WM5 clients are still seeing the problem. Also getting reports that evolution and another imap client on Mac OSX is having the same problem. I have not seen this first hand but can vouche for WM5 problems. I manage a server at work and at home so I've been able to compare. At home I use Dovecot. I have a multipart (text/plain + text/html) that I send to both accounts. I've verified that the line count from the "uid fetch ??? BODY" produces the right line count now. So I started digging deeper...
Using tcpflow I was able to capture the transation between the WM5 client and each of the servers. By examining these, I found some key differences. I'll use the convention of "C: ..." for client side send and "S: ..." for server response.
On Zimbra:
Code:
C: A8 FETCH 4508 (INTERNALDATE UID FLAGS RFC822.SIZE BODY.PEEK[HEADER.FIELDS (DATE FROM SUBJECT MESSAGE-ID CONTENT-TYPE X-MS-TNEF-Correlator CONTENT-CLASS IMPORTANCE)] BODYSTRUCTURE)
S: * 4508 FETCH (UID 32325 INTERNALDATE "09-Nov-2006 16:48:00 -0800" RFC822.SIZE 7936 BODYSTRUCTURE (("TEXT" "PLAIN" NIL NIL NIL "7BIT" 472 21)("TEXT" "HTML" NIL NIL NIL "7BIT" 5674 251) "ALTERNATIVE") BODY[HEADER.FIELDS (DATE FROM SUBJECT MESSAGE-ID CONTENT-TYPE X-MS-TNEF-CORRELATOR CONTENT-CLASS IMPORTANCE)] {297}
Date: Thu, 9 Nov 2006 16:47:59 -0800 (PST)
From: joeuser@somewhere.com
Subject: test email message
Message-ID: <40C8ECA7.1060503@somehost.somewhere.com>
Content-Type: multipart/alternative;
boundary="__________MIMEboundary__________"
FLAGS (\Seen)) On Zimbra:
Code:
C: A58 FETCH 2 (INTERNALDATE UID FLAGS RFC822.SIZE BODY.PEEK[HEADER.FIELDS (DATE FROM SUBJECT MESSAGE-ID CONTENT-TYPE X-MS-TNEF-Correlator CONTENT-CLASS IMPORTANCE)] BODYSTRUCTURE)
S: * 2 FETCH (UID 2 FLAGS (\Seen) INTERNALDATE "09-Nov-2006 16:48:01 -0800" RFC822.SIZE 8544 BODYSTRUCTURE (("text" "plain" ("charset" "us-ascii") NIL NIL "7bit" 472 21 NIL NIL NIL)("text" "html" ("charset" "us-ascii") NIL NIL "7bit" 5674 250 NIL NIL NIL) "alternative" ("boundary" "__________MIMEboundary__________") NIL NIL) BODY[HEADER.FIELDS (DATE FROM SUBJECT MESSAGE-ID CONTENT-TYPE X-MS-TNEF-CORRELATOR CONTENT-CLASS IMPORTANCE)] {296}
Date: Thu, 9 Nov 2006 16:47:59 -0800 (PST)
From: joeuser@somewhere.com
Subject: test email message
Message-ID: <40C8ECA7.1060503@somehost.somewhere.com>
Content-Type: multipart/alternative;
boundary="__________MIMEboundary__________"
) Since this is the identical message sent to two places, this shows differences of how each server handles the message and the request. Most of the differences seem pretty innocent and I've verified the WM5 makes the same decision on what the next command is which is to request the first section of the body and both servers produce very similar responses (the exception is that Zimbra does not output flags at the end of the body where dovecot does). The one I suspect is the problem is missing "("charset" "us-ascii")" section after the mime type on Zimbra. The reason I suspect this is that WM5 requests and gets the first section of the body which is consisted with dovecot. That means that WM5 *has* the text/plain part which is fine. The only reason I can think of that causes WM5 to show blank is that it doesn't know how to display what it has. Unfortunately, I have no way to verify my theory.
I'd be happy to help test any fix.
Bugzilla
Wiki
Source
Linear Mode
