503309 - No safe-guard provided against adding wrong MIME association to mimeTypes.rdf from incoming attachment, so broken/wrong Content-Type: headers are sent

Status: NEW

(MailNews Core :: Attachments, defect)

Description

[rsx11m]

This is another spin-off from Thunderbird bug 501163. While the identification and removal of wrong entries in mimeTypes.rdf is handled there and in the related SeaMonkey bug 462629, the proposal here is to avoid such wrong entries and their consequences to start with. In general, a MIME-type/file-extension association is added whenever an attachment with a previously unknown MIME type is opened.

The idea is to:

1) allow only a single MIME type to be associated with each file extension (currently multiple MIME types are allowed to register, which doesn't seem to make much sense and causes ambiguities when sending a mail with an attachment having that same file extension);

2) before adding an entry from an attachment opened with a type previously
not seen, verify the MIME-type/file-extension association with whatever is registered with the operating system, and issue a warning with "Add? Yes/No"
if there is a mismatch;

3) if an attachment is opened which has a file extension already registered in mimeTypes.rdf, but there is a mismatch with the MIME type presented for the attachment opened, present a dialog "Change association? Yes/No" to allow the new assoication to override any previously made (and possibly wrong) one from
a prior definition.

Such would obviously require some redesign of the current "Open with" dialog but may hopefully avoid many of the cases of a wrong association picked up just by opening an incoming attachment, thus sending e-mails with wrong MIME types when an attachment of the matching file extension is attached.

Comment 1

[rsx11m]

There is also bug 293804 describing a similar approach. It appears though that bug was filed to resolve any conflicting MIME-type/extension combinations when opening an attachment to determine the correct action, whereas the bug here is supposed to prevent/adjust wrong entries put into mimeTypes.rdf to start with.

Comment 2

[Magnus Melin [:mkmelin]]

(In reply to comment #0)
> 1) allow only a single MIME type to be associated with each file extension
> (currently multiple MIME types are allowed to register, which doesn't seem to
> make much sense and causes ambiguities when sending a mail with an attachment
> having that same file extension);

Wrong associations aside, i think this would likely cause problems too.

Comment 3

[rsx11m]

Can you clarify if you mean (a) allowing multiple MIME types per file extension may cause problems beyond associations, or (b) restricting MIME types to one per file extension may cause limitations in other regards?
I don't see the use case for the (b) interpretation.

Comment 4

[Magnus Melin [:mkmelin]]

I'm not sure what b) would imply, but yeah i meant mainly a).

Comment 5

[rsx11m]

WADA, thanks for giving this issue attention, but this bug isn't restricted to /broken/ Content-Type headers, rather wrong ones in general, thus making the bug summary a bit more generic again (also applies to SeaMonkey).

Comment 12

[Ben Bucksch (:BenB)]

phew, serious bug. This concept "save mimetypes that I received and send them to others" is fundamentally flawed. We shouldn't just protect against it, but eliminate it.

For the purposes of sending, the learning feature should be disabled, only system services and manual user configs should be used.

Comment 13

[Ben Bucksch (:BenB)]

Breaks core functionality, even for recipients -> Severity major.

Comment 14

[Ben Bucksch (:BenB)]

The priority should be:
1. manual user settings in Firefox/Thunderbird
2. system settings
3. learning
Auto-learning should only be used for file exts and mime types that are not known by the system.

> a MIME-type/file-extension association is added whenever an attachment with a
> previously unknown MIME type is opened.

Maybe the bug is that this is then stored and also used to make the reverse lookup of file ext to mimetype. I.e. you ever get "text/pdf" for a "foo.pdf", then Firefox will have both application/pdf <-> .pdf and a text/pdf <-> .pdf, and (and this is the bug) when encoutering a .pdf, will consider both entries. So, another solution could be to make the associations uni-directional instead of bi-directional.

I think the priority order is the right solution.

Comment 15

[Fabian Keßler]

Depents on Bug 649321

Comment 16

[rsx11m]

Thanks Fabian, but this appears to be a slightly different issue. The other bug is on files which don't have an extension at all, whereas this bug is on assigning a wrong MIME type to a known file extension from incoming messages. Or, did I read the other bug wrong?

Comment 17

[Fabian Keßler]

oh you are right, this bug Blocks Bug 649321 cause Bug 649321 describes the special case, that the mimetype is (application/unknown foo). 
I have mixed it up, because the bug is hinted in the comments that this is a general problem with incorrect mime types.

Comment 18

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

Comment 19

[rsx11m]

This bug needs to be re-verified after bug 306471 "Upload setting wrong Content-Type for files if you downloaded files with such an extension from a server that provided the wrong Content-Type for them" landed 2016-08-24 and may have fixed this issue for Thunderbird as well.

Comment 20

[Bruno Pagani]

So it looks like this side of the bug (registering wrong types) is fixed, since I have not been able to reproduce it. But that could be luck too, since I don’t know of a way that reproduced this 100% of time.

However, even that being fixed, it seems users still have to clean their association file (so maybe this should be done automatically on some update), and this concept still looks fundamentally flawed to me (and fixing this could solve the “how to clean the file?” induced by the first part of this sentence). Why not just use the system MIME types definitions?