133.17 KB, message/rfc822
592 bytes, text/plain
33.96 KB, image/png
34.58 KB, image/png
5.74 KB, text/plain
2.98 KB, text/plain
8.55 KB, patch
|Details | Diff | Splinter Review|
When I receive mail from people who use Outlook/Outlook Express which contains an attachment, Mozilla doesn't display the message properly. Instead it lists *2* attachments, the original one and one called Part 1.1 (which contains the actual message), and displays nothing in the view messasge window. There seems to be no way to view the message itself short of opening this 'attachment' in a text editor. In addition, one mail that I received containing a JPEG image actually displayed the image in the view message window. The original message was, as before, in the form of an attachment.
The sample e-mail does not specify the content-type of the text message. if you change Content-Type: to Content-Type: text/plain; charset=us-ascii; format=flowed the message would work fine related to bug 162138?
Summary: Mail with attachments sent by Outlook don't work → Text in multipart message does not show if Content-Type is blank [Mail with attachments sent by Outlook don't work]
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 I have emails that come with a blank Content-type. Sometimes these are rendered as blank messages with a single attachment. Other times the message is shown without attachment. I realise the incoming message is not correct and the sender mailer is "broken". For instance if I display the message and then repeatedly switch the View -> Headers between Normal and All, sometimes the email is viewed with attachment and sometimes without. Attachments to follow: 1) A simple example message that displays inconsistantly 2) A screendump of the mail with view as attachment 3 [details] [diff] [review]) A scrrendump of the mail with view without attachment
QA Contact: yulian → stephend
*** Bug 210606 has been marked as a duplicate of this bug. ***
Altho the blank Content-Type header may be a clue, see also bug 199298 comment 1 for another issue that may apply.
This seems to be the earliest bug about this problem. The summary is accurate. I'll attach a simple mailfolder file with a test case. Confirming this bug; replicated with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040108 I no longer believe that bug 199298 comment 1 has anything to do with anything; however, that bug is a potential dupe of this one. If someone can verify that the "Part 1.1" shows up (with an empty message body) under Mac or Linux (as I imagine it does), we could widen the Platform/OS fields on this bug. Is it feasible to perform some sort of autodetect on an untyped attachment? Andrew Brady's attached email is interesting. In the case of a single-part mail with a blank Content-Type, I am always seeing the message displayed null with an attachment called "attachment", as shown in attachment 101972 [details]. I have not seen the message body displayed inline, as in attachment 101971 [details].
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is a sample mailfolder with two nearly identical messages: one created by Mozilla with a small attachment, the other the same thing only edited to have a blank Content-Type. (Close Mozilla, place the file into a Mail account subdirectory, open Mozilla -- it should automatically appear as a new folder in that account, containing the msgs.)
*** Bug 243009 has been marked as a duplicate of this bug. ***
Hmmmm... This bug was opened nearly two years ago and still no solution. Mine (see last dupe) seems to be also the same kind of problem. (See attach http://bugzilla.mozilla.org/attachment.cgi?id=147976&action=view for example!) Anyway, why can an empty content-type not just be treated as plain/text? This sould solve our problem. In my case, the faulty email is created by a Linux-system. So it is not an Outlook-specific thing but more a general problem. And for me this is a really bad problem. Because better to see some ASCII-rubbish (if it is not text/plain) than to see an empty message. And because this bug is now in since around two years, it is time to do something!
Updating component. See also bug 53711, bug 134663; the problem messages in both bugs have a part (body or attachment) that doesn't display due to a malformed Content-type. As with those bugs, Mozilla is arguably doing the right thing.
Assignee: mscott → sspitzer
Component: Attachments → MIME
QA Contact: stephend
Well, if there is an incorrect type and diplaying the body is not ok, I can live with this. But the question now is, more or less, is an empty content-type incorrect? Formally yes. But IHMO an empty ct should be treated as there is no ct. And if there is not ct-tag in the mail, it will be displayed correctly. Because at this point, we are talking about usability. It is not very useful, to display a message with content as an empty msg. This is a kind of "information hiding". You know, why IE made the game, compared to NS4 in the past? Because you could view nearly every page with it. With NS4, you sometimes just saw an empty page (frame) if there was an error in. And because the user could not change the site, he changed the client - his PC - to a browser that could display the faulty page. Of course the better way would be to code correct html... And if no browser can display a page correct, it will be changed (sooner or later). But as soon as I might loose information, I switch to the software that shows me even an incorrect mail. (And a normal user does not use "view source" to read a mail!) In this case, the question for me is: do we want a piece of software that follows the standards 100% correct or do we want a software that users can work with? From the definitions Mozilla currently is right. But from users point of view, it is wrong. For whom do we want to write software? For w3c/rfc-authors or for the users?
OS: Windows 98 → All
Hardware: PC → All
RFC 2045 says ; ( http://www.faqs.org/rfcs/rfc2045.html ) > 5.2. Content-Type Defaults > > Default RFC 822 messages without a MIME Content-Type header are taken > by this protocol to be plain text in the US-ASCII character set, > which can be explicitly specified as: > > Content-type: text/plain; charset=us-ascii > > This default is assumed if no Content-Type header field is specified. > It is also recommend that this default be assumed when a > syntactically invalid Content-Type header field is encountered. In > the presence of a MIME-Version header field and the absence of any > Content-Type header field, a receiving User Agent can also assume > that plain US-ASCII text was the sender's intent. Plain US-ASCII > text may still be assumed in the absence of a MIME-Version or the > presence of an syntactically invalid Content-Type header field, but > the sender's intent might have been otherwise.
Well, there you have it: the spec agrees with what is desired, and Mozilla is arguably *not* doing the right thing here. > For whom do we want to write software? For w3c/rfc-authors or for the users? I'm not lobbying one way or the other on that point. However, just blindly assuming that you can display the file inline (as text/plain) can lead to additional user complaints if the MIME part happens to be <html> ("Mozilla doesn't display my HTML mail correctly") or an image ("Mozilla shows my email as gibberish") or in an unusual charset (see the discussion in bug 241821). Note, also, that bug 162138 requests that Mozilla be *more* restrictive in what it shows, for a particular and relatively safe situation. There may be other bugs in that vein as well.
This is an example of the message source that causes this big when someone using Outlook XP (v.10) sends a message with an inline background attachment.
I have added another example where it will always occur when someone sends a message with an inline background with their message in MS Outlook XP (2002, v.10). Instead of the message being rendered with the background and text in front, the message is just shown as a blank message with an attachment. The Content-type on the inline text/html part is missing.
I'm going to contradict my comment 16 -- the spec argues to treat a *missing* Content-Type as text/plain, but the problem here is an *blank* Content-Type -- the header exists, but it doesn't specify anything at all. It's not clear that the spec addresses this point.
(In reply to comment #19) > the spec argues to treat a *missing* Content-Type as text/plain This is basic description of RFC 822. In addition to this case(No Content-Type: header), RFC 2045 also says ; > This default is assumed if no Content-Type header field is specified. This is for Content-Type: header with no parameter, which is this bug's case. Mike, I don't think you have to contradict your comment 16 :-)
*** Bug 270769 has been marked as a duplicate of this bug. ***
RFC 2045, point 5.2., states: This default is assumed if no Content-Type header field is specified. It is also recommend that this default be assumed when a syntactically invalid Content-Type header field is encountered. Also, RFC 2045 defines the Content-Type syntax at point 5.1. as: content := "Content-Type" ":" type "/" subtype *(";" parameter) ; Matching of media type and subtype ; is ALWAYS case-insensitive. According to this, the string: "Content-Type: " is syntactically invalid Content-Type header field (it contains neither type, "/" nor subtype). Therefore, to comply with RFC 2045, the contents of the message should be rendered as having: Content-type: text/plain; charset=us-ascii (also according to RFC 2045, point 5.2.)
Getting mangled HTML would be better than not getting any information at all. I'm trying to bring a co-worker over from Outlook, and it doesn't look good when all the e-mail with attachments doesn't display the message body... I guess I see this as two bugs: 1. Mozilla doesn't appear to be in compliance with this obscure (from my point of view) bit of the spec. 2. Mozilla doesn't properly import Outlook mail (which stores e-mail which may or may not be in compliance with the spec). 1. would be great to fix. 2. has, I think, a higher priority, at least as long as we want people switching from Outlook to Mozilla. Is it easy/possible to patch the conversion code so that such blank Content-Types get some default value during the process?
has anyone tried this with importing with tbird 1.0? I fixed a bunch of outlook import problems.
I will try the next time I'm in the office late.
*** Bug 277800 has been marked as a duplicate of this bug. ***
(In reply to comment #24) > has anyone tried this with importing with tbird 1.0? I fixed a bunch of outlook > import problems. David, I think this bug is NOT for problem of importing from Outlook family, even though many of "No Content-Type: header" or "No parameter on Content-Type: header" mails are produced by importing from Oultlook family. Ie. this bug is for problem 1 in Comment #23 instead of problem 2 in Comment #23. I believe "importing from Outlook family" is not the only cause of this bug. Is it wrong?
*** Bug 169874 has been marked as a duplicate of this bug. ***
*** Bug 214478 has been marked as a duplicate of this bug. ***
(In reply to comment #24) > I fixed a bunch of outlook import problems. I can't find any description nor patch in Bug 219181. > Bug 219181 : attachments get messed up when importing messages from outlook David, by which bug(s)?
I've found that David fixed bug 199298, one of the "a bunch of outlook import problems", on 2004-11-04. > Bug 199298 : Import from Outlook moves msg body to Part 1.1 attachment
(In reply to comment #24) > has anyone tried this with importing with tbird 1.0? I fixed a bunch of outlook > import problems. A Japanese tester reported to Bugzilla Japan that "non didplayed text problem(this bug) and part 1.1 problem" did not occur when imported mails from MS Outlook 2000 by Thunderbird 1.0.
xref bug 230377.
*** Bug 321711 has been marked as a duplicate of this bug. ***
When importing mail from Outlook 2003, TB gets Content-Type: text/plain, yet the body clearly has html all over inside. From an end result, this results in an HTML email being unreadable in TB. The issue seems to be various points from the source of the import. If the Content-Type is incorrect, which is the case with my import, and some of the original imports with no Content-Type, then is it TB's job to rewrite the Content-Type header line to text/html when it detects html email? From a "right thing to do", the source of the problem should be corrected. We all know that the liklihood of that is 296520562058620856 to one against. As such, for a usability/image-of-Thunderbird standpoint, this might want to be converted to an enhancement request for TB to detect HTML and render appropriately, even if the content-type is text/plain or null. I definitely have a vested interest in this second solution; however, this is the age-old developer vs everyone else standpoint. In the developer world, things should be done "the right way". In the user world, things should work, regardless of whether it's kludgy.
(In reply to comment #35) > When importing mail from Outlook 2003, TB gets Content-Type: text/plain, > yet the body clearly has html all over inside. And that applies to this bug how? The answer is: it doesn't. There are many bugs about Content-Type -- if you can't find one about your particular symptom, then open one. Don't comment in bugs that you haven't fully read and understood, or which aren't about the symptom you think is a problem.
I was referred here by the bug that DID seem to relate, and there were multiple updates in this bug diverging from the core topic. I apologize for the mistake.
(In reply to comment #35) ... > As such, for a usability/image-of-Thunderbird standpoint, this might want to be > converted to an enhancement request for TB to detect HTML and render > appropriately, even if the content-type is text/plain or null. > Please, no to this one! Some of us sometimes want to be able to put HTML source on a web page or in an attachment so that it is visible as HTML source (e.g. to teach others how to write proper HTML), by marking it as text/plain. Please don't consider overriding users' explicitly specified content-type. It might be a different matter if there is no content-type specified.
(In reply to comment #38) See Bug 323184 for Outlook import conversion. My post in 35 was off topic and should be disregarded from this thread. I apologize for the confusion. > (In reply to comment #35) > ... > > As such, for a usability/image-of-Thunderbird standpoint, this might want to be > > converted to an enhancement request for TB to detect HTML and render > > appropriately, even if the content-type is text/plain or null. > > > Please, no to this one! Some of us sometimes want to be able to put HTML source > on a web page or in an attachment so that it is visible as HTML source (e.g. to > teach others how to write proper HTML), by marking it as text/plain. Please > don't consider overriding users' explicitly specified content-type. It might be > a different matter if there is no content-type specified. >
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
The problem was that when the header value is an empty string we iterate over to the next line and the value will be something like the first character of what's on the next line header name. With this patch I can see all the test messages attached to this bug.
Comment on attachment 294768 [details] [diff] [review] proposed fix sr=bienvenu, except, instead of + if (!obj->content_type || strlen(obj->content_type) == 0) you can just use if (!obj->content_type || !*(obj->content_type)) it's faster and less code than doing strlen...
Thx! Fixed the nit and checked in. Checking in mailnews/mime/src/mimehdrs.cpp; /cvsroot/mozilla/mailnews/mime/src/mimehdrs.cpp,v <-- mimehdrs.cpp new revision: 1.76; previous revision: 1.75 done Checking in mailnews/mime/src/mimeobj.cpp; /cvsroot/mozilla/mailnews/mime/src/mimeobj.cpp,v <-- mimeobj.cpp new revision: 1.32; previous revision: 1.31 done ->FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M11
You need to log in before you can comment on or make changes to this bug.