Open Bug 353815 Opened 18 years ago Updated 2 years ago

Received attachments with malformed mime types like "text/msword" for ms.doc 1) should not be displayed inline 2) proliferate incorrect mime types handling into mimetypes.rdf (bug 503309)

Categories

(Thunderbird :: General, defect)

Product:
Thunderbird
Component:
General
Platform:
x86
Windows XP
Type:
defect

Tracking

(Not tracked)

Status:
UNCONFIRMED

People

(Reporter: refsvileco, Unassigned)

Details

(Whiteboard: [better description see comment 6])

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1b2) Gecko/20060821 Firefox/2.0b2 Build Identifier: Thunderbird version from 0.5 to 1.5.0.7 (20060909) I don't know why bau some of my users has a mimetypes.rdf like this: <?xml version="1.0"?> <RDF:RDF xmlns:NC="http://home.netscape.com/NC-rdf#" xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <RDF:Description RDF:about="urn:mimetype:externalApplication:application/msword" NC:prettyName="" NC:path="" /> <RDF:Description RDF:about="urn:mimetype:handler:text/msword" NC:alwaysAsk="true" NC:useSystemDefault="true" NC:saveToDisk="false"> <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:text/msword"/> </RDF:Description> <RDF:Description RDF:about="urn:mimetype:application/msword" NC:fileExtensions="doc" NC:description="Documento di Microsoft Word" NC:value="application/msword" NC:editable="true"> <NC:handlerProp RDF:resource="urn:mimetype:handler:application/msword"/> </RDF:Description> <RDF:Description RDF:about="urn:mimetype:handler:application/pdf" NC:alwaysAsk="true" NC:useSystemDefault="true" NC:saveToDisk="false"> <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/pdf"/> </RDF:Description> <RDF:Description RDF:about="urn:mimetype:application/pdf" NC:fileExtensions="pdf" NC:description="Documento Adobe Acrobat" NC:value="application/pdf" NC:editable="true"> <NC:handlerProp RDF:resource="urn:mimetype:handler:application/pdf"/> </RDF:Description> <RDF:Description RDF:about="urn:mimetype:externalApplication:application/pdf" NC:prettyName="" NC:path="" /> <RDF:Description RDF:about="urn:mimetype:externalApplication:text/msword" NC:prettyName="" NC:path="" /> <RDF:Seq RDF:about="urn:mimetypes:root"> <RDF:li RDF:resource="urn:mimetype:application/msword"/> <RDF:li RDF:resource="urn:mimetype:application/pdf"/> <RDF:li RDF:resource="urn:mimetype:text/msword"/> </RDF:Seq> <RDF:Description RDF:about="urn:mimetype:handler:application/msword" NC:alwaysAsk="true" NC:useSystemDefault="true" NC:saveToDisk="false"> <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/msword"/> </RDF:Description> <RDF:Description RDF:about="urn:mimetype:text/msword" NC:fileExtensions="doc" NC:description="Documento di Microsoft Word" NC:value="text/msword" NC:editable="true"> <NC:handlerProp RDF:resource="urn:mimetype:handler:text/msword"/> </RDF:Description> <RDF:Description RDF:about="urn:mimetypes"> <NC:MIME-types RDF:resource="urn:mimetypes:root"/> </RDF:Description> </RDF:RDF> When this case appens, they sent doc attachment that the recipients see in line, such as a message body, if the option in line is checked, and it is always checked cause they need it. This is a part of the header: Content-Type: text/msword; name="Relazione alla modifica.doc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Relazione alla modifica.doc You can see tha content-type is text/msowrd and not applications/msword, ad content-disposition is inline, not attachment. Why that appens? Why thunderbid modifies the mimetypes.rdf? Then after a corrupted mail is received, also the recipiens has a strange mimetypes.rdf like the ones above. And my users, unfortunatly, prints with distraction the mail, and they waste a lot and lot of paper and they became angry with me. Is possible to say to thunderbird to treat mimetype text/msword like a pure attachment? I have try whay suggested in http://kb.mozillazine.org/Send_attachments_as_real_attachments, but it doesn't work. Thunderbird restarts to work only if I modify/delete the mimetypes.rdf file, but I can't chase my users.... I think it is a bug..... Reproducible: Always Steps to Reproduce: 1. use the mimetypes.rdf above 2. make a mail with a doc attachment 3 [review]. send the mail to somebody with thunderbird (make sure that in the configuration you have the mimetypes.rdf above) 4. receive the email above with thunderbird 5. view the message with attachment inline (it is a doc, It wouldn't) 6. back to step 1. Actual Results: You can see a bad message with the doc file in the body. then if you send again a message, you spread the wrong mimetype text/msword to other mimetypes.rdf. Expected Results: to not see the doc attachment inline! to save paper :)
With regard to corresponding RFCs, IANA looks after the official list of mime-type definitions, which in this cas implies application/msword (as stated in above summary): http://www.iana.org/assignments/media-types/application/msword Following this logic, implementing text/msword would not be correct. Therefore, I suggest to move this bug to the evangelism section to be discussed there. Also (though mime is orginally only mail-related) this issue will not only be relevant to Tb, but probably rather to be targeted at a Core component.
> I suggest to move this bug to the evangelism section to be discussed there. > Also (though mime is orginally only mail-related) this issue will not only be > relevant to Tb, but probably rather to be targeted at a Core component. > Where is this sections? I see the documents of iana, but it happens that mimetypes.rdf is modified and mimetype test(msword is used then ehen there is a microsoft document attached. What i mush do?
I'm not sure, but I think there's an error in the pasted copy of mimeTypes.rdf. I keep getting crashes when I start a profile with that text stored as the file. In the future, please attach files using the Create New Attachment link in the bug; pasting text is prone to errors. The only way (in TB) to have created a text/msword entry in the first place is to have tried to open an attachment with that type. Most text/* MIME types are treated as plain text, even text/aunt-tilly (the notable exceptions are text/html and text/rtf). There's way to absolutely prevent adding the erroneous entry in mimetypes.rdf; but if the .DOC extension is already associated with application/msword, there shouldn't be an option to add it: if TB doesn't have an entry for the MIME type but does have one that matches the extension, that's the action it will use. Assume your user has a good mimetypes.rdf, and she gets a message with a text/msword attachment. If she has "Display attachment inline", then she'll presumably notice the pile of gibberish in the message. If she doesn't, the only clue about the attachment will be that the attachment's icon won't be a Word icon. You can tell the users to look for those cases, and then use Save To Disk, rather than trying to open it from within TB. You can also create a default mimetypes.rdf file with the correct assocation between .DOC and application/msword and just install that in the user's profile immediately after installing TB. If the entry somehow gets made anyway, then you can try the following: Tools | Options | Attachments | View & Edit Actions In the table of defined actions, there are columns; to the left of the column headers is a column-picker. Click that, then pick MIME Type from the menu that appears; this will help you be sure you get the right item. Select the one that has text/msword in it, and click Remove Action.
I'm one of the moderators of italian mozilla support forum and I must say that we have had several cases like this one, all about attachments .doc or .rtf with wrong mimetypes, that cause wrong entries in mimeTypes.rdf (because the first one the user in the first place have tried to open an attachment with that type). To fix this, I've written a small extension that modifies nsHelperAppDlg.js so that it's impossible for the user registry the action when there is a mismatch between file extension and its mimetype: it prevents the wrong entries in mimeTypes.rdf with .doc .rtf and .pdf files (I've heard mismatches just about these types, but the method can be extended also to other file extension, I think). You can see it here: https://nic-nac-project.org/~kaosmos/NoWrongMimetypes-0.1.xpi
Assignee: mscott → nobody
Reporter, does this still occur with the latest supported 2.0.0.x / Shredder trunk nightlies? (1.5.0.x is now end-of-life and the latest supported 2.0.0.x is 2.0.0.17)
Whiteboard: closeme 2008-10-16
The problem is still present in 2.0.x versions, as you can see in this threads in mozillazine forum: http://forums.mozillazine.org/viewtopic.php?f=39&t=902575 http://forums.mozillazine.org/viewtopic.php?f=39&t=890035 There are two problems related to this bug: 1) Thunderbird seems to show inline every attachment with mimetype text/* This can be a problem with attachment with wrong mimetypes (the most frequent cases are with pdf attachments); for example a pdf having mimetype text/pdf or text/doc. For a common user, this seems a file corruption, even it is not. According to me, the inline view shoudn't be applied when there is a mismatch between mimetype and file extension. 2) As explained in comments #3 and #4, sometimes wrong mimetype entries are created in mimetypes.rdf file and this causes that all attachments of that type will be send with wrong mimetype. Pratical example: - receive a message with a pdf attachment and text/pdf mimetype - open it and choose to perform always this action - an entry in mimetypes.rds is created that associates pdf and text/pdf mimetype - compose a message and attach a pdf file --> it will have wrong text/pdf mimetype. nsHelperAppDlg.js should not allow creation of wrong entries.
Dan, did TB have any mimetype code improvements in the last few months?
Whiteboard: closeme 2008-10-16
Not that I'm aware of that would have fixed this.
FYI. Bug 462629 is request not to import this kind of Tb's bugs to Seamonkey Trunk(next Seamonkey 2). See Bug 471027 Comment #20 for quick summary of problems around bogus mimeTypes.rdf entry. (we are trying to find already opened bug for each problem) Note-1: Problem of "Tb creates bogus mimeTypes.rdf entry" can occur on any combination of mime-type & file-extention. It's never limited to text/msword & ".doc". AFAIR, many bugs are already opened for the problem(Bug 471027 is an example of new case) and some are closed as DUP. Note-2: AFAIR, I saw a bug for problem around multiple relations between mime-type & file-extension in mimeTypes.rdf.
The summary of this bug should be improved to reflect the actual problem more precisely, and then it should be confirmed?
If I understand this bug correctly, it should be morphed into an RFE: Explore ways to prevent saving of wrong mime type handling derived from received messages with malformed mime attachments (e.g. text/msword for .doc instead of application/msword)
Flags: needinfo?(m-wada)
(In reply to Thomas D. from comment #11) duping to bug 503309 is apropriate?
Flags: needinfo?(m-wada) needinfo?(m-wada) → needinfo-
(In reply to WADA from comment #12) > (In reply to Thomas D. from comment #11) > duping to bug 503309 is apropriate? Per my comment 11, I think yes. Thank you! But duping to bug 503309 will only cover #2 of comment 6. I think #1 of comment 6 is also an important part of bad ux of this bug: "view attachments inline" showing garbage preview of attachments with malformed mime types Wada, do we have a bug for #1 of comment 6? Or we should morph this bug here to cover that?
Summary: text/msword bad treatment of body message with ms .doc attachement → Received attachments with malformed mime types like "text/msword" for ms.doc 1) should not be displayed inline 2) proliferate incorrect mime types handling into mimetypes.rdf (bug 503309)
Whiteboard: [better description see comment 6]
The bug still exists. I wanted to fix the bug because it prepares us a lot of trouble at work. But i couldn't find the place in the source, where the mimetypes are handled in a wrong way.

(In reply to Fabian Keßler from comment #14)

The bug still exists. I wanted to fix the bug because it prepares us a lot
of trouble at work. But i couldn't find the place in the source, where the
mimetypes are handled in a wrong way.

Disable display attachments inline will fix this sort of issue and it has been an option for a long time.
I think this should be resolved works for me.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.