Open Bug 213393 Opened 21 years ago Updated 2 years ago

RTF attachments show compatibility problems with many other mail clients

Categories

(MailNews Core :: Attachments, defect)

x86
Windows XP
defect

Tracking

(Not tracked)

People

(Reporter: giov, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

RTF files sent by mozilla as attachments are not displayed correctly by many
mail programs. This is not a mozilla bug, but it seems that the way that mozilla
builds these attachments is not compatible with the way that many other clients
expect to see one. This may become a problem when communicating with other people.
The MIME headers sent by Mozilla for the attachment are:

Content-Type: text/rtf;
 name="myfile.rtf"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="myfile.rtf" 

I suppose that the problem is "text/rtf". The usual type chosen by other mail
programs is "application/msword" or something like that. So I suspect (but not
sure) that "text/rtf" is maybe standard but not widely understood. Maybe there
should be an option for some kind of compatibility mode?

Reproducible: Sometimes

Steps to Reproduce:
1. Send a mail with an RTF attachment
2 [review]. Try to open it with other mail clients


Actual Results:  
It happens often that the mail sent this way is seen as plain text (no
attachment, the mail text + the source code of the rtf file, all together) in
the other clients.

Expected Results:  
Mozilla should send a mail with RTF attachment which should be understood
correctly by all other mail clients.

Are we sure this is the most practical way of attaching RTF files?

(A workaround exist: Zip the RTF file, as the problem manifests only with RTF
files. However this is not convenient).
Or maybe the problem lies in Content-Disposition: "inline" ? Maybe it should be
"attachment"? The other clients treat mozilla-sent rtf messages as inline junk
(Not an rtf text, nor a downloadable attachment)
Mozilla gets the mimetype from windows.
You can AFAIK override that with a different mime-type in the helper apps.
Hmmm. But in the Windows registry I find that ".rtf" is associated to
"application/msword", not "text/rtf". And yes, I have installed Office *before*
Mozilla.
Another thing: from what I have read on Usenet, it seems anyway that rtf may be
associated with either "text/rtf" or "application/rtf". The latter seems to have
less compatibility problems.
This should go from UNCONFIRMED to NEW.  I see this problem still in 
Thunderbird 0.8 on Windows XP.

Also, this ticket should probably be merged with #205871.
Product: MailNews → Core
*** Bug 285857 has been marked as a duplicate of this bug. ***
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
Maybe the problem is that noone looked at this bug ... at least the assigned
person officially does not read BUGMAIL!!
I thought we sent these attachments as text/plain...
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #0)
> I suppose that the problem is "text/rtf". The usual type chosen by other
> mail programs is "application/msword" or something like that. 

When Word is installed, it gloms onto the text/rtf type because it knows how to edit those files, but giving the file a type "application/msword" implies that the file is Word document.  (text/rtf is the native type of MS's old WordPad program, which cannot open Word documents.)


> Maybe there should be an option for some kind of compatibility mode?

I don't think this is a good idea.


> Actual Results:  
> It happens often that the mail sent this way is seen as plain text (no
> attachment, the mail text + the source code of the rtf file, all together)
> in the other clients.

Could you be specific about what "other" clients behave that way?  Have you filed bug reports with *them*?


> Expected Results:  
> Mozilla should send a mail with RTF attachment which should be understood
> correctly by all other mail clients.

Mozilla cannot be responsible for what other clients do or don't do.  If we had to do everything in a way that would allow all other clients to read every message we compose, there would be no attachments, no HTML, nothing but plain text.


(In reply to comment #1)
> Or maybe the problem lies in Content-Disposition: "inline" ? Maybe it should
> be "attachment"?

This may indeed be why the other client is dumping the text/rtf source to the message window, but it's still a bug on *their* side.  If you want to override this, you can change the setting of the preference    mail.inline_attachments
to 'false' -- altho that will affect all attachments, including images.


(In reply to comment #3)
> Hmmm. But in the Windows registry I find that ".rtf" is associated to
> "application/msword", not "text/rtf".

First, double-check that.  Second, check (in TB) the Attachment options' 
"View & Edit Actions" (or, in the suite, Preferences|Navigator|Helper Apps) 
to see if you have an entry for .RTF there -- if you do, that entry determines what MIME type gets used.

Third, try (again) to send a .RTF file, and look at the source of the message in your Sent folder.  I just tested this, and (with no .RTF entry in TB's own MIME registry) TB *definitely* is getting the MIME type for the extension from the Windows registry.


(In reply to comment #8)
> I thought we sent these attachments as text/plain...

??  I hope you're not suggesting that as a solution!

I think this bug should be WontFix'd.
Assignee: sspitzer → nobody
QA Contact: stephend → attachments
Product: Core → MailNews Core
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.