244618 - Need an option to define a custom mime-type (for attaching files)

Status: NEW

(Thunderbird :: Preferences, enhancement)

Description

[Tom Billiet]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

I mail a lot of maple-file (mathematics program). It saves it's files with
".mws" extention. The information in the files is plain text, but you can't read
anything of it, it's a custom syntax used by maple.
So when I mail a file, thunderbird adds "text/plain" as mime type, what results
in a text-preview at the receiver's side, and also the icon form notepad is
used. But you can't do anything with the preview, zo I would like to tell
thunderbird to use the mime-type "application/maple"
Mozilla suite has an option to defice custom mime-types, and it works perfect
there, so I would like to see this option in thunderbird too.
Thanks!

Reproducible: Always
Steps to Reproduce:
1. mail a file with plain text, which is "unreadable" for human people, and has
no ".txt" extension
2. open the mail with mozilla (thunderbird) (not outlook, it ignores the mime-type)

Comment 1

[Mike Cowperthwaite]

xref bug 236212 comment 7,9,10,11,12.  (Ignore the stuff about the Windows 
registry, as that seems to make no difference.)  The capability described there 
is not available in TB.

I guess TB's interface is supposed to make it easier to not have to deal with 
MIME types that people don't understand very well, but for those of us who do 
understand them, the program is kinda crippled in this respect.

See also bug 261766.

Comment 2

[Mike Cowperthwaite]

*** Bug 251485 has been marked as a duplicate of this bug. ***

Comment 3

[Mike Cowperthwaite]

*** Bug 267912 has been marked as a duplicate of this bug. ***

Comment 4

[Mike Cowperthwaite]

Here's a workaround for this problem:

Let's say you want to attach files with a ".blx" extension.  If you have a known 
MIME type to associate with it (e.g. application/bollocks) use that; otherwise, 
just make one up and use the x- prefix -- e.g.: application/x-blx

Locate  mimeTypes.rdf  in your Thunderbird profile, and load it into a text 
editor.  Add a new entry structured as follows:
  <RDF:Description RDF:about="urn:mimetype:application/x-blx"
                   NC:value="application/x-blx"
                   NC:editable="false"
                   NC:fileExtensions="blx"
                   NC:description="">
  </RDF:Description>

