User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1 Build Identifier: 2.0.0.19 or 3.0b1 Thunderbird should never send a valid attachment with content-type text/x-moz-deleted, no matter what mimeTypes.rdf or any other entity claims the MIME type should be. It is never correct behavior to use this special magic MIME type for a real attachent, and if it *is* used, harm will befall the recipient (if they use Thunderbird). This is bug 1 of 3 that are descended from bug 471027. Fixing any of these three bugs would prevent the serious harm described below. (I think this is probably the easiest of the three to resolve.) --- A problem that originated with a single user, and initially seemed like a somewhat minor bug, propagated via email to nearly every Thunderbird installation in a company, causing them all to become unable to send email attachments. Furthermore, the problem re-emerges and re-propagates, even after IT staff go in to repair the damage. This propagation-via-email aspect is what makes this such a major bug. Originally filed as bug 471027, the discussion on the bug made it clear that there were actually multiple bugs working together to cause harm. Fixing any one of these bugs would stop the propagation of the bug from machine to machine, so I am filing them separately. --- Reproducible: Always Steps to Reproduce: (NOTE: I use Excel .xls file as the example here, but it could be any file type.) 1) From Thunderbird instance A, find a message (send yourself one if necessary) with an .xls attachment. Open the message and delete the attachment. 2) Forward the message with the deleted attachment to Thunderbird instance B. 3) In Thunderbird instance B, double-click the attachment in the received mail. (The attachment will have type "text/x-moz-deleted".) 4) In the resulting open prompt, choose "Open with Microsoft Office Excel (default)" (or choose to open it with some other program), and check the "Do this automatically for files like this from now on". Actual Results: In step 4 above, Thunderbird B creates a bogus entry in mimeTypes.rdf that associates the ".xls" file extension with mimetype "text/x-moz-deleted. 5) Now Thunderbird B is borked. It will now send .xls attachments with mimetype "text/x-moz-deleted", and this causes many mailers to see the attachment as gibberish inline text. Thunderbird, in particular, will not only be unable to display the message properly, but if the recipient performs the same actions as step 3 above, their Thunderbird will now also be affected in the same way. 6) Each other Thunderbird user to whom Thunderbird B sends an Excel attachment will experience the same problem. In the company where I found this issue, over the course of a few weeks almost everybody had their Thunderbird become non-functional in this way, via opening an attachment file from another user already affected by this bug. Expected Results: There are multiple bugs at work here, but this one is occurring in step 2, when the message is actually sent. I would expect: a.) Thunderbird does not ever send a valid attachment with content-type "text/x-moz-deleted", and therefore b.) Thunderbird would not react to double-clicking the file by associating this invalid MIME type with "xls" files, thus rendering it unable to correctly send Excel file attachents There is a bunch of (somewhat messy) discussion of this issue on bug 471027. Basically there are a variety of existing bugs regarding how TB could be improved in how it deals with MIME types and file associations. But because it is always incorrect behavior to send a real attachment with content-type text/x-moz-deleted, and because significant harm can result if it does happen, I think it should be actively prevented at send time. That is, this special case should be handled by the code that actually encodes the message and its attachment for sending. AFACT this could be done in nsMsgSend.cpp, in nsMsgComposeAndSend::AddCompFieldLocalAttachments() .

Not a blocker, but I'll take a look at this.

Reassigning my self, as I took on bug 476400 instead and that makes this a non-issue. Not sure this is even worth keeping after that bug lands.

I didn't understand this. Should this bug status be NEW? Wasn't it been replaced by bug 476400, which is marked as FIXED? On the other hand, I've experienced another situation in some versions of Thunderbird (2.0.0.21 among them): I can't see options while right-clicking a text/x-moz-deleted-attachment, but even so I still can open it by double-clicking the file. Apparently nothing wrong was recorded in mimeTypes.rdf, but if I forward the message, the x-moz-deleted type is reproduced.

(In reply to comment #3) > I didn't understand this. Should this bug status be NEW? Wasn't it been > replaced by bug 476400, which is marked as FIXED? Celi (and Mason), are you saying this works for you?

Bugged conversation ;-) - I don't know what do you mean by "this works for you". I mean the following: this bug was reported a year and a half ago, and, as far as I can see, had been replaced by bug 476400, which is already closed as FIXED. But this one is still marked as NEW. According to my own experience in the last days, the issues reported here keep going on. I have the same expectations as Mason's a.) and b.), so I'd like to know opinions about this. In my opinion, this is not closed, maybe it should be reopened.

see also bug #639460 comment #6