User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 When I receive (TB 0.6GA 20040502, Win2K SP3+, using IMAP against an MS Exchange Server) an email from an Outlook user who composed the email as RTF, the email shows up correctly in the messages list with sender, date, subject, etc. However, when I click on the message, the display in the mail message window is *empty* (as in, all white, no body, no headers). If I select a different message it gets displayed correctly. When I then go back and select the first (RTF) message, the mail message window *is not updated* (so the prior message is still displayed). A plain RTF message with no RTF markup seems to display correctly. I should also notice that I've selected my IMAP INBOX to be available when offline. Reproducible: Always Steps to Reproduce: 1. Send a message to desired mailbox from Outlook, composing as RTF with markup. 2. Connect to mailbox and download message. 3. Select message from message list. Actual Results: The contents of the message is not displayed, nor are any headers. Expected Results: Either attempted to ASCII-fy the RTF, if possible, or present the message as a single "winmail.dat" attachment like it seems the venerable Mozilla MailNews did for some cases. I just checked with Mozilla MailNews on the particular message; it didn't display anything either. Brief discussion on MozillaZine Tbird-General forum is here: http://forums.mozillazine.org/viewtopic.php?t=77690 This is the contents of such an Email from the local INBOX file. Checking with Outlook web access, it only contains a single attachment, so there's no RTF markup, but the email still doesn't display. ------msg_border-- From - Tue May 18 20:01:15 2004 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Received: by mailwest-e6 id <01C43CFC.3A9E3B10@mailwest-e6>; Tue, 18 May 2004 10:19:08 -0700 Message-ID: <A3E375FA108EF94496269A5A96AFCAC12AE27A@mailwest-e6> From: Xxxxxxxx xxx <firstname.lastname@example.org> To: List YYY <email@example.com> Subject: Date: Tue, 18 May 2004 10:19:07 -0700 MIME-Version: 1.0 Content-Type: application/msword; name="Messaging_Tool_Console .doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Messaging_Tool_Console .doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAA+AAAAwh4AAAAAAAAA EAAAxB4AAAEAAAD+////AAAAAIQeAACFHgAAhh4AAIceAACIHgAAiR4AAIoeAACLHgAAjB4AAI0e -- end snippet -- Thanks for looking at this.
This header: Content-Type: application/msword; indicates that the message is not RTF but rather in Word format. Either way, the format of the message is proprietary -- RTF is not an open standard, and Mozilla does not display RTF (or Word) files inline. If the extent of your problem is that the message is not being displayed, this is a dupe of bug 186267 (which has been, quite correctly, resolved as Invalid). > Expected Results: > Either attempted to ASCII-fy the RTF, if possible, or present the message as a > single "winmail.dat" attachment like it seems the venerable Mozilla MailNews > did for some cases. The failure to see the attachment may be due to the content-type header, or not; the only way we'll be able to tell is to actually test on a message. Please provide a (small) sample message; once the message is received, save it as a .EML file and attach it to this bug, using the Create New Attachment link above.
Agreed, however, it'd be nice if we could offer to MIME-decode email body and save as binary? I.e., treat as if the proper MIME-headers were present?
I have a test message I obtained somewhere which has Content-type: image/jpeg This displays inline (because Moz supports JPEG) but it also shows as an attachment, which I could save if I chose. We need to see a test message showing your symptom to figure out why the body-as-attachment is not shown.
No response from reporter; =>WFM Christian Callsen, if you reopen, *please* attach a sample msg to this bug.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.