780081 - Multipart/alternative - can't view the body, because boundary parameter is not written in Content-Type: multipart/alternative header by mail application (bug of ZeXtras Mobile which will be fixed by ZeXtras 1.4.2)

Status: RESOLVED INVALID

(Thunderbird :: General, defect)

Description

[Alessandro]

Attachment: Testcase1.eml: not viewable message

I forward a simple email to me with my android smarthphone.
I can't view the body of the forwarded email, but I can see the source.

I can repeat the problem with more than one android smartphone (standard email client) and with more thunderbird 14 installation (linux and windows, 32/64 bit, all in IMAP).

I try with all the following settings: view=>body=>orig.html/simple html/simple text 

Webmail views the email correctly as expected; few lines of greeting with the text of the first forwarded email (with his text, from, to and date headers).

I attached the .eml
I'm don't understand the problem, but I see "X-Amavis-Alert: BAD HEADER SECTION, MIME..." so it seems to me that boundary="----=_Part_1_1343962909440" is missing after the "multipart/alternative" (if I put it in the eml file then it seems I can open it correctly!)

If so, it seems that tb works fine and the email is wrong, but I note that:
- webmail works fine (it is zimbra)
- outlook views the entire email as simple text with all his headers 
- many android smarthphones send this kind of email (the last one also)

It seem the 769447 but I'm not sure

Comment 1

[WADA:World Anti-bad-Duping Agency]

(In reply to Alessandro from comment #0)
> Testcase1.eml: not viewable message

Mail structure.
> Content-Type: multipart/alternative
> Message-ID: <[e-mail]>
> X-Mailer: Zimbra 7.2.0_GA_2669
>
> ------=_Part_1_1343962909440
> Content-Type: text/plain; charset= utf-8
> Content-Disposition: inline
>
> ------=_Part_1_1343962909440
> Content-Type: text/html; charset= utf-8
> Content-Disposition: inline
>
> ------=_Part_1_1343962909440
> Content-Type: message/rfc822
> Content-Disposition: attachment
>
>      (Structure of correctly formatted mail which sender wants to forward)
>      Content-Type: multipart/alternative; boundary="----=_Part_1_1343962861104"
>      ------=_Part_1_1343962861104
>      Content-Type: text/plain;  charset= utf-8
>      Content-Disposition: inline
>      ------=_Part_1_1343962861104
>      Content-Type: text/html; charset= utf-8
>      Content-Disposition: inline
>      ------=_Part_1_1343962861104--
>
> ------=_Part_1_1343962909440--

(1) As you say, no boundary parameter in Content-Type: multipart/alternative.
    i.e. Accessible sub part of multipart is not contained in this mail. 
    Avast! at destination server looks to have detected it.
    If Content-Type: header is changed to following,
       Content-Type: multipart/mixed; boundary="----=_Part_1_1343962909440"
    user can see mail contents, although both text/plain part and text/html part
    are shown at same time by normal/ordinal mailers.
Note:
When Content-Type: multipart/alternative; boundary="...", I don't know whether Tb selects message/rfc822 part as an alternative in multipart/alternative or not. If message/rfc822 part is not an displayable alternative in multipart/alternative for Tb, recent Tb perhaps tries to show the bad message/rfc822 part under multipart/alternative as if attachment at attachment pane, but I don't know actual Tb's behavior.

(2) Mail application looks trying to forward a mail as attachment
    with two versions of message body(text/plain and text/html).
    However, structure of mail is never for it.
    Application programmer of the mail app doesn't seem to have sufficient
    knowledge on mime or multipart(multipart/mixed, multipart/alternative,
    multipart/related) for creating mail application.
    He probably creates program without any manual reading always.

> - webmail works fine (it is zimbra)
> - outlook views the entire email as simple text with all his headers 

If so, this kind of mail is very convenient for "attacking users of the Web mail only" :-)

Comment 2

[Thomas D. (:thomas8)]

I understand that this not a TB bug, but a malformed msg.

So the question is, is there a simple way to work around malformedness and display something more useful than nothing?
Do we want to accept this malformedness for reading (reporter claims it occurs with many Android smartphones)?

Otherwise, my impression is that we need to draw a line somewhere and mark this invalid (not a TB bug).

Comment 3

[Alessandro]

I'm agree it is not a TB bug.

It seems to me that android fails forwarding email only if it is using a zimbra account (with the Zextras plugin; an Exchange compatibility layer)
No problem for gmail (or others, I suppose)

So I can understand why I can't find people with the same problem: it is a very specific case, and I think that very few people are involved.

Alessandro

Comment 4

[Thomas D. (:thomas8)]

WADA, in view of comment 3 (not a TB bug, malformed msg), could you answer my comment 2:

(In reply to Thomas D. from comment #2)
> So the question is, is there a simple way to work around this malformedness and
> display something more useful than nothing?
> Do we want to accept this malformedness for reading (reporter claims it
> occurs with many Android smartphones)?
> 
> Otherwise, my impression is that we need to draw a line somewhere and mark
> this invalid (not a TB bug).

Wada, could you pls take a decision here, either morph this into RFE (enable TB to cope with malformed msg for reading), or close as invalid.

Comment 5

[Alessandro]

The problem is solved: the ZeXtras team has modified its zimbra plugin, now the emails are written in the correct form by android, so thunderbird is able to show them correctly.

The decision to show (or not) the body of an incorrect email still remain.

In my -little- experience there is no other cases like this, and all emails show something in them bodies

Alessandro

Comment 6

[Jim Porter (:squib)]

Based on comments 3 and 5, closing as invalid.

As an aside, the sheer number of ways that mailers produce broken messages continually astounds me.

Comment 7

[Thomas D. (:thomas8)]

(In reply to Jim Porter (:squib) from comment #6)
> Based on comments 3 and 5, closing as invalid.
Thanks! :)

Comment 8

[WADA:World Anti-bad-Duping Agency]

FYI.
Following looks bug report by Alessandro about correct software at correct place.
> http://forums.zextras.com/zxmobile/284-problem-android-forwarding-emails.html

Comment 9

[Thomas D. (:thomas8)]

(In reply to WADA from comment #8)
> FYI.
> Following looks bug report by Alessandro about correct software at correct
> place.
> > http://forums.zextras.com/zxmobile/284-problem-android-forwarding-emails.html

Thanks WADA, great research as ever. :)