1304908 - Attachment with Content-Type: application/octet-stream; not shown in attachment area.

Status: NEW

(MailNews Core :: Attachments, defect)

Description

[Kees]

Attachment: Source email

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160811182350

Steps to reproduce:

From an online system (Blackboard eLearning system) sent several emails with attachment. I have tried this with several .jpg and .pdf files.


Actual results:

The email arrives fine in Thunderbird, immediately after arrival it shows a paperclip symbol to indicate the presence of the attachment but when the email is opened in a new tab by a click this tab shows no attachment. Going back to the Inbox, the paperclip symbol has vanished. 


Expected results:

Thunderbird should keep recognising the email has an attachment. 

I am attaching the source of such an email (edited out most of the binary attachment content for clarity). I have (1) tested this source via http://www.mimevalidator.net/index.html which shows no errors and (2) been able to open the attachment just fine in the online webmail application for this email account, indicating to me that Thunderbird seems at fault. (?)

Comment 1

[Jorg K (CEST = GMT+2)]

The message contains an attachment with the following headers:

Content-Type: application/octet-stream; name="Bola.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Bola.jpg"

That is wrong. Correct would be:

Content-Type: image/jpeg; name="Bola.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Bola.jpg"

After manually correcting in the exported e-mail and reimporting the e-mail message, the picture shows.

Comment 2

[Kees]

I see the status is now changed to `RESOLVED INVALID'. I don't understand this. Surely even with `Content-Type: application/octet-stream' it should be recognised and reflected by Thunderbird as an attachment, even if it can't identify beyond a binary blurb, surely just pretending as if there is no attachment at all is not desired behaviour?

Comment 3

[Jorg K (CEST = GMT+2)]

Yes, well, you could argue that Thunderbird should treat "binary blurb" attachments better. It will go onto the huge pile of enhancement requests that we don't have time for.

In the meantime I suggest to set preference mailnews.display.show_all_body_parts_menu and look at all the body parts via
View > Message Body As > All Body Parts.

Comment 4

[Kent James (:rkent)]

Jorg, what is wrong with:

Content-Type: application/octet-stream; name="Bola.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Bola.jpg"

Yes it would not be interpreted as an image, but we should at least show the presence of an attachment that can be saved as a file. Right?

Comment 5

[Jorg K (CEST = GMT+2)]

(In reply to Kent James (:rkent) from comment #4)
> we should at least show the
> presence of an attachment that can be saved as a file. Right?
Right. Isn't that what the summary of this *confirmed* bug says:
Attachment with Content-Type: application/octet-stream; not shown in attachment area.

Comment 6

[Kent James (:rkent)]

I was responding to your snarky response "It will go onto the huge pile of enhancement requests that we don't have time for." as well as comment 1 "That is wrong"

I would also not consider this an enhancement request. To me, a bug (not an enhancement) is when the behavior does not match the design intent. I find it hard to believe that the design intent was to not allow the download and saving of an attachment when the type was "application/octet-stream".

Comment 7

[Jorg K (CEST = GMT+2)]

Attachment: Sample message showing the vanishing paper clip.

OK, changed the status back to "normal".

I still believe setting Content-Type: application/octet-stream for an image is wrong.

The reporter complains that the paper clip symbol disappears after the message is clicked. It's a common problem that is shows erroneously and then disappears, do you know this problem and is there a bug for it? Drag the attached message to a folder and the paper clip appears and later disappears.

I briefly searched and only found bug 606233

Comment 8

[Jorg K (CEST = GMT+2)]

Found it. Bug 479017.

Comment 9

[Kent James (:rkent)]

The paper clip initially appears because there is a kludge somewhere that searches for, I believe, "Content-Type: multipart/related;" as a proxy for whether the message has an attachment, then sets the attachment flag. When full MIME processing of the message is done, the attachment flag is updated. So for some reason when MIME processing of this message is done, the attachment is not recognized.

This has always been a big problem in filtering, which also happens prior to MIME processing. Users would like to filter on attachments, attachment types, and attachment names, but none of this is available at filtering time.

That's why on our imaginary roadmap we have the item to do MIME processing earlier in message processing.

Comment 10

[Jorg K (CEST = GMT+2)]

(In reply to Kent James (:rkent) from comment #9)
> The paper clip initially appears because there is a kludge somewhere that
> searches for, I believe, "Content-Type: multipart/mixed;" <<== as a proxy for
> whether the message has an attachment, then sets the attachment flag. When
> full MIME processing of the message is done, the attachment flag is updated.
> So for some reason when MIME processing of this message is done, the
> attachment is not recognized.
Yes, that is the diagnosis in bug 479017 comment #17. The message here simply has a bad MIME structure, it's multipart/mixed, but there is no attachment.

Comment 11

[mailinglists35]

(In reply to Jorg K (CEST = GMT+2) from comment #3)
[...]

In the meantime I suggest to set preference
mailnews.display.show_all_body_parts_menu and look at all the body parts via
View > Message Body As > All Body Parts.

This worked for me but activating it is unconvenient as it always shows attachments status bar/menu even if you just have a html+text email.

Can we have a compromise working mode when the preference is enabled to only show a visual indicator that there are more body parts available, then clicking it would reveal the body parts and names, instead of directly showing them as attachments? Because showing it directly it takes space on the message area.

The relavant part looks like this

------=_Part_15946_1702326044.1707705518803
Content-Type: application/octet-stream;
name=Failed_Monitors_2024_02_12_04_38_38.xls
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename=Failed_Monitors_2024_02_12_04_38_38.xls

[base64 encoded block]

Comment 12

[mailinglists35]

should the sending app be fixed to change Content-Type to application/vnd.ms-excel?

Comment 13

[Francesco]

TB produces: Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; for xlsx.

"application/octet-stream" doesn't help distinguishing attachment types.