487976 - Thunderbird sets content-type set to application/octet-stream on outgoing attachments even if the OS knows the correct MIME type

Status: RESOLVED DUPLICATE of bug 441791

(Thunderbird :: General, defect)

Description

[D R Evans]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.8) Gecko/2009032712 Ubuntu/8.10 (intrepid) Firefox/3.0.8
Build Identifier: 2.0.0.21 (20090318)

Even though the OS knows the correct MIME type for a file with a simple name such as "test", Thunderbird marks it as the content-type application/octet-stream instead of using the correct MIME type.

The "Steps to Reproduce" provides one example: that of an application/vnd.oasis.opendocument.text file. Similar results occur with other MIME types where the name of the file does not have an extension.

I am running Thunderbird on 64-bit Kubuntu 8.10. 

Reproducible: Always

Steps to Reproduce:
1. Create an  application/vnd.oasis.opendocument.text file called "test" using any application that generates ODT-format files..
2. Attach the file to an outbound e-mail.
3. Send the e-mail.
4. Thunderbird will insert the following content-type header:
  Content-Type: application/octet-stream;
 name="test"
4a. The actual content-type should be application/vnd.oasis.opendocument.text
4b. The OS correctly identifies the file as application/vnd.oasis.opendocument.text, so the information is certainly available; it's just that Thunderbird doesn't seem to use it.


Actual Results:  
The attachment has the (unhelpful) MIME type application/octet-stream (which is intended for generic binary data, not for known applications).

Expected Results:  
The Content-type header should reflect the correct MIME type of the file as determined by the OS.

I am running Thunderbird on 64-bit Kubuntu 8.10 (although I doubt that that matters).

I regard this as a bug (because Thunderbird is not telling the recipient the right thing). You might consider it a wish.

Comment 1

[Ludovic Hirlimann [:Usul]]

(In reply to comment #0)

> 
> I am running Thunderbird on 64-bit Kubuntu 8.10 (although I doubt that that
> matters).
> 
> I regard this as a bug (because Thunderbird is not telling the recipient the
> right thing). You might consider it a wish.

Is this also true with versions 3.0 betas ? (they are available in PPA)

Comment 2

[D R Evans]

Painful experience has taught me never, ever to install from PPA :-(

Someone following this bug who is braver (or more foolhardy?) than I am should be able to test on 3.0 by following the instructions in the original report.

(If the packages are moved to backports, then I can/will install them, but not as long as they are only in PPA.)

Comment 3

[Phil Ringnalda (:philor)]

No need to test, it's the same core file handling bug that gives bogus types for file uploads.

Comment 4

[Vincent Lefevre]

What is the status of this bug? It is marked as a duplicate of bug 373621, but bug 373621 now belongs to the Firefox product, which the bug here concerns Thunderbird. Should it be reopened?

Comment 5

[Vincent Lefevre]

BTW, bug 373621 was about PDF only (and its fix is specific to PDF). So, this bug should be reopened.

Comment 6

[Kent James (:rkent)]

TO reopen this bug, it would be good to first establish reliable steps to reproduce. This has been a confusing area, and the assumption is that any issues Thunderbird has are related to core issues.

My own vague understanding of this, which may or may not be accurate, is that the sequence of failure is something like this. While downloading an attachment with a particular mimetype (or is it file extension?) chooses an odd program to observe the attachment. That then results in a strange mimetype being entered into the mimetype.rdf file. You'll see the strange mimetype in the Attachments options tab. Then on upload, the strange mimetype is used (which is surprising because the Thunderbird UI shows this in the Incoming/Attachments tab.

I never really understood why the problem mostly occurs with PDF files.

As I said, this understanding may be inaccurate.

Comment 7

[Vincent Lefevre]

(In reply to Kent James (:rkent) from comment #6)
> TO reopen this bug, it would be good to first establish reliable steps to
> reproduce. This has been a confusing area, and the assumption is that any
> issues Thunderbird has are related to core issues.

Yes, but if this is related to core issues, I wonder why "File Handling" bugs have been moved from the Core to Firefox product.

> My own vague understanding of this, which may or may not be accurate, is
> that the sequence of failure is something like this. While downloading an
> attachment with a particular mimetype (or is it file extension?) chooses an
> odd program to observe the attachment. That then results in a strange
> mimetype being entered into the mimetype.rdf file.

Yes, I suppose something like that:

1. filename.ext is downloaded and served with an unknown mimetype, e.g. application/octet-stream; such a choice is done for obscure reasons like security reasons, here's an example: https://scm.fusionforge.org/anonscm/gitweb?p=fusionforge/fusionforge.git;a=commit;h=46457e98aba26896b26e30d734ba720984074091 ("plug XSS-with-CSP-bypass by always serving files as binary instead of using the content-type the browser gave us during the upload").

2. This has the effect to associate extension "ext" with the mimetype application/octet-stream in the mimeTypes.rdf file.

Then, when a file with extension "ext" is uploaded (by either Firefox or Thunderbird?), the mimetype is chosen from the mimeTypes.rdf file, thus is incorrect.

I can see two possible bugs:

1. The fact that the mimeTypes.rdf file has been modified based on some choice from an arbitrary web server (IMHO, this can be regarded as a security issue).

2. Under Unix (at least), the fact that for upload, the mimeTypes.rdf file is used instead of the user/system mime.types file. See: https://en.wikipedia.org/wiki/Media_type#mime.types

> I never really understood why the problem mostly occurs with PDF files.

Because this is the most used file format when exchanging documents (in particular in contexts when the mimetype information can be lost)?

Comment 8

[Kent James (:rkent)]

When you say:

"Then, when a file with extension "ext" is uploaded (by either Firefox or
Thunderbird?), the mimetype is chosen from the mimeTypes.rdf file, thus is
incorrect."

that is what makes me think core bug. If you can duplicate the issue with Firefox, then that is really where the bug should be filed. They have several orders of magnitude more resources to fix issues than Thunderbird does.