Windows Mobile 5 - HTML formatted message

[eddie]

Looks like there's multiple problems here..

1. Linecount (fixed)
2. charset=us-ascii
3. single html part within the multipart

I've gotten readable email with charset=us-ascii on all text parts but only when there is no more than a single text/html part. If I have a message with multiple text/html parts, then WM5 fails to read it if it comes from zimbra but works with dovecot. The only other difference looking at the imap return using the exact fetch command that the WM5 client uses (used tcpflow) is that zimbra returns

("boundary" "__________MIMEboundary__________")

after "alternative" whereas dovecot does not.

Here is the full return with Zimbra:

08 fetch 9895 (INTERNALDATE UID FLAGS RFC822.SIZE BODY.PEEK[HEADER.FIELDS (DATE FROM SUBJECT MESSAGE-ID CONTENT-TYPE X-MS-TNEF-Correlator CONTENT-CLASS IMPORTANCE)] BODYSTRUCTURE)
* 9895 FETCH (UID 9996 FLAGS (\Seen) INTERNALDATE "13-Dec-2006 16:52:38 -0800" RFC822.SIZE 8713 BODYSTRUCTURE (("text" "html" ("charset" "us-ascii") NIL NIL "7bit" 4503 225 NIL NIL NIL)("text" "html" ("charset" "us-ascii") NIL NIL "7bit" 1242 30 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)] {289}
Date: Wed, 13 Dec 2006 16:52:36 -0800 (PST)
From: Super-User <root@somewhere.com>
Message-Id: <200612140052.kBE0qarT005135@somewhere.com>
Subject: test old results 6
Content-Type: multipart/alternative;
    boundary="__________MIMEboundary__________"

)
* 9865 FETCH (FLAGS (\Seen))
08 OK Fetch completed.

With dovecot:

08 fetch 5394 (INTERNALDATE UID FLAGS RFC822.SIZE BODY.PEEK[HEADER.FIELDS (DATE FROM SUBJECT MESSAGE-ID CONTENT-TYPE X-MS-TNEF-Correlator CONTENT-CLASS IMPORTANCE)] BODYSTRUCTURE)
* 5394 FETCH (UID 39257 INTERNALDATE "13-Dec-2006 16:52:36 -0800" RFC822.SIZE 8129 BODYSTRUCTURE (("TEXT" "HTML" ("CHARSET" "us-ascii") NIL NIL "7BIT" 4503 225)("TEXT" "HTML" ("CHARSET" "us-ascii") NIL NIL "7BIT" 1242 31) "ALTERNATIVE") BODY[HEADER.FIELDS (DATE FROM SUBJECT MESSAGE-ID CONTENT-TYPE X-MS-TNEF-CORRELATOR CONTENT-CLASS IMPORTANCE)] {290}
Date: Wed, 13 Dec 2006 16:52:36 -0800 (PST)
From: Super-User <root@somewhere.com>
Message-Id: <200612140052.kBE0qarT005135@somewhere.com>
Subject: test old results 6
Content-Type: multipart/alternative;
    boundary="__________MIMEboundary__________"

 FLAGS (\Seen))
08 OK FETCH completed

Perhaps the ("boundary" "__________MIMEboundary__________") is causing a problem but I have not figured out a way to test this.

I've checked RFC 2060 and RFC 3501 and neither mentions the boundary parameter. Also checked out RFC 1341 which defines multipart content-type and it's subtypes... will check some other possible causes around that.

[dkarp]

I think you have the two mixed up -- dovecot contains the more verbose output, while Zimbra doesn't. It's a question of returning the optional BODYSTRUCTURE fields. I'll try that tomorrow.

[eddie]

Hehe.. yes.. sorry. You are absolutely correct. I had two windows going and got them mixed up. Dovecot has the boundary parameter defined in the fetch response and Zimbra does not. It also has two extra NILL's at the end of each section but I don't expect that to do anything one way or the other.

[dkarp]

I've put back the BODYSTRUCTURE fixes to mainline and FRANK. If you've got a local build going, please sync in about an hour and let me know if that fixes things...

[eddie]

more data...

Here is the identical email where the only difference is the boundary= parameter is on the same line as the Content-Type: in the first case and on a second indented line int he second case. The email body only has a single text/html part. What's interesting here is the first one displays but the second one doesn't.

