221426 - Multi part Mail message source displayed (incorrectly), if multiple "Content-type" headers exist(malformed mail).

Status: RESOLVED INVALID

(MailNews Core :: MIME, defect)

Description

[Cecelia S]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030925
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030925

Mail messages with "Content-type: text/plain;" declared before "To:" and "From:"
 fields display as plain text:

Works properly:

From - Mon Oct  6 15:54:46 2003
X-UIDL: 141c50156cb97042aaaa7577dd7db200
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Apparently-To: [e-mail] via 216.136.131.236; Mon, 06 Oct 2003
13:03:15 -0700
Return-Path: <[e-mail]>
Received: from 64.4.240.74  (EHLO smtp1.nix.paypal.com) (64.4.240.74)
  by mta215.mail.scd.yahoo.com with SMTP; Mon, 06 Oct 2003 13:03:14 -0700
Received: from web1.nix.paypal.com (web1.nix.paypal.com [10.192.2.1])
	by smtp1.nix.paypal.com (Postfix) with SMTP id 42A023F3C6
	for <[e-mail]>; Mon,  6 Oct 2003 13:03:09 -0700 (PDT)
Received: (qmail 1644 invoked by uid 99); 6 Oct 2003 20:03:09 -0000
Date: Mon, 06 Oct 2003 13:03:09 -0700
Message-Id: <[e-mail]>
>>>DELETED "Content-type" INFO<<<
From: [e-mail]
To: [e-mail]
Subject: Receipt for your Payment to sayles-enterprises 
MIME-Version: 1.0
Content-Type: multipart/alternative;
  boundary="NextPart_048F8BC8A2197DE2036A"

This is multi-part message in MIME format.

--NextPart_048F8BC8A2197DE2036A
Content-Type: text/plain; charset=iso-8859-1




Problem:

From - Mon Oct  6 15:54:46 2003
X-UIDL: 141c50156cb97042aaaa7577dd7db200
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Apparently-To: [e-mail] via 216.136.131.236; Mon, 06 Oct 2003
13:03:15 -0700
Return-Path: <[e-mail]>
Received: from 64.4.240.74  (EHLO smtp1.nix.paypal.com) (64.4.240.74)
  by mta215.mail.scd.yahoo.com with SMTP; Mon, 06 Oct 2003 13:03:14 -0700
Received: from web1.nix.paypal.com (web1.nix.paypal.com [10.192.2.1])
	by smtp1.nix.paypal.com (Postfix) with SMTP id 42A023F3C6
	for <[e-mail]>; Mon,  6 Oct 2003 13:03:09 -0700 (PDT)
Received: (qmail 1644 invoked by uid 99); 6 Oct 2003 20:03:09 -0000
Date: Mon, 06 Oct 2003 13:03:09 -0700
Message-Id: <[e-mail]>
Content-type: text/plain; charset=iso-8859-1 >>>THIS IS THE PROBLEM LINE<<<
From: [e-mail]
To: [e-mail]
Subject: Receipt for your Payment to sayles-enterprises 
MIME-Version: 1.0
Content-Type: multipart/alternative;
  boundary="NextPart_048F8BC8A2197DE2036A"

This is multi-part message in MIME format.

--NextPart_048F8BC8A2197DE2036A
Content-Type: text/plain; charset=iso-8859-1


Reproducible: Always

Steps to Reproduce:
1. Receive a message with "Content-type:" declared before the "To:" and "From:"
fields.
2. 
3.

Actual Results:  
Message displayed is source (less header).

Expected Results:  
Mozilla could have compensated for the misplaced(?) "Content-type" information
to display the message normally to handle "bad" mail better.

Or, perhaps it's Paypal's problem, not sure.

Comment 1

[Gervase Markham [:gerv]]

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/

Comment 2

[Cecelia S]

I just checked the message again. It's still displaying incorrectly in
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b) Gecko/20050217

Comment 3

[Mike Cowperthwaite]

