Last Comment Bug 155537 - Text in multipart message does not show if Content-Type is blank [Mail with attachments sent by Outlook don't work]
: Text in multipart message does not show if Content-Type is blank [Mail with a...
Status: RESOLVED FIXED
:
Product: MailNews Core
Classification: Components
Component: MIME (show other bugs)
: Trunk
: All All
: -- normal with 4 votes (vote)
: mozilla1.9beta3
Assigned To: Magnus Melin
:
Mentors:
: 140409 159148 169874 210606 214478 243009 270769 277800 321711 409137 420998 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-07-03 00:57 PDT by Saajan Chana
Modified: 2013-08-29 01:22 PDT (History)
18 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Here is an example of a message that gets mangled (133.17 KB, message/rfc822)
2002-07-03 01:00 PDT, Saajan Chana
no flags Details
A simple mail with a blank content-type that does not display consistantly (592 bytes, text/plain)
2002-10-07 04:36 PDT, Andrew Brady
no flags Details
email body displayed in-line (33.96 KB, image/png)
2002-10-07 04:38 PDT, Andrew Brady
no flags Details
body displayed as attachment (34.58 KB, image/png)
2002-10-07 04:39 PDT, Andrew Brady
no flags Details
Folder with a good message & a broken message (6KB) (5.74 KB, text/plain)
2004-01-17 08:25 PST, Mike Cowperthwaite
no flags Details
Outlook v10 Multipart Message (2.98 KB, text/plain)
2004-06-01 14:31 PDT, Chris Bartow
no flags Details
proposed fix (8.55 KB, patch)
2007-12-28 12:00 PST, Magnus Melin
mozilla: review+
mozilla: superreview+
Details | Diff | Review

Description Saajan Chana 2002-07-03 00:57:42 PDT
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.
Comment 1 Saajan Chana 2002-07-03 01:00:47 PDT
Created attachment 90045 [details]
Here is an example of a message that gets mangled
Comment 2 Daniel Wang 2002-08-31 21:01:01 PDT
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?
Comment 3 Andrew Brady 2002-10-07 04:33:48 PDT
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
Comment 4 Andrew Brady 2002-10-07 04:36:19 PDT
Created attachment 101970 [details]
A simple mail with a blank content-type that does not display consistantly
Comment 5 Andrew Brady 2002-10-07 04:38:55 PDT
Created attachment 101971 [details]
email body displayed in-line
Comment 6 Andrew Brady 2002-10-07 04:39:44 PDT
Created attachment 101972 [details]
body displayed as attachment
Comment 7 Mike Cowperthwaite 2004-01-16 15:52:22 PST
*** Bug 210606 has been marked as a duplicate of this bug. ***
Comment 8 Mike Cowperthwaite 2004-01-16 16:21:32 PST
Altho the blank  Content-Type  header may be a clue, see also 
bug 199298 comment 1  for another issue that may apply.
Comment 9 Mike Cowperthwaite 2004-01-17 08:22:57 PST
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].
Comment 10 Mike Cowperthwaite 2004-01-17 08:25:25 PST
Created attachment 139276 [details]
Folder with a good message & a broken message (6KB)

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.)
Comment 11 Simon Montagu :smontagu 2004-05-08 13:29:10 PDT
*** Bug 243009 has been marked as a duplicate of this bug. ***
Comment 12 Robert Hofmann 2004-05-10 06:21:43 PDT
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!
Comment 13 Mike Cowperthwaite 2004-05-10 11:56:51 PDT
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.
Comment 14 Robert Hofmann 2004-05-11 06:07:28 PDT
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?
Comment 15 WADA 2004-05-11 12:07:18 PDT
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.
Comment 16 Mike Cowperthwaite 2004-05-11 12:18:45 PDT
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.
Comment 17 Chris Bartow 2004-06-01 14:31:25 PDT
Created attachment 149774 [details]
Outlook v10 Multipart Message

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.
Comment 18 Chris Bartow 2004-06-01 14:34:13 PDT
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.
Comment 19 Mike Cowperthwaite 2004-06-07 10:01:17 PDT
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.
Comment 20 WADA 2004-06-07 10:36:58 PDT
(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 :-) 
Comment 21 Mike Cowperthwaite 2004-11-19 10:03:41 PST
*** Bug 270769 has been marked as a duplicate of this bug. ***
Comment 22 Radu 2004-11-25 00:18:52 PST
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.)
Comment 23 Peter Kay 2004-12-15 14:33:17 PST
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?
Comment 24 David :Bienvenu 2004-12-15 14:36:05 PST
has anyone tried this with importing with tbird 1.0? I fixed a bunch of outlook
import problems.
Comment 25 Peter Kay 2004-12-16 10:22:11 PST
I will try the next time I'm in the office late.
Comment 26 Mike Cowperthwaite 2005-01-11 07:28:18 PST
*** Bug 277800 has been marked as a duplicate of this bug. ***
Comment 27 WADA 2005-01-11 13:57:49 PST
(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?
Comment 28 Doug Wright 2005-01-14 10:02:14 PST
*** Bug 169874 has been marked as a duplicate of this bug. ***
Comment 29 Doug Wright 2005-01-14 10:02:27 PST
*** Bug 214478 has been marked as a duplicate of this bug. ***
Comment 30 WADA 2005-01-28 18:36:07 PST
(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)?
Comment 31 WADA 2005-01-28 19:01:22 PST
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
Comment 32 WADA 2005-01-31 17:18:33 PST
(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.
Comment 33 Mike Cowperthwaite 2005-02-19 09:31:27 PST
xref bug 230377.
Comment 34 Mike Cowperthwaite 2005-12-30 12:18:12 PST
*** Bug 321711 has been marked as a duplicate of this bug. ***
Comment 35 Josh D S Davis 2006-01-20 09:13:58 PST
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.
Comment 36 Mike Cowperthwaite 2006-01-20 10:41:41 PST
(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.
Comment 37 Josh D S Davis 2006-01-20 11:04:30 PST
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.
Comment 38 Peter Kirk 2006-01-20 12:04:00 PST
(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.
Comment 39 Josh D S Davis 2006-01-20 13:08:26 PST
(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.
> 

Comment 40 (not reading, please use seth@sspitzer.org instead) 2007-06-21 14:59:23 PDT
sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Comment 41 Magnus Melin 2007-12-25 08:47:17 PST
*** Bug 409137 has been marked as a duplicate of this bug. ***
Comment 42 Magnus Melin 2007-12-28 12:00:27 PST
Created attachment 294768 [details] [diff] [review]
proposed fix

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 43 David :Bienvenu 2007-12-28 12:28:19 PST
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...
Comment 44 Magnus Melin 2007-12-28 13:17:24 PST
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
Comment 45 Magnus Melin 2008-03-06 12:33:55 PST
*** Bug 420998 has been marked as a duplicate of this bug. ***
Comment 46 Thomas D. (currently busy elsewhere; needinfo?me) 2013-08-29 01:19:42 PDT
*** Bug 140409 has been marked as a duplicate of this bug. ***
Comment 47 Thomas D. (currently busy elsewhere; needinfo?me) 2013-08-29 01:22:41 PDT
*** Bug 159148 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.