+++ This bug was initially created as a clone of Bug #501163 +++ This is split off per bug 501163 comment #6. The former Thunderbird attachment preferences pane allowed to verify associations between a file extension and a MIME-type specified application as was set by opening an attachment (adding the file extension and ability to remove a wrong entry back to the new pane is handled in bug 501163). When sending an attachment which is not yet registered in mimeTypes.rdf, the operating system's associations are consulted, under the assumption that those are accurate. Problems occur mainly when an attachment with a file extension is added which is neither known in mimeTypes.rdf nor in the OS associations. In this case, the MIME type is guessed (bug 236212) to be one of text/plain, text/html, or application/octet-stream. Either of those generic MIME types may cause problems at the recipient's side: attachments classified as text may be inappropriately shown inline, binary attachments sent with application/octet-stream do not allow to register a correct MIME-type/application at the recipient's end. Due to the lack of being able to add or edit an association, this cannot be resolved in either the former pane nor the new one introduced by bug 446291. The proposed fix for this issue is to provide an "Add" functionality again, as it was available in the original Mozilla Suite Help Applications dialog. It has to be kept in mind though that a user may need some support in creating such an entry. Following options could be provided on their own or combined to resolve the issue: 1) Provide an "Add" button in the attachment preference pane with a dialog to enter file extension, MIME type, and application; 2) allow to open an attachment by browsing or drag-and-drop (which would be the SeaMonkey equivalent) to establish an association, where the dialog should be prefilled with the values provided by the operating system or the guessed type, then allow the user to make any changes before registering the association in mimeTypes.rdf; 3) add a right-click option to the attachment context menu in the composition window to verify and edit the MIME type for the attachment, maybe open that automatically if an association is not provided and the type was guessed.

I don't think we should have a way to specify the application in the "Add" dialog. This can be done using the existing prefpane code. What we need is a "New" button. Maybe just below the list. Anything we need to enter there is MIME type and extensions as a start to be modified by the existing code. The same dialog should be available for all existing items in their dropdown menu as an "edit" entry, so the exiting entries may be modified. But I'll have a look at a old SeaMonkey 1.x here, as I think it was impossible to edit the MIME type field. If so, I don't think we should add this.

... wrong bug. Will have to reopen a similar bug for SeaMonkey first.

Actually, for SM this should be covered by bug 462629, unless you want to change its scope. This bug here is a spin-off from the Thunderbird bug 501163.

wanted-thunderbird3.1?

I don't think this qualifies for wanted+ because it doesn't sound high-leverage to me at all: I suspect the vast majority of mail senders are unlikely to have any idea that this problem exists, and even those who do are unlikely to be motivated to spend their own time to fix it by hand using anything in a preference window or a context menu. I agree that there is a real problem here, but I'm not convinced that any of the solutions proposed so far are likely to make an appreciable dent in that problem.

A surprisingly high proportion of people who send attachments to me use a client that marks them as octet-stream, making the only way to open them (since TB3 came out with no MIME:Edit add-on option) to save them, open the application and open the file. The vast majority of mail senders may have no idea about this, but that is as likely to result in unopenable as openable attachments. The most recent one (judging by the headers) came from an Exchange Server, so probably from an Outlook (Express) user (there's a "X-MS-Has-Attach: yes " header). That's a pretty common scenario. It may be the sender's fault, but if the sender is unlikely to fix it, it's better for Thunderbird to find a way to work with it if it's straightforward, than to sulk and refuse to cooperate. The file extensions give a pretty good clue. Is it really so undesirable to make TB3 a little more user-friendly by allowing it to use the file extension to decide what application to use to open octet-stream attachments?

See bug 576663 for a use case. There, it is necessary to override the guessing algorithm which comes up with XML as a build-in known type rather than the type associated with that file extension in the operating system. This relates to the generic application/octet-stream, but nevertheless appears to be solvable by establishing correct MIME associations for that file extension.

I am so amazed by the bull-headed post by Manuel Reimer YES!!! We DO, I repeat WE DO need a way to add handlers to mime types that TB has no idea how to handle, has the WRONG guess of the handler app. This is a serious missing capability in TB. Most of the email attachments I get are from Windows users, using Mime types that neither my Fedora OS nor TB has handlers for. I find the "philosophical" arguments against providing this solution as idiotic at best. They are akin to saying" Let's keep TB Broken until I, Mr. Philosopher, have conjured a solution that I, (emphasis on I), like. Come on guys - give us the ability to add our choice of handlers! The release literature brags "This is YOUR mail client .....it is all YOURS". Well, LIVE UP TO IT!!

JD: First of all, please refrain from personal attacks as they are in violation with bugzilla etiquette rules. As a matter of fairness, Manuel Reimer retracted his comment #1 two minutes later, though - reading it again - I still have problems to understand what his point is. > Most of the email attachments I get are from Windows users, using Mime types > that neither my Fedora OS nor TB has handlers for. In this case, you should be prompted to pick a helper application when opening an unknown attachment type. The main reason I had filed this bug was to avoid issues when sending an attachment, either to override bad handler definitions by the operating system, or to avoid guessed types where no default exists. > (In reply to comment #1) But I'll have a look at a old SeaMonkey 1.x here, > as I think it was impossible to edit the MIME type field. For reference, SeaMonkey 1.x allowed editing the MIME type in both "New Type" and "Edit" dialog (it's the same window as attached here).