a11 fetch 5425:5426 (INTERNALDATE UID FLAGS RFC822.SIZE BODY.PEEK[HEADER.FIELDS (DATE FROM SUBJECT MESSAGE-ID CONTENT-TYPE X-MS-TNEF-Correlator CONTENT-CLASS IMPORTANCE)] BODYSTRUCTURE)
* 5425 FETCH (UID 39307 INTERNALDATE "14-Dec-2006 13:44:50 -0800" RFC822.SIZE 8079 BODYSTRUCTURE (("TEXT" "HTML" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 5674 251) "ALTERNATIVE") BODY[HEADER.FIELDS (DATE FROM SUBJECT MESSAGE-ID CONTENT-TYPE X-MS-TNEF-CORRELATOR CONTENT-CLASS IMPORTANCE)] {306}
Date: Thu, 14 Dec 2006 13:44:48 -0800 (PST)
From: Super-User <root@somewhere.com>
Message-Id: <200612142144.kBELimNG017931@somewhere.com>
Subject: WM5 mailresults5.txt - single html part
Content-Type: multipart/alternative; boundary="__________MIMEboundary__________"

 FLAGS (\Seen))
* 5426 FETCH (UID 39308 INTERNALDATE "14-Dec-2006 13:45:48 -0800" RFC822.SIZE 7903 BODYSTRUCTURE (("TEXT" "HTML" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 5674 251) "ALTERNATIVE") BODY[HEADER.FIELDS (DATE FROM SUBJECT MESSAGE-ID CONTENT-TYPE X-MS-TNEF-CORRELATOR CONTENT-CLASS IMPORTANCE)] {324}
Date: Thu, 14 Dec 2006 13:45:47 -0800 (PST)
From: Super-User <root@somewhere.com>
Message-Id: <200612142145.kBELjlMw017959@somewhere.com>
Subject: WM5 mailresults5.txt - single html part, boundary own line
Content-Type: multipart/alternative;
 boundary="__________MIMEboundary__________"

 FLAGS (\Seen))
a11 OK FETCH completed

when downloaded from dovecot, both work

[eddie]

just verified that by simply putting the boundary parameter on the same line as Content-type:, multipart/alternative contaning 1 text/plain and 2 text/html parts display at least the plain part on WM5 client. I suspect that if the boundary parameter is parsed and inserted into the bodystructure return, the whole username/wm hack would be unnecessary.

[dkarp]

Our QA team has said that the BODYSTRUCTURE change fixed the problem! Thanks very much for helping us figure this out!

You may still want to use the "/wm" hack to map the "Sent Items" folder on the WM5 device to the Zimbra "Sent" folder.

[eddie]

Great! Any possibility this will make it into a 4.0.x release? It'd be nice to not have to wait until 4.5.

BTW, found the RFC reference in 2060 (and 3501):

Extension data follows the multipart subtype.
Extension data is never returned with the BODY
fetch, but can be returned with a BODYSTRUCTURE
fetch. Extension data, if present, MUST be in the
defined order.

The extension data of a multipart body part are in
the following order:

body parameter parenthesized list
A parenthesized list of attribute/value pairs
[e.g. ("foo" "bar" "baz" "rag") where "bar" is
the value of "foo" and "rag" is the value of
"baz"] as defined in [MIME-IMB].

body disposition
A parenthesized list, consisting of a disposition type
string, followed by a parenthesized list of disposition
attribute/value pairs as defined in [DISPOSITION].

body language
A string or parenthesized list giving the body language
value as defined in [LANGUAGE-TAGS].

body location
A string list giving the body content URI as defined in
[LOCATION].

Any following extension data are not yet defined in this
version of the protocol. Such extension data can consist of
zero or more NILs, strings, numbers, or potentially nested
parenthesized lists of such data. Client implementations that
do a BODYSTRUCTURE fetch MUST be prepared to accept such
extension data. Server implementations MUST NOT send such
extension data until it has been defined by a revision of this
protocol.

[dkarp]

Originally Posted by eddie

Great! Any possibility this will make it into a 4.0.x release? It'd be nice to not have to wait until 4.5.

Yes. If there's a 4.0.5, this change will be in it.

[dkarp]

Originally Posted by eddie

Great! Any possibility this will make it into a 4.0.x release? It'd be nice to not have to wait until 4.5.

You're in luck! I managed to squeeze this bug fix into 4.0.5. Please let me know if it resolves the issue for you!