Closed Bug 543813 Opened 14 years ago Closed 14 years ago

Attachments with "Content-Type:" line containing a line break are not processed properly

Categories

(MailNews Core :: MIME, defect)

Product:
MailNews Core
Component:
MIME
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(thunderbird3.1 rc1-fixed)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 3.1rc1
Tracking Flags:
Tracking Status
thunderbird3.1 --- rc1-fixed

People

(Reporter: vmikhelson, Assigned: Parasyte)

References

(
URL
)

Details

Attachments

(1 file, 1 obsolete file)

Patch v2
5.21 KB, patch
asuth
: review+
Bienvenu
: superreview+
Bienvenu
: approval-thunderbird3.1+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1

If a message has an attachment with "Content-Type:" line broken into two like in the following example:

Content-Type:
	 application/vnd.openxmlformats-officedocument.spreadsheetml.sheet

it is processed incorrectly.

1. If "View / Display Attachments Inline" is checked the attachment shows up in the message pane as a raw MIME;

2. The attachment is passed on double-click to a registered application as a raw MIME, i.e. not decoded.

Right-click / Save-As works as expected, i.e. the file is saved in its original format and can be opened by an application. That can be used as a workaround.

Reproducible: Always

Steps to Reproduce:
1. Make sure "View / Display Attachments Inline" is checked
2. Go to a message pane
3. Observe the raw MIME displayed
4. Double click the attachment name
5. Observe the registered application being called but the file passed is not decoded



Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111
Thunderbird/3.0.1

Here is a sample of an offending message.


Message pane contents:
======================

Attached is a spread sheet....

--List.xlsx --------------------------------------------------------------------

