Plain text view shows no attachments in iPad mails - Make TB more tolerant to incorrect MIME structure: Show attachments also if multipart/mixed is not at the top level (and attachment sits in alternative part)

NEW
Unassigned

Status

MailNews Core
MIME
--
enhancement
7 months ago
7 days ago

People

(Reporter: acab, Unassigned)

Tracking

(Blocks: 2 bugs)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

7 months ago
Created attachment 8864992 [details]
ipad-mail.eml

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170414223958

Steps to reproduce:

The attached mail is a simplified test case of a set of actual mails that I've received, which were generated by "iPad Mail (14E304)".



Actual results:

When thunderbird is configured to show message body as plain text, the attachments are not available (the attachments pane is missing entirely).
When thunderbird is configured to show message body as either simple html or original html, the attachments are shown and available for download.


Expected results:

Thunderbird 52.1 appears to blindly obey the mime structure as set up by the sender, no matter how stupid.
I agree that the sender should do a better job but this is email and relying on others never really works.
In particular, hiding the attachment pane (and the attachment icon too) severely cripples the plain text view.
I frankly preferred the behaviour of Thunderbird 45.8 which did show all the attachments regardless of the mixed part they were attached to.

Thanks for the great product!
(Reporter)

Comment 1

7 months ago
Created attachment 8864994 [details]
no attachments in plain text view
(Reporter)

Comment 2

7 months ago
Created attachment 8864996 [details]
attachments shown in simple and original html view
Attachment #8864992 - Attachment mime type: message/rfc822 → text/plain
This behaviour is to be expected given the incorrect MIME structure of the message. It is:

multipart/alternative
  text/plain
  multipart/mixed
    text/html
    attachment

So when selecting the plain part, you don't see the attachment associated with the alternative part.

The message structure should be:

multipart/mixed
  multipart/alternative
    text/plain
    text/html
  attachment

I'll attach a message in a minute where you can see that TB works with the correct MIME structure.

Log a bug with Apple ;-)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → INVALID
Created attachment 8865089 [details]
E-Mail with better MIME structure

Reading your comment #0 in detail now:

TB 45.x did not access the plain text part in the message, instead it stripped down the HTML part and showed that as plain text (dataloss, no?). We fixed that, but of course, every *fix* we make breaks someone's workflow, like:

https://xkcd.com/1172/ ;-) - No offence intended.
(Reporter)

Comment 5

7 months ago
Hi Jorg,
thanks for the quick answer.

My "workflow" is simply to read mails in plain text view which is found under "View / Message body as" (as opposed to some obscure "about:config" entry) and expect to see attachments like it has been the case since forever.

As I said, I understand the MIME structure and I agree that the sender should format the message properly.
But that said, I don't understand if TB aims at being a MUA or a MIME lint tool.
If you want to be a MUA you'll have to expect and accept the fact that others, especially the big and arrogant ones, won't (and sometimes will plain refuse to) be complying. Frankly, if I look at your respective market shares, it's clear to me who has to adapt to who. No offence intended.

Now, if you have a second look at the reduced test case I've attached, you can easily see that there are a few clear giveaways about the fact that the attachment is indeed intended as an attachment, the most obvious being: "Content-Disposition: attachment"
If you care about plain text viewers, you can use those hints and show the attachments.
If you don't (that's fine for the same "market share" reasons I've quoted above), you should really drop plain text view from TB as, as a result of the mime fix, it has become very misleading.

Thanks again for your time
OK, I can reopen this, but I'm afraid we won't have manpower to fix this.
Severity: normal → enhancement
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
Summary: Plain text view shows no attachments in iPad mails → Plain text view shows no attachments in iPad mails - Make TB more tolerant to incorrect MIME structure: Show attachments also if multipart/mixed is not at the top level (and attachment sits in alternative part)
Status: REOPENED → NEW
(Reporter)

Comment 7

7 months ago
Thanks Jorg.
If time permits, I may be able to work on a patch.

Updated

7 months ago
Component: Message Reader UI → MIME
Product: Thunderbird → MailNews Core
Version: 52 Branch → 52

Comment 8

7 months ago
Just a note:
Bug 602718 is about a slightly different problem with the MIME type 'multipart/related'.
As a solution, a fourth view ('All Body Parts') was introduced.
These must be activated with the Pref:
'mailnews.display.show_all_body_parts_menu'

Updated

6 months ago
See Also: → bug 1367973

Updated

6 months ago
Blocks: 505172
See Also: → bug 1386585
Check bug 1386585 comment #19 to see that attachments in this MIME structure

  multipart/alternative
    text/plain
    multipart/mixed
      text/html
      large ZIP file attachment
      text/html

take very long to open.
Blocks: 1405234

Comment 10

7 days ago
(In reply to Alfred Peters from comment #8)
> Bug 602718 is about a slightly different problem with the MIME type
> 'multipart/related'.
> As a solution, a fourth view ('All Body Parts') was introduced.
> These must be activated with the Pref:
> 'mailnews.display.show_all_body_parts_menu'

The addon <https://addons.mozilla.org/en-us/thunderbird/addon/show-all-body-parts/> will do that. But in addition to listing all MIME sections as attachments, it appends to the plaintext mail body all the html MIME sections.

The result is more of a technical view than an everyday-usable plaintext mode.
You need to log in before you can comment on or make changes to this bug.