nested multipart MIME messages not displayed properly (or at all)
Categories
(MailNews Core :: MIME, defect)
Tracking
(thunderbird149 affected)
| Tracking | Status | |
|---|---|---|
| thunderbird149 | --- | affected |
People
(Reporter: blilly, Assigned: maxe)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 external file)
|
30.48 KB,
text/plain
|
Details |
| Reporter | ||
Comment 1•23 years ago
|
||
Comment 2•23 years ago
|
||
Comment 3•23 years ago
|
||
| Reporter | ||
Comment 4•23 years ago
|
||
Comment 5•23 years ago
|
||
Comment 6•23 years ago
|
||
| Reporter | ||
Comment 7•22 years ago
|
||
Updated•22 years ago
|
Comment 8•22 years ago
|
||
| Reporter | ||
Comment 9•22 years ago
|
||
Comment 10•22 years ago
|
||
Updated•21 years ago
|
Comment 11•21 years ago
|
||
Comment 12•21 years ago
|
||
Comment 13•18 years ago
|
||
Updated•18 years ago
|
Updated•18 years ago
|
Comment 14•17 years ago
|
||
Comment 15•14 years ago
|
||
Comment 16•7 years ago
|
||
Importing (dragging) the attachment above into an imap mailbox on tb definitely has a problem. The two pdf attachments are OK but the two text parts, don't display or can't be downloaded (I see a message that text attachment is empty when clicked). However with evolution and claws mail on linux the message displays perfectly.
Reading the manyj comments above, it is not clear to me how the message is expected to display. However, when I look with evo or claws, it is structured like this:
< start evo or claws email display>
Normal From/To/Subject/Date Header
Plain text paragraph describing the email: This month's......regarding the meeting.
test text
test text
< end email display>
Both claws and evo show links (that all work) to the two text parts as well as the 2 pdf's to download.
Tb shows the email like this:
< start tb email display>
Normal From/To/Subject/Date Header
Plain text paragraph describing the email: This month's......regarding the meeting.
< end email display>
At the bottom, tb shows link single to text and 2 pdf's. The pdf's links are OK and work. The single text link says "attachment empty" when clicked.
Note: There is (I think) a new pref that disables showing text as inline that is set by default, mail.inline_attachments.text. Setting this true or false doesn't make a difference. Re: Bug 1509709, https://hg.mozilla.org/comm-central/rev/43c9c600cf84
| Assignee | ||
Comment 17•6 months ago
|
||
This bug still has some merit, Thunderbird 149 and Daily both produce an empty attachment. I do not believe merging the other text sections in is necessarily the right call, but either the attachment should be a valid .txt or dropped altogether.
| Assignee | ||
Updated•6 months ago
|
| Assignee | ||
Comment 18•6 months ago
|
||
I have yet to see a parser that generates two .txt-attachments, two .pdf-attachment and this body:
This month's notice is being sent in plain text and in PDF format for your convenience in printing and posting the notice. The PDF files are also available from our web site (http://www.mte.com/nysmpte), as is additional information regarding the meeting.
This is what I guess one would expect out of this e-mail, but that would involve more gnarly logic of treating Content-Disposition: inline as attachment based on the fact it has a file name which is always dangerous.
Can anyone provide a slightly less cursed .eml-sample triggering this issue?
What do y'all expect out of this e-mail, how should it be rendered in your opinion?
Updated•6 months ago
|
Comment 19•6 months ago
|
||
Is there anything correct in this MIME structure? Does the attachment display when you view all body parts? Pref mailnews.display.show_all_body_parts_menu.
If so, I suggest Invalid, as users can get to the attachment.
| Assignee | ||
Comment 20•6 months ago
•
|
||
Is there anything correct in this MIME structure? Does the attachment display when you view all body parts? Pref mailnews.display.show_all_body_parts_menu.
If so, I suggest Invalid, as users can get to the attachment.
The setting changes absolutely nothing, the current result in Thunderbird 150 is either way in terms of attachments:
SMPTE 1202_1.pdf: worksSMPTE_1202_2.pdf: brokentext: broken, possibly due to duplicate file-name and identical content
I see no reason why we should not render the 2nd pdf and in general a broken inline plain-text part without a file extension in its name should not show up as an unopenable attachment.
I guess from a conservative point of view, my expected behaviour is that I can open the 2nd .pdf and ideally see its attachment size, but that might be a different can of worms, see bug 333880.
Comment 21•6 months ago
|
||
The setting changes absolutely nothing
Did you switch to "All body parts" in the View menu? The setting only enables a menu option.
| Assignee | ||
Comment 22•6 months ago
•
|
||
Depending on your parsing semantic, you can consider the 2nd attachment as fully compliant with RFC 2046.
It is our choice not to follow Content-Disposition: inline and downgrade to a proper attachment and there is zero reason why the first .pdf should work and the 2nd one not, cause their structure is pretty much identical.
| Assignee | ||
Comment 23•6 months ago
|
||
Did you switch to "All body parts" in the View menu? The setting only enables a menu option.
This gives us five attachments that I can actually open, yet the 2nd .pdf should work fine regardless.
| Assignee | ||
Comment 24•6 months ago
|
||
| Assignee | ||
Updated•6 months ago
|
| Assignee | ||
Updated•6 months ago
|
Updated•6 months ago
|
| Assignee | ||
Updated•6 months ago
|
Comment 25•6 months ago
|
||
Pushed by toby@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/9da2812694c5
Fix handling of unreferenced inline children in multipart/related as attachment. r=tobyp
Updated•5 months ago
|
Description
•