363764 - .vcs files (and sometime rtf files) get sent as text/plain

Status: RESOLVED WORKSFORME

(MailNews Core :: Attachments, defect)

Description

[David :Bienvenu]

There are some files that look like text but don't display well as text. In particular, I know of two - .vcs files and .rtf files. We should be setting their content type as application/octet-stream, I believe. There are a lot of ways of doing this, but for now I've picked a way that only affects send time...

For the rtf case, you need an rtf file that's big enough so that the unknowndecoder's quick check will pass (rtf files end with a non-text char, but if the file is small enough, the unknown decoder will notice that non-text char). > 20K ought to do it.

Comment 1

[David :Bienvenu]

Attachment: proposed fix

if there are more of these file types, we should make this into a table, I suppose...

I didn't want to mess with registry settings or mime type tables - this is a send time thing, and it really doesn't matter how you've configured things; it's up to the recipient...

Comment 2

[David :Bienvenu]

fixed on trunk and 2.0 branch

Comment 3

[Mike Cowperthwaite]

David, I wish you'd CC'd me on this.  This solution makes me unhappy.  If you're not willing to create a table of useful MIME associations, why bother making the patch?

.RTF files should be either application/rtf or text/rtf.  text/rtf is recognized (somewhere [1]) by Moz as a type that should not be displayed inline; I think it's the type preferred by Microsoft (who own the format after all).  But if this is just a fallback measure, application/rtf is probably a better approach.  I'm running Ubuntu at the moment, and my current config (with TB 1.5.0.8) is assigning application/rtf.

I found the following for .VCS:
  application/hbs-vcs 
  text/calendar 
  text/x-vcalendar

/netwerk/mime/public/nsMimeTypes.h  has a definition for text/calendar.  That seems to make it the obvious type to use.

I'm assuming the |if (type.IsEmpty()...)| part of the patch means that this is done after all previous attempts to identify have completed, right?  That is, you're not overriding an entry from mimeTypes.rtf?


[1] I did an LXR search for "/rtf" and the only instances I found were comments in os2-specific code.  But I've tested this, and a text/rtf attachment is not inlined, unlike random text/* types (such as text/yo-mama).


(In reply to comment #1)
> I didn't want to mess with registry settings or mime type tables

Why not?  I think patching mimeTypes.rdf would have been a more useful way to approach this, but there doesn't seem to be any precedent for putting anything at all in there by default (e.g. text/x-moz-deleted -- see bug 286454).


> this is a send time thing, and it really doesn't matter how you've
> configured things; it's up to the recipient...

What if the recipient happens to be on an identical system which is likewise (for some reason) ignorant of these MIME types?  When the recipient gets this message, she won't be able to associate a default action for handling it -- not even Save -- because it's application/octet-stream.

Comment 4

[David :Bienvenu]

Sorry, Mike, I thought you were automatically cc'ed on everything mailnews.

>I'm assuming the |if (type.IsEmpty()...)| part of the patch means that this is
>done after all previous attempts to identify have completed, right?  That is,
>you're not overriding an entry from mimeTypes.rtf?

Yes, exactly. It's a last ditch attempt to make sure we don't send these types as text plain.

I'm happy to try to make those changes...

Comment 5

[David :Bienvenu]

cc'ing Mike - see previous comment.

Comment 6

[Magnus Melin [:mkmelin]]

Should not be an issue anymore. We don't by default display random text parts.