--------------------------------------------------------------------------------
PKßMRP©hZ.±âÄ3³;³Ž·e‘l ¢õ.ƒ´/pÚë–™xŸ½ôîE‚¤œQ…w‰
®¯†³]SÀñ—…¥"~K”^©%ÈÛ~ÿNjïõ¨Â£á,Ôº äyËÛ’¹u"ylþ«¨2¡B(¬VÄBåÆ™$=¿XX
ÆëuÉÐ)†Ê`@e‘†h™1NˆC!GÃ7.:ZÉDEzU%3Èm!‰+€æ9H¹†N"j°›
åwB¤]Ø™ê¸ÞôfRsf–õÒ½Öc5èžÿ„½
<¯µ_JùdÌmÀ†vïÚ=ùðq5÷~uiWª4¦¥²n¯ûT9“èJ|gPM”Ó



Message body:
=============

Mime-Version: 1.0
X-Mailer: GroupWise 8.0
Subject: List
Date: Tue, 19 Jan 2010 14:37:12 -0600
Message-ID: <4B55C398020000490000CDE9@xxx.com>
From: "X Y Z" <aaa@xxxx.com>
To: "V M" <bbb@xxx.com>
Content-Type: multipart/mixed; boundary="____WCRAQBYZYWOYSIACEIHF____"


--____WCRAQBYZYWOYSIACEIHF____
Content-Type: multipart/alternative; boundary="____SRDVHGLOLYVOWLRNXGUW____"


--____SRDVHGLOLYVOWLRNXGUW____
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Attached is a spread sheet....


--____SRDVHGLOLYVOWLRNXGUW____
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD>
<META content=3D"text/html; charset=3Dutf-8" http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18854"></HEAD>
<BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>&nbsp;</DIV>
<DIV>Attached is a spread sheet....</DIV>

<DIV>&nbsp;</DIV>
<DIV>Mike</DIV></BODY></HTML>
--____SRDVHGLOLYVOWLRNXGUW____--

--____WCRAQBYZYWOYSIACEIHF____
Content-Type:
     application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="List.xlsx"

UEsDBBQABgAIAAAAIQC1ensdkAEAAAEGAAATANIBW0NvbnRlbnRfVHlwZXNdLnhtbCCizgEooAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

..............................................

ABMAAAAAAAAAAAAAAAAA3UYAAGRvY1Byb3BzL2N1c3RvbS54bWxQSwUGAAAAAA4ADgCpAwAAFUkA
AAAA
--____WCRAQBYZYWOYSIACEIHF____--
Let me add to and correct the original report.

It does not display or pass raw MIME. The MIME is decoded but incorrectly.

This is how the head of the saved file looks in FAR (ASCII mode):



PK♥♦¶ ♠ ◘   ! µz{↔_☺  ☺♠  ‼ O☺[Content_Types].xml ¢I☺(  ☻





                                   ¬TEnA0►¼Wê?D_VÄDCUU♦♫}∟[$è•↑{!■%my↨
⌂ßMRPchZ¶.±âÄ33;3▲Z·e`l ¢o.‼ƒ'/↕pU←ë-TxY½ôîE,☼oQ.w_%↔ ↑_r_+3] Lo'ALäDáAJO9"
S▼Añ-._¥"~_K↓"^c%EU~ÿNjï◘∟o"A►£á‼,Oº äyEU_'1u"yl_«"2¡B(¬VÄBåÆT▼$=¿XX♪ÆëuÉD)+◘E`♫
@e`+hT1N_^♂C!GA7.:Z♥ÉDEzU%3Em!%+_æ9H1+N"j°>
åwB☼]☺OTê,_♠ô☼fRsf-oO½Öc☺5èzÿ,½◄
<_µ_☺Jùd_☺ImA■+vïU=ùdq5÷~uiWª4▌¥²n_ûT◘9A"è♥J♫|g☺PM"☺O♂♀ `,∟zÖE-xH_ìLßAü"o§_j|=3(
ëåO±<à·↓A:0W◄I"oUX^|6¿c·é8♦Aû◘ç[±▼~êô   •d}__>☺  ÿÿ♥ PK♥♦¶ ♠ ◘   ! ‼^_e♣☺  ß☻  ♂
 _☺_rels/.rels ¢º☺(  ☻
Confirmed on trunk with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100201 Shredder/3.2a1pre, SeaMonkey and Linux too,
thus moving to MailNews Core for all platforms.

I've taken a message sent from Thunderbird and simply edited the mbox content
by splitting the line after the Content-Type: header, moving the argument into the next line. This prompted the apparent text/plain default taken. It is not clear to me if this case is covered as acceptable white-space folding in the sense of RFC 5322, and RFC 2045 doesn't seem to have any information either, thus assuming that this is a case that "should" be covered for robustness.
URL: http://tools.ietf.org/html/rfc5322#se...
Status: UNCONFIRMED → NEW
Component: Message Reader UI → MIME
Ever confirmed: true
OS: Windows XP → All
Product: Thunderbird → MailNews Core
QA Contact: message-reader → mime
Hardware: x86 → All
Version: unspecified → Trunk
Just checking to see if there is any life here.

-Vladimir
One of our employees ran into this bug.  I'm not sure what the sending client was (possibly Outlook or Lotus-something-or-other) but the email contained a multi-part MIME with the following Content-Type header:

Content-Type: 
 application/vnd.openxmlformats-officedocument.presentationml.presentation;
 name="NWRM_April_2010_Tariq.pptx"

This long MIME type is specified by Microsoft[1], and the header itself appears to be valid according to RFC 5322; specifically section 2.2, quoting:

   ... A field body MUST NOT include CR and LF except
   when used in "folding" and "unfolding", as described in section
   2.2.3.

And section 2.2.3 defines this behavior (Note the whitespace following the line breaks; see also Comment #0).


This bug appears to be caused by [2].  MimeHeaders_get() does not follow the RFC in this case; parsing is terminated at the first line break following the colon (when strip_p is true).

I'm trying to work on a patch for this.  I want to cover different styles of line breaks, like MimeHeaders_build_heads_list() does[3].  It's probably not necessary, but seems like the Right Thing To Do.


[1] http://technet.microsoft.com/en-us/library/cc179224.aspx
[2] http://mxr.mozilla.org/comm-1.9.1/source/mailnews/mime/src/mimehdrs.cpp#402
[3] http://mxr.mozilla.org/comm-1.9.1/source/mailnews/mime/src/mimehdrs.cpp#291
Attached patch Patch v1 (obsolete) — — Splinter Review 
I would like wanted-1.9.1 on this, but can't seem to mark wanted?  David or Andrew, do you think this could make the cut?
Attachment #443669 - Flags: review?(bugmail)
Attachment #443669 - Flags: review?(bienvenu)
This really should have a unit test.  Do you need direction on where to add the test or have you found good testing spots in your investigation?
I would like some help with that, if you don't mind.  I'm available on IRC (Parasyte) during after-hours, or you can reach me by email any time if that's a better place to discuss testing.

This bug is pretty important for our organization (and I imagine for many corporate settings that need compatibility with Outlook).  I'm interested in pushing forward with this one ASAP.
Righto, so it looks like you want to to create an instance of nsIMimeHeaders, cram in your string data, and then call extractHeader on it and verify it pulls out the whole thing.

nsIMimeHeaders:
http://mxr.mozilla.org/comm-central/source/mailnews/mime/public/nsIMimeHeaders.idl#54

An example that basically already does what you want:
http://mxr.mozilla.org/comm-central/source/mailnews/extensions/mdn/test/unit/test_askuser.js#19

But you want to put it in this directory and perhaps slightly follow the lead of the other files there when it comes to boilerplate:
http://mxr.mozilla.org/comm-central/source/mailnews/mime/test/unit/
Attached patch Patch v2 — — Splinter Review 
Thanks for the info!  This one includes a test.

The test fails without the patch (YAY!) because the second header parsed will return a content type like: "\r\n\tapplication/..."  Which isn't expected.  :(

With the patch, we get the expected "application/..."  :)

Some other cases are also tested, including actual empty content type fields.
Attachment #443669 - Attachment is obsolete: true
Attachment #443897 - Flags: review?(bugmail)
Attachment #443669 - Flags: review?(bugmail)
Attachment #443669 - Flags: review?(bienvenu)
Comment on attachment 443897 [details] [diff] [review]
Patch v2

This looks good to me and tests pass (woo! thanks for the tests!)

I think this would be desirable to get for 3.1 and not particularly risky, unless bienvenu thinks otherwise...
Attachment #443897 - Flags: superreview?(bienvenu)
Attachment #443897 - Flags: review?(bugmail)
Attachment #443897 - Flags: review+
Assignee: nobody → parasyte
Status: NEW → ASSIGNED
Comment on attachment 443897 [details] [diff] [review]
Patch v2

break should go on its own line here:

+       */
+      else break;

but yeah, this does seem like it would be good to have, thx for the patch.
Attachment #443897 - Flags: superreview?(bienvenu) → superreview+
Attachment #443897 - Flags: approval-thunderbird3.1+
Thanks Everybody!

Probably obvious, but important to note the patch will affect the parsing of all headers (not just Content-Type).  It seems like Content-Type is the one that will hit the bug most often.
(I'm going to make the bienvenu requested change and land this)
pushed to comm-1.9.2:
http://hg.mozilla.org/releases/comm-1.9.2/rev/dc4825de95af

pushed to comm-central:
http://hg.mozilla.org/comm-central/rev/f0b8896052d9
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
status-thunderbird3.1: --- → rc1-fixed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.1rc1
Blocks: 574961
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: