User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9 Build Identifier: Thunderbird 1.5.0.2 20060308 An initial install of Thunderbird attaches msword documents to outbound emails Perfectly. For some reason, and after different periods of time for different users, the attachments are declared unreadable by the recipients. The empirical solution is to find the three copies of mimetypes.rdf that will have been created on the sending system and delete them, at which point the problem goes away for a while. Always to return; for some users within hours, for some only after weeks. The exact technical problem is that the bad mimetypes.rdf causes outbound attachments to get bad Content-type fields in the mime header. It should be application/msword but comes up as application/applefile, which is not recognised by e.g. Entourage. There are other variations on this theme. It's clear that some innocent action on the part of the users is causing a mimetypes.rdf to be created and a bad entry installed for msword attachments. We've had similar problems with Powerpoint and JPEG attachments. The contents of the corrupt mimetypes.rdf clearly shows the bad content-type for the given attachment type. But how does it get there? What user action causes a new entry in mimetypes.rdf to be created? Or the file created at all? I have Googled this to death and everyone knows that deleting mimetypes.rdf fixes many attachment issues. Nobody seems to know why or how this file gets corrupted however. On the basis that the two must be linked, I've tried to use Preferences -> Attachments -> View&EditActions to control mimetype.rdf's association between file types and content-type headers but this panel has no "Add" function, only "Edit" or "Remove" and the bad associations don't show up there anyway. This is becoming a major show-stopper for us. Some users are screaming that the only way to reliably get attachments through is to constantly be deleting the three copies of mimetypes.rdf that keep showing up on their systems. Reproducible: Always Steps to Reproduce: 1.Give all your users Mac OS X, MS Office 2004, Firefox, Thunderbird. 2.Have them exchange Word, Powerpoint attachments all day with clients. 3.Sooner or later, the clients will start receiving attachments with bad or incompatible Content-Type fields in MIME headers. Actual Results: The association between a file to be attached to an email and the MIME Content-Type field used for it gets lost or becomes invalid or acquires a value not recognised by many recipients. Expected Results: An msword attachment should get Content-Type: application/msword and this should be managable by the user and not arbitrarily changed on the fly by Thunderbird. Same for Powerpoint at al. It's clear that the users are doing something which affects mimetypes.rdf. They rely heavily on attaching MS Office documents to emails but other than that have standard systems that they use in normal ways. Why is nobody else seeing this?

Please attach one of the corrupted mimetypes.rdf files to this bug (use the Create New Attachment link above).

(In reply to comment #0) > On the basis that the two must be linked, I've tried to use Preferences -> > Attachments -> View&EditActions to control mimetype.rdf's association between > file types and content-type headers but this panel has no "Add" function, > only "Edit" or "Remove" and the bad associations don't show up there anyway. When I tried loading both of those test files into a profile, and then checking the View&Edit Actions, I couldn't see *any* items listed. The reason for this is that all of the urn:mimetype entries had the 'alwaysAsk' attribute set to True; this means every time an entry is selected, the user has to ask -- therefore, there is no "action" to be edited. This is bad! I don't know how this ever gets set in the first place. I've been trying various things to reproduce this and none are successful. If I edit the mimeTypes.rdf and change all the alwaysAsk values to false, then the types are displayed correctly. There are *three* types associated with .DOC: application/msword, application/applefile and application/x-msdownload. I haven't been able to reproduce this problem, either -- I can't cause multiple entries to be created for the .DOC extension. Once the first entry is in place, any subsequent attachment with .DOC is always using that entry's action regardless of the MIME type of the attachment, unless that MIME type happens to match some other entry -- see bug 293804. This looks like the same basic problem in bug 353815. > This is becoming a major show-stopper for us. Some users are screaming that > the only way to reliably get attachments through is to constantly be deleting > the three copies of mimetypes.rdf that keep showing up on their systems. Three copies? Why are there three? Are the users using multiple profiles? The only one that should be affecting them is the one at the top level of the profile directory. If you have three of these showing up, which directories are they appearing in?

(In reply to comment #4) I have a theory. One thing we do which is relatively unique is to read email attachments with both Firefox and Thunderbird. Firefox is used to access our internal web site's email archive. This latter service then offers a URL for reading each or any attachment. This URL sends the whole MIME encapsulated attachment from the selected email to the browser. Firefox then interprets the Content-type and invokes the appropriate application. Works well. Users love it. I think (more accurately, I guess) that Firefox creates/updates a mimetypes.rdf file using Content-type as the major key. Thunderbird does the same thing but in both directions; using Content-type as the key for inbound (reading) attachments and file extension (e.g. .doc) for outbound (sending) attachments. I also guess that the mimetypes.rdf created by Firefox overrides that created by Thunderbird. Probably depends on the path used. So, if Firefox sees several different Content-type fields referring to the same sort of attachment, they will all be added to his mimetypes.rdf even though they refer to the same thing. This will then fool Thunderbird which will only use the first that is relevant to the attachment type being prepared to be sent. In other words, Thunderbird will create an outgoing Content-type field to match whatever was last seen by Firefox as the Content-type associated with that kind of attachment. Because Firefox only ever uses mimetypes.rdf to convert from Content-type to application, there is never a problem for him. But Thunderbird uses the same file to make the reverse connection from an application to a content-type and obviously uses the first (or is it the last) match it finds in the file. Once Firefox has downloaded an attachment with a vague or meaningless Content-type but managed anyway to figure out the application from the filename extension he will be fine; but all future outbound attachments from Thunderbird will be crippled with that same vague or meaningless Content-type. Not all email readers are smart enough to deal with the result. Asking around, most users report only two copies of mimetypes.rdf turning up instead of the three I've seen in the past. There would be a certain logic to that if there is any truth to the above scenario.

Each program maintains its own mimeTypes.rdf -- they're not shared, the profiles exist in separate directories. I'm having difficulty figuring out how the mimeTypes file comes to be as it is. There are two different problems in the versions you provide: the 'alwaysAsk' fields all being set to True, and the several MIME types all being associated with the same extension. If you can provide steps-to-reproduce that get to either point from a fresh install, that would be helpful. It's possible that part of this is Mac-specific, especially given the 'applefile' type that keeps popping up. (See, for instance, the Mac-specific bug 355142.) Not having a Mac, I can't test this.

(In reply to comment #6) I did the following experiment on a spare machine. Removed all versions of mimetypes.rdf then started Thunderbird and sent myself an email with an msword attachment. Downloaded that email. On opening the attachment I didn't select the "Do this always" option. Open worked fine and the duly created mimetypes.rdf appeared correct but obviously had 'alwaysAsk' set to True. I then modified the original email on the server to change application/msword to application/jimsword and put it back into the relevant mailbox. Downloaded it again to Thunderbird and opened the attachment (which worked) and again not selecting "Do this always". Then I sent myself another email with exactly the same msword document as an attachment and examined the resulting text of the email on the server. The Content-type was application/jimsword. As far as I can tell, the alwaysAsk is a result of, for whatever reason, not selecting to "do this always". The Content-type field for an outbound attachment appears to be created from whatever was last seen associated with the same type of file as an inbound attachment. I will add the mimetypes.rdf as an attachment. It shows the two different Content-type values but I confess I don't really understand the format or meaning of the file's contents.

Thanks much for the detailed info. (In reply to comment #7) > On opening the > attachment I didn't select the "Do this always" option. Open worked fine and > the duly created mimetypes.rdf appeared correct but obviously had 'alwaysAsk' > set to True. I can't reproduce this. If I leave "Do this always..." unchecked, no entry gets loaded into the otherwise-empty mimeTypes.rdf. You may be seeing Mac-only behavior. Still, I'm confirming this bug, based on the detailed steps-to-reproduce. Wayne, if you could test this (and maybe on Seamonkey too) on your Mac...? > Then I sent myself another email with exactly the same msword document as an > attachment and examined the resulting text of the email on the server. The > Content-type was application/jimsword. This is a different problem from the one adding the 'alwaysAsk=true' entries, and I think it applies to all platforms. With two entries in the mimeTypes file both associated with a single extension, if a file with that extension is added, I'm not sure if it's predictable which MIME type actually gets selected. Per comment 4, if the 'alwaysAsk' is true, the item is not displayed in the View&EditActions dialog. If we can fix this part, then it would be possible to manage the second problem thru the UI rather than having to go delete or overwrite the mimeTypes.rdf.

(In reply to comment #9) For the sake of completeness I thought it worth doing the obvious further experiment: I repeated all of the above but this time DID click on "Do this always" for the attachment with the good Content-type. When I downloaded and opened the attachment with the bad Content-type it did not ask what do do with it but simply opened MSWord. Seems reasonable. The mimetypes.rdf following this exercise however was unchanged. Needless to say a further send of the same attachment created a correct Content-type of application/msword in the mime header. I spoke to the most affected user who confirmed a past disinclination to click on the "Do this always" option. Don't know why. I've suggested that she clear out the old mimetypes.rdf, send herself attachments of the required types and use "Do this always" for each of them as they are opened. From the experiment I did here, this should cure the problem. I await the result. Either way your feedback has been of tremondous help. Thanks very much.

(In reply to comment #10) > When I downloaded and opened the attachment with the bad Content-type it did > not ask what do do with it but simply opened MSWord. Seems reasonable. The > mimetypes.rdf following this exercise however was unchanged. I disagree on the reasonableness of that. An example: IIRC, Filemaker used to name its files with .DOC but the MIME type would be something else, such as application/x-filemaker. If someone happened to send you one of these, you couldn't open it in Word, but with the program behaving as it currently does, you'd be stuck. These days, the .DOC extension has been pretty well relinquished to Word, so it's not such an issue with that; but bug 293804 is about a similar issue with the .DAT extension. A different MIME type needs to be recognized as such; I've opened bug 366879 about this issue.

(In reply to comment #9) > Per comment 4, if the 'alwaysAsk' is true, the item is not displayed in the > View&EditActions dialog. If we can fix this part, then it would be possible > to manage the second problem thru the UI rather than having to go delete or > overwrite the mimeTypes.rdf. This is bug 333277; and it only applies to Thunderbird. The main symptom here may occur on the suite as well; see bug 368581.

It doesn't look like the patch for bug 333277 is going to make it into TB 2, but I looked at that patch more closely and it doesn't look like it would affect the Mac anyway.