155537 - Text in multipart message does not show if Content-Type is blank [Mail with attachments sent by Outlook don't work]

Status: RESOLVED FIXED

(MailNews Core :: MIME, defect)

Description

[Saajan Chana]

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]

Attachment: Here is an example of a message that gets mangled

Comment 2

[Daniel Wang]

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]

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]

Attachment: A simple mail with a blank content-type that does not display consistantly

Comment 5

[Andrew Brady]

Attachment: email body displayed in-line

Comment 6

[Andrew Brady]

Attachment: body displayed as attachment

Comment 7

[Mike Cowperthwaite]

*** Bug 210606 has been marked as a duplicate of this bug. ***

Comment 8

[Mike Cowperthwaite]

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]

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]

Attachment: 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]

*** Bug 243009 has been marked as a duplicate of this bug. ***

Comment 12

[Robert Hofmann]

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]

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]

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:World Anti-bad-Duping Agency]

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]

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]

Attachment: 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]

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]

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:World Anti-bad-Duping Agency]

(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]

*** Bug 270769 has been marked as a duplicate of this bug. ***

Comment 22

[Radu]

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]

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]

has anyone tried this with importing with tbird 1.0? I fixed a bunch of outlook
import problems.

Comment 25

[Peter Kay]

I will try the next time I'm in the office late.

Comment 26

[Mike Cowperthwaite]

*** Bug 277800 has been marked as a duplicate of this bug. ***

Comment 27

[WADA:World Anti-bad-Duping Agency]

(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]

*** Bug 169874 has been marked as a duplicate of this bug. ***

Comment 29

[Doug Wright]

*** Bug 214478 has been marked as a duplicate of this bug. ***

Comment 30

[WADA:World Anti-bad-Duping Agency]

(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:World Anti-bad-Duping Agency]

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:World Anti-bad-Duping Agency]

(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]

xref bug 230377.

Comment 34

[Mike Cowperthwaite]

*** Bug 321711 has been marked as a duplicate of this bug. ***

Comment 35

[Josh D S Davis]

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]

(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]

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]

(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]

(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 [e-mail] instead)]

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 42

[Magnus Melin [:mkmelin]]

Attachment: 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]

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 [:mkmelin]]

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