Windows Mobile 5 - HTML formatted message

Take your Zimbra with you!
4534eddie
Posts: 27
Joined: Fri Sep 12, 2014 10:04 pm

Windows Mobile 5 - HTML formatted message

Post by 4534eddie »

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

Message-Id:

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

Message-Id:

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
Elite member
Elite member
Posts: 1410
Joined: Fri Sep 12, 2014 9:52 pm

Windows Mobile 5 - HTML formatted message

Post by 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.
4534eddie
Posts: 27
Joined: Fri Sep 12, 2014 10:04 pm

Windows Mobile 5 - HTML formatted message

Post by 4534eddie »

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
Elite member
Elite member
Posts: 1410
Joined: Fri Sep 12, 2014 9:52 pm

Windows Mobile 5 - HTML formatted message

Post by 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...
4534eddie
Posts: 27
Joined: Fri Sep 12, 2014 10:04 pm

Windows Mobile 5 - HTML formatted message

Post by 4534eddie »

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

Message-Id:

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

Message-Id:

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
4534eddie
Posts: 27
Joined: Fri Sep 12, 2014 10:04 pm

Windows Mobile 5 - HTML formatted message

Post by 4534eddie »

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
Elite member
Elite member
Posts: 1410
Joined: Fri Sep 12, 2014 9:52 pm

Windows Mobile 5 - HTML formatted message

Post by 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.
4534eddie
Posts: 27
Joined: Fri Sep 12, 2014 10:04 pm

Windows Mobile 5 - HTML formatted message

Post by 4534eddie »

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):

[quote]

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.


[/quote]
dkarp
Elite member
Elite member
Posts: 1410
Joined: Fri Sep 12, 2014 9:52 pm

Windows Mobile 5 - HTML formatted message

Post by dkarp »

[quote user="4534eddie"]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.[/QUOTE]

Yes. If there's a 4.0.5, this change will be in it.
dkarp
Elite member
Elite member
Posts: 1410
Joined: Fri Sep 12, 2014 9:52 pm

Windows Mobile 5 - HTML formatted message

Post by dkarp »

[quote user="4534eddie"]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.[/QUOTE]

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!
Post Reply