776246 - Invalid MIME types application/applefile, application/oct-stream (etc.?) on (PDF) attachments in outgoing email

Status: REOPENED

(MailNews Core :: Composition, defect)

Description

[Tyrel McQueen]

The issue I am encountering is basically the same as that previously reported as bug 479169 . Basically, once I open a file of type pdf that was sent by a user of the Mail program of OS X 10.7, Thunderbird picks up the mime type of application/applefile for all pdf files. Any emails I send with pdf attachments then have the content-type given as application/applefile, but are missing the required metadata for that content type. Result is some receivers of my email (confirmed are those using outlook web access and the OS X Mail program) cannot open the pdf attachment ('file is corrupted' errors).

Steps to reproduce:
1) Send an email with a pdf attachment from the OS X mail program, making sure it includes the applefile metadata (default as far as I can tell on OS X 10.7 Mail program)
2) Open email in thunderbird (OS X or Windows; did not check Linux) and save attachment to disk. Thunderbird picks up the application/applefile mime type for pdf files.
3) Send an email from thunderbird with a pdf attachment. It will have mime type application/applefile . 
4) The pdf in this new email is not readable by some clients (one version of OWA and OS X Mail confirmed).

Expected result: Thunderbird should always send PDF files as type application/pdf , or at the very least not be using a MIME type without ensuring the appropriate parts are present.

Severity: With the rise of OS X and iOS based clients, this is becoming more prevalent. Further, Thunderbird should not be sending emails with improper MIME types.

Comment 1

[Tyrel McQueen]

One more note: deleting the "application/applefile" mime type from the attachment preferences pane fixes the issue, but only until I receive the next pdf attachment from an OS X / Mail user.

Comment 2

[Kent James (:rkent)]

Bug 503309 and its sister variants are what you are seeing. What is new to me here (but not really new to bug 503309) is that I have been focused on incorrectly formatted content types like "?windows-1252?q?application/pdf" but here the root cause is a correctly formatted, but wrong, content type.

Comment 3

[Kent James (:rkent)]

I'm going to undupe this for now, because there are two different issues:

1) preventing bad content types from getting into mimeTypes.rdf in the first place (that is bug 503309)

2) not using bad content types that already exist in mimeTypes.rdf in outgoing emails.

Although there might be another existing dupe of this bug, I'm going to interpret this bug for now as issue 2).

Comment 4

[rsx11m]

(In reply to Kent James (:rkent) from comment #3)
> 2) not using bad content types that already exist in mimeTypes.rdf in
> outgoing emails.

I'm wondering how one would identify "bad content types" stored in mimeTypes.rdf compared to "valid" ones. What would be the suggested procedure when a definition contradicting the OS-registered MIME type or multiple definitions within the mimeTypes.rdf exist, thus causing an ambiguity?

Comment 5

[Kent James (:rkent)]

(In reply to rsx11m from comment #4)
> What would be the suggested
> procedure when a definition contradicting the OS-registered MIME type or
> multiple definitions within the mimeTypes.rdf exist, thus causing an
> ambiguity?

There are no good answers. Perhaps an "Are you sure"? type of prompt with a "don't ask again" box for this particular type of mismatch?

Comment 7

[Tony Mechelynck [:tonymec]]

Duplicate 945730 is about a similar phenomenon observed in SeaMonkey 2.25a1, also for PDF files, but with bogus MIME type "application/oct-stream". I applied the temporary workaround mentioned in bug 945730 comment #2; however I'll try to keep watch for the case mentioned in comment 1 above.

Comment 8

[Tony Mechelynck [:tonymec]]

oops, 2.24a1. Here are the user-agent string etc.:

Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24a1 ID:20130919003001 c-c:1ea1fc3586db m-c:803189f35921

(This is the latest SeaMonkey nightly for Linux64, see bug 943740.)

Comment 9

[WADA:World Anti-bad-Duping Agency]

(In reply to rsx11m from comment #4)
> (In reply to Kent James (:rkent) from comment #3)
> > 2) not using bad content types that already exist in mimeTypes.rdf in
> > outgoing emails.
> I'm wondering how one would identify "bad content types" stored in
> mimeTypes.rdf compared to "valid" ones. What would be the suggested
> procedure when a definition contradicting the OS-registered MIME type or
> multiple definitions within the mimeTypes.rdf exist, thus causing an ambiguity?

I think there is no need to identify "bad content types". I think "respect setting in OS, already known correct one by Tb(hard coded, or predefined) in generating mail data" is sufficient. 
  (i) Look content type defined in OS first
 (ii) if not found, look Tb's pre-defined ones
(iii) if still not found, look mimeTypes.rdf defined by user intentionally or accidentally.
      if broken, for example, ?windows-1252?, ignore it.
In "generating mail data", required "relation" is only "file extension -> mime-type" on Win and Linux(file meta data of the file is usable if Mac).
Why data set by "do it always or automatically" for "registration of application name" should be used in mail composition?

By this priority change, mimeTypes.rdf can not be used for "overriding bad OS setting by mimeTypes.rdf of Tb".
However, broken or bad setting in OS should be corrected via OS interface by user.
And, there is no way to freely register "association between mime type and file extension to mimeTypes.rdf" in both Tb and SeaMonkey already, because such function was already killed in Tb and even in SeaMonkey. So, manual "overriding bad OS setting by mimeTypes.rdf setting via UI of Tb/Sm" is already impossible.

Even after this priority change, "bad mime type in outgoing mail" can not be avoided, if unknown file extension in OS/Tb and if bad mime type is saved in mimeTypes.rdf for the unknown file extension by "do it always or automatically" or "ask".
I believe majority of problem due to "bad mime type in outgoing mail produced by bad mimeTypes.rdf entry which is generated by Tb himself" is problem on very popular file extension like .pdf, .doc, .xls, instead of on "unknown file extension in OS". So, even if solution is not perfect, I believe this priority change will reduce number of victims.
And, because "delete" is already supported in Tb's UI by bug 501163, user can already remove it any time using Tb. There is no need to delete "unknown mimeTypes.rdf file for general Tb user" any more.

rsx11m and Kent James:
Is such "priority change", "search order change", possible in Thunderbird?

Comment 10

[Kent James (:rkent)]

Some additional comments on this that have come up in the ExQuilla addon (see https://exquilla.zendesk.com/entries/41844416)

The user had text/plain for the content type of .pdf files, and when ExQuilla picked that up for an outgoing email, the Exchange server generated an error. The user (and me!) was also confused because the UI for setting the MIME type specifically refers to incoming emails, while in fact that content type is also used in outgoing emails. Or so I say after just a few minutes of reexamining this.

Comment 11

[Bruno Pagani]

OK, so I think that https://bugzilla.mozilla.org/show_bug.cgi?id=1206024 is a duplicate of this too (with video/x-flv as the wrong MIME type).

Comment 13

[Bruno Pagani]

Also, I would like to say this is very annoying because of the spreading nature of this issue: fixing it on your side (by cleaning the mimeTypes.rdf file) has a very temporary effect, since has soon as someone else affected or using another affected mail client send you a mail with a wrong MIME type, you’re screwed again (because of https://bugzilla.mozilla.org/show_bug.cgi?id=503309)…

So this bug is more and more widespread, and something must be done about this. Also, when a fix will be released, depending on its nature it might be needed to clean users mimeTypes.rdf…

Comment 14

[jens]

Same here. I had also wrong entry in mimeTypes.rdf so my pdf documents are send with "Content-Type: video/x-flv;".
thunderbird-45.4.0-1 running on fedora 23. Removing mimeTypes.rdf completely helped.