Reporter, since you still have the message, it would be more useful if you 
could save it as a .EML file and attach it to this bug (or, if you're 
concerned about privacy, forward it to me as an attachment).

The Content-Type line shown is definitely incorrect, given the part of the 
mail you've shown; it should be something like:
  Content-Type: multipart/alternative  (or multipart/related)
but having the following headers displayed in the message is not the expected behavior.

Comment 4

[Cecelia S]

Attachment: Email

Here's the entire email (although I did edit out some of the more sensetive information (replaced by asterisks).

Comment 5

[Mike Cowperthwaite]

OK: When I open that message, I see:
=================
This is multi-part message in MIME format.

--NextPart_048F8BC8A2197DE2036A
Content-Type: text/plain; charset=iso-8859-1

Dear Cecelia Sullivan,
[....]
=================
This is what I'd expect to see when the Content-Type:text/plain -- and, in 
fact, it's pretty much what you *said* you saw.

I notice, now, that there is a second Content-Type header for the message.  
The first Content-Type is not correct for the message, the second one is.
Messages aren't supposed to have more than one Content-Type, so there are no rules for picking between the two; Mozilla & TB, it seems, use the first one encountered and ignore any subsequent ones.

If you're getting frequent messages from PayPal that exhibit this problem, you should contact them and tell them to fix the problem on their side.

Comment 6

[Cecelia S]

Attachment: New Email

When we look at this email, we see that they've now removed the content type info that was before the envelope information:

Date: Fri, 09 Dec 2005 07:41:00 -0800
Message-Id: <[e-mail]>
Subject: Receipt for Your Payment
X-MaxCode-Template: email-receipt-auction-payment
To: Cecelia Sullivan <[e-mail]>
From: "[e-mail]" <[e-mail]>
X-Email-Type-Id: PP843
X-XPT-XSL-Name: /default/en_US/auction/ReceiptAuctionPayment.xsl
Content-Type: multipart/alternative;
  boundary=--NextPart_048F8BC8A2197DE2036A
MIME-Version: 1.0

----NextPart_048F8BC8A2197DE2036A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=windows-1252

This email works correctly and I can actually switch back and forth between plain text and HTML views. I see what you meen, Mike. So does it not matter where the content type declaration is, as long as there's only one in an email header?

Comment 7

[WADA:World Anti-bad-Duping Agency]

Changing summary(saying "duplicated Content-Type", i.e. malformed, clearly) based on analysis of Comment #5 by Mike.

Comment 8

[WADA:World Anti-bad-Duping Agency]

Which is this bug's problem and targeted solution?
 (1) Thunderbird rendering of a malformed mail is different from expectation of
     the malformed mail sender.
     Tb has to display it as mail sender wants(have to guess) when malformed.
 (2) Thunderbird rendering of a malformed mail is different from our usual
     expectation derived from RFC's description.
     Tb has to be more torelent for malformed mail.
     (Request of ignoring feature of duplicated Content-Type., and so on.) 
 (3) Thunderbird rendering of a malformed mail is different from our usual
     expectation derived from RFC's description.
     Tb's display is incorrect, then should be corrected, or better to
     be corrected.
 (4) A mail sender sent malformed mail.
     Mail sender should correct the error. (Tech Evang like bug.)

If (2) or (3), I can DUP Bug 325867 to this bug.

Comment 9

[(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 10

[Wayne Mery (:wsmwk)]

confirming to get on radar

Comment 11

[Magnus Melin [:mkmelin] (away until Aug 10)]

I doubt there is a "good" fix for this. Of course in this particular case it would have worked to look at the second Content-type header, but in other cases the first one would be the correct one. We'd just be guessing...

Comment 12

[Max Emig [:maxe]]

Apple Mail also trips on this, it is one of those bugs I strongly consider won't fixing because it involves far too much guesswork on a clearly broken message.

Comment 13

[Max Emig [:maxe]]

No reaction from the bug reporter, and no one else in CC apart from Thunderbird contributors.

mail_parser can parse it, but again it is absolutely not worth it to implement a whole new brute-force heuristic for this.