(Be *sure* you don't put that inside another Description tag!)  Restart TB, and 
you should find that attachments with this filetype are now sent out as with the 
specified MIME type, and should be BASE64'd.  (Might be sent plain-text if the 
MIME type used is a text/* type.)

Do not use application/octet-stream as the MIME type!  You really don't want to 
associate that generic type with any known extension.

Comment 5

[Mike Cowperthwaite]

There may also be a way (under Windws) to work around this problem, by creating 
registry entries for the file extension and the associated MIME type but I can't 
figure out exactly how to make this work.

I have one pre-existing pair of registry keys -- HKCR\<extension> and 
HKCR\MIME\Content-Type\<type>  -- not referenced at all in any of the TB config 
files.  If I attach a plain-text file with that extension to a message, it's 
given the corresponding MIME type, and BASE64'd.  But I haven't been able to 
create a new pair of keys that work the same way.

Comment 6

[Dejan Rodiger]

I have tried what Mike had suggested and nothing worked.
I have even added Content Type to registry and restarted and it doesn't work.
Here is my mimetypes.rdf
---start---
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:NC="http://home.netscape.com/NC-rdf#">

  <RDF:Description about="urn:mimetypes"> 
    <NC:MIME-types> 

    </NC:MIME-types> 
  </RDF:Description> 
</RDF:RDF>
<RDF:Seq about="urn:mimetypes:root">
    <RDF:Description RDF:about="urn:mimetype:application/x-cfr"
                 NC:value="application/x-cfr"
                 NC:editable="false"
                 NC:fileExtensions="cfr"
                 NC:description="eConfig file">
    </RDF:Description>
</RDF:Seq>
---end---

What else could I try?

Comment 7

[Tom Billiet]

Mike's sollution works fine for me, thanks!

Comment 8

[Mike Cowperthwaite]

(In reply to comment #6)

> What else could I try?

Hmm.  In comment 4, I wrote:
> (Be *sure* you don't put that inside another Description tag!)

You've taken that too far!  Did you add that RDF:Seq tag, or did that exist 
already?  The new RDF:Description tag should be nested within the top-level 
RDF:RDF tag.

Comment 9

[Dejan Rodiger]

Thanks, it works.
This is profile mimetypes.rdf that works:
--start--
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:NC="http://home.netscape.com/NC-rdf#">

  <RDF:Description about="urn:mimetypes"> 
    <NC:MIME-types> 
      <RDF:Seq about="urn:mimetypes:root">
      </RDF:Seq>
    </NC:MIME-types> 
  </RDF:Description> 
  <RDF:Description RDF:about="urn:mimetype:application/x-cfr"
    NC:value="application/x-cfr"
    NC:editable="false"
    NC:fileExtensions="cfr"
    NC:description="">
  </RDF:Description>
</RDF:RDF>
--end--

Comment 10

[David Klein]

*** Bug 273402 has been marked as a duplicate of this bug. ***

Comment 11

[Mike Cowperthwaite]

Bad move, Doug -- this *is* a Preferences issue.

Comment 12

[Mike Cowperthwaite]

See bug 234245.

Comment 13

[Mike Cowperthwaite]

Bug 302760 is another example of why this function is desirable.

Here's another way to get the mimeTypes updated correctly:
1) Create a message with an attachment with the extension.
2) Send it (or Send Later).  Close TB.
3) Edit the Sent (or Unsent) folder file and locate the message.
4) Edit the headers to the attachment to change "text/plain" into the desired 
MIME type.  Save the folder file.
5) Reopen TB.  Find the message in the edited folder, and open it.
6) Double-click the attachment.  TB will prompt "what to do with this"?  Select 
either Save To Disk, or "Open With" whatever the preferred application is --
AND, very important, select "Always do this."  (Don't worry if the data has been 
corrupted for that application, that's not important.  Also note, you can go 
back and change the default action later.)

After opening/saving the attachment, the mimeTypes.rdf file should be updated 
correctly; and subsequent attachments will be sent as BASE64 unless the MIME 
type is "known to be text" by TB (such as Postscript PS/EPS files -- 
bug 176258).

Comment 14

[Raymond Koekemoer]

(In reply to comment #13)
> Bug 302760 is another example of why this function is desirable.
> 
> Here's another way to get the mimeTypes updated correctly:
> 1) Create a message with an attachment with the extension.
> 2) Send it (or Send Later).  Close TB.
> 3) Edit the Sent (or Unsent) folder file and locate the message.
> 4) Edit the headers to the attachment to change "text/plain" into the desired 
> MIME type.  Save the folder file.
> 5) Reopen TB.  Find the message in the edited folder, and open it.
> 6) Double-click the attachment.  TB will prompt "what to do with this"?  Select 
> either Save To Disk, or "Open With" whatever the preferred application is --
> AND, very important, select "Always do this."  (Don't worry if the data has been 
> corrupted for that application, that's not important.  Also note, you can go 
> back and change the default action later.)
> 
> After opening/saving the attachment, the mimeTypes.rdf file should be updated 
> correctly; and subsequent attachments will be sent as BASE64 unless the MIME 
> type is "known to be text" by TB (such as Postscript PS/EPS files -- 
> bug 176258).

Great fix! Simpler solution though:
On step 2 don't exit TB
Skip steps 3 & 4
viola!

Comment 15

[Mike Cowperthwaite]

(In reply to comment #14)
> Great fix! Simpler solution though:
> On step 2 don't exit TB
> Skip steps 3 & 4

I don't see how that fixes anything.  The whole point is to create a specific MIME type associated with the file extension.  If the message being composed *already* has the correct MIME type, there is no need to do anything special at all; if it doesn't already have the correct MIME type, then the steps you suggest skipping are in fact necessary.

Comment 16

[lionel valero]

Hello,

I faced the problem with my microsoft visio file, under windows XP, the open with is grayed out.

- TB1509 windows xp -

I installed TB1509 on linux and try to open a visio file, and i was able to choose the program, i copied the "MimeTypes.rdf" generated by the action, and copied it to my windows profile, to make sure i did not make a mistake, doing my own file.

<RDF:RDF xmlns:NC="http://home.netscape.com/NC-rdf#"
         xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <RDF:Seq RDF:about="urn:mimetypes:root">
    <RDF:li RDF:resource="urn:mimetype:application/vnd.visio"/>
  </RDF:Seq>
  <RDF:Description RDF:about="urn:mimetype:application/vnd.visio"
                   NC:value="application/vnd.visio"
                   NC:editable="true"
                   NC:fileExtensions="vsd"
                   NC:description="">
    <NC:handlerProp RDF:resource="urn:mimetype:handler:application/vnd.visio"/>
  </RDF:Description>
  <RDF:Description RDF:about="urn:mimetypes">
    <NC:MIME-types RDF:resource="urn:mimetypes:root"/>
  </RDF:Description>
  <RDF:Description RDF:about="urn:mimetype:handler:application/vnd.visio"
                   NC:alwaysAsk="true"
                   NC:saveToDisk="false"
                   NC:useSystemDefault="false"
                   NC:handleInternal="false">
    <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/vnd.visio"/>
  </RDF:Description>
  <RDF:Description RDF:about="urn:mimetype:externalApplication:application/vnd.visio"
                   NC:path="C:\Program Files\Microsoft Office\Visio11\VISIO.EXE"
                   NC:prettyName="accton" />
</RDF:RDF>

I also try to modify my viso file extension :

myvisiofile.vsd -> myvisiofile.vsn

and :

NC:fileExtensions="vsd" -> NC:fileExtensions="vsn" as well

and the "open with" was not grayed out (the only thing is that visio do not accept a file without .vsd extension !).

I also made tests with an extension of my creation and associated it to ultraedit using the same block (cf supra) and it works, so it is really related to a windows xp environment.

Regards.

Comment 17

[Mike Cowperthwaite]

> I faced the problem with my microsoft visio file

See bug 280847: Under Windows, Thunderbird considers Visio files to be "executable" and so dangerous -- they're treated like EXE and other executable files, and so are not permitted the ability to open with a default action.  The only option is Save To Disk.  When you move TB 2.0, you'll see an even more restrictive dialog.

At bug 261766 comment 26 I reported some success with getting Visio files to open by tweaking the mimeTypes.rdf file, but I'm not sure if that even works any longer.

Comment 18

[Daniel Essin]

I've just gotten a Mac. I've read all these posts and I still do not understand why the download actions dialog on the mac does not have a button to add a MIME type. After the default installation, the list of download actions is empty. Without an add button how would anything ever get into that list?

I want pdf's to be opened by Acrobat, not Preview. 've set the finder prefs to always open pdf's with Acrobat but Thunderbird ignores that.

I am obviously missing something but I have no idea what.

How do I solve this?

Thank you

Comment 19

[WADA:World Anti-bad-Duping Agency]

Another workaround: Use "Helper Applications" of Seamonkey as mimeTypes.rdf editor
0. When MS Win, download ZIP version of Seamonkey, and unzip.
1. Copy mimeTypes.rdf of Thunderbird(or Firefox) to Seamonkey's profile directory
2. Start Seamokey, and "Helper Applications"
3. Terminate Seamonkey, and copy mimeTypes.rdf of Seamonkey to Tb(or Fx)
4. Restart Thunderbird
Although Bug 229386 is probably not completely resolved yet, I think many entries written by Seamonkey are already usable by Tb or Fx.  

Comment 21

[rsx11m]

Another workaround is to install the MIME Edit extension on Thunderbird, https://addons.mozilla.org/en-US/thunderbird/addon/4498 (has "New Type...").

Comment 22

[D R Evans]

Two comments:

1. This bug just bit me, trying to send a Cabrillo-format radio log which, because it has the extension .cbr, was erroneously given the MIME type application/x-cbr.

2. Forcing the MIME type to be derived from the filename (as opposed to simply making that the "normal" default behaviour for non-power-users) is fundamentally an error. There is no reason to expect the filename to have an "extension" (i.e., end in .<something>), and even if it does, there's no fundamental reason for that name to indicate the file contents. 

For example, I have many plain text documentation files whose name ends in ".doc". Thunderbird gives them an application/msword MIME type instead of text/plain, which is what is reported by the OS.

Similarly, I have many files on my system that are in PDF format, but whose names do not end in .pdf. The OS correctly detects them as application/pdf (if I use the "file" command), but of course Thunderbird does not interrogate the underlying OS, so it marks them rather uselessly as application/octet-stream. The same is true for many other files (i.e., not just PDF).

There very much needs to be a way for the user to override Thunderbird's decision about the MIME type of outgoing attachments, on an attachment-by-attachment basis.

Comment 23

[Orion Poplawski]

This is absurd that the content-type of attachments that you send is selected randomly (it seems) from a list of content-types of messages that you have dealt with previously.  One of our users was sending out emails with .pdf attachments with a content-type of "text/unknown", presumably because someone at sometime sent her such an email.  One side effect is that when she tried to print out such an email, it sent the raw contents of the attachment to the printer as well resulting in pages of garbage.  There needs to be a definitive list of content-types.

This is with TB 45.6.0.