AquaMail Forum

English - Android => Bug reports => Topic started by: Darek- on February 22, 2013, 10:58:17 am

Title: 1.2.2/1.2.2.7 - Content-type text/html displayed as text/plain
Post by: Darek- on February 22, 2013, 10:58:17 am

I have mail with:

Code: [Select]

Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64
Precedence: bulk
X-no-archive: yes

PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTUwJTsgY29sb3I6IGdyZWVuOyBmb250LXdlaWdodDog
Ym9sZDsiPm5hIGR6aXNpYWovanV0cm86IDI8L3NwYW4+PHRhYmxlIGJvcmRlcj0iMSIgc3R5bGU9
So after base64 decoding its incorrectly formated HTML beginning with span tag without HTML header:

Code: [Select]

<span style="font-size: 150%; color: green; font-weight: bold;">and AquaMail (SGS2 Android 4.1.2 AM 1.2.2 & GT 8.9 Android 4.0.4) display this as text/plain.
I know this is bad HTML, but I think this still should be displayed as HTML and not plain text.

Title: Re: 1.2.2/1.2.2.7 - Content-type text/html displayed as text/plain
Post by: Kostya Vasilyev on February 24, 2013, 02:31:16 am

I assume this is an IMAP mail server.

The app's treatment of html vs. plain text is determined by what the server returns as the mime type for this particular message part.

Please:

1 - enable logging in the app, make sure to include "raw data": http://www.aqua-mail.com/?page_id=232
2 - open the message
3 - use Menu / Diag: reload (last item in the menu) to generate the info I need
4 - send the log to kmansoft / at sign / gmail / dot com

Title: Re: 1.2.2/1.2.2.7 - Content-type text/html displayed as text/plain
Post by: Darek- on February 24, 2013, 01:14:32 pm

Quote from: Kostya Vasilyev, Aqua Mail on February 24, 2013, 02:31:16 am

I assume this is an IMAP mail server.

The app's treatment of html vs. plain text is determined by what the server returns as the mime type for this particular message part.

You are right - this is IMAP (Courier IMAP).
And I think I found true source of this problem - this mail don't have (mandatory for use of Content-Type:) MIME-Version: header.
So Courier return:
BODYSTRUCTURE ("text" "plain" NIL NIL NIL "base64" 1498 21 NIL NIL NIL) INTERNALDATE "22-Feb-2013 07:00:08 +0100")
and AquaMail use it.

Looks like Thunderbird (and many other mail clients) not use BODYSTRUCTURE in strict way and use headers anyway.
Also not all IMAP servers parse this kind of error in message same way (as I found Dovecot will return text/html in BODYSTRUCTURE even without MIME-Version).
But if HTML have HTML header then AquaMail display HTML, probably using MIME guessing?
So I ask programmer to fix generated mail, but I send you logs too.

In logfile there are two log session.
First is wrongly formated HTML (displayed as text/plain).
BODYSTRUCTURE ("text" "plain" NIL NIL NIL "base64" 1498 21 NIL NIL NIL) INTERNALDATE "22-Feb-2013 07:00:08 +0100")
Second is a bit fixed version - programmer add HTML header to the body - now it's displayed as HTML, only with wrong charset encoding (no meta http-equiv in body - this probably fix this issue).
BODYSTRUCTURE ("text" "plain" NIL NIL NIL "base64" 1792 24 NIL NIL NIL) INTERNALDATE "22-Feb-2013 09:25:27 +0100")

Darek

Title: Re: 1.2.2/1.2.2.7 - Content-type text/html displayed as text/plain
Post by: Darek- on February 24, 2013, 08:29:31 pm

We agree with Kostya by mail - that this is not AquaMail issue.
So I think this case can be closed now :)

Title: Re: 1.2.2/1.2.2.7 - Content-type text/html displayed as text/plain
Post by: Kostya Vasilyev on February 25, 2013, 02:21:36 am

Turns out the source of the issue is -- technically -- malformed messages, and Courier IMAP's very strict message parser.

If the message is lacking "MIME-Version: 1.0", then Courier will treat the whole message as a piece of "text/plain" content.

Furthermore, even the "charset=xxx" part common found in the "Content-Type:" header these days (e.g. "utf-8") is a MIME attribute, and will be ignored by Courier and not reported to the app in this case.

( I never thought "charset=xxx" had anything to do with MIME... shows how little i know about email... )

This seems to be an intentional decision on part of Courier developers, can't really argue with that.