Last Comment Bug 805620 - Content-Transfer-Encoding and Content-Disposition parameters should be case-insensitive, per RFC 2045
: Content-Transfer-Encoding and Content-Disposition parameters should be case-i...
Status: RESOLVED FIXED
:
Product: MailNews Core
Classification: Components
Component: MIME (show other bugs)
: 16
: All All
: -- normal (vote)
: Thunderbird 21.0
Assigned To: Hiroyuki Ikezoe (:hiro)
:
Mentors:
http://forums.mozillazine.org/viewtop...
Depends on:
Blocks: 580017
  Show dependency treegraph
 
Reported: 2012-10-25 14:30 PDT by Chip
Modified: 2013-01-12 11:53 PST (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
test mail folder file, 4 cases : base64,attachment / base64,ATTACHMET, / BASE64,attachment / BASE64,ATTACMENT (5.05 KB, text/plain)
2012-11-22 02:21 PST, WADA
no flags Details
Fix (1.30 KB, patch)
2012-11-27 16:38 PST, Hiroyuki Ikezoe (:hiro)
standard8: review+
Details | Diff | Splinter Review

Description Chip 2012-10-25 14:30:56 PDT
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121011 Firefox/16.0 SeaMonkey/2.13.1
Build ID: 20121011080919

Steps to reproduce:

A public domain email program (http://www.blat.net/) sent an email to a client, who tried to read the incoming email with Thunderbird version 16.0.  Unfortunately, Thunderbird was unable to render the attachment.  The incoming message had "Content-Transfer-Encoding: BASE64".


Actual results:

Due to the uppercase BASE64, Thunderbird refused to handle the attachment.


Expected results:

To be compliant with RFC 2045, Thunderbird should have accepted an uppercase BASE64 the same as if it were lowercase base64.  The culprit appears to be in mailnews/mine/src/mimei.cpp, line 875.  This line should read:

if (encoding.LowerCaseEqualsLiteral(ENCODING_BASE64))

This error exists in version 17.0b1, mailnews/mine/src/mimei.cpp, line 885.
Comment 1 Mike Koleszar 2012-11-21 08:59:55 PST
For testing purposes, if a .eml file is sent as an attachment, blat will use base64 to encode it. This error exists in Thunderbird 17.0

--=_BlatBoundary-byWAMXG7xnJ7sgl1Ou9Dj
Content-Type: application/octet-stream;
 name="test.eml"
Content-Transfer-Encoding: BASE64
Content-Disposition: ATTACHMENT;
 filename="test.eml"
Comment 2 WADA 2012-11-21 23:54:41 PST
(In reply to Mike Koleszar from comment #1)
> --=_BlatBoundary-byWAMXG7xnJ7sgl1Ou9Dj
> Content-Type: application/octet-stream; name="test.eml"
> Content-Transfer-Encoding: BASE64
> Content-Disposition: ATTACHMENT; filename="test.eml"

Mike Koleszar, are you talking about same problem as bug 580017?
(note: bug 580017 is fixed in Tb 13)
According to following in comment #0 by bug opener, 
> Actual results:
> Due to the uppercase BASE64, Thunderbird refused to handle the attachment.
this bug sounds phenomenon like next.
  If base64, no problem, but if BAE64, problem does occur.
Does your adding the comment to this bug mean "no problem occurs if base64, but problem occurs if BASE64"?
Comment 3 WADA 2012-11-22 00:18:11 PST
(In reply to Chip from comment #0)
> The incoming message had "Content-Transfer-Encoding: BASE64".

How about Conten-Type: header and Content-Disposition: header?
Conten-Type: message/rfc822? application/octet-stream? or other?
Content-Disposition: attachment? inline? or other?

> Actual results:
> Due to the uppercase BASE64, Thunderbird refused to handle the attachment.

Bug opener, does it mean "no problem occurs if base64, but problem occurs if BASE64"?
Comment 4 WADA 2012-11-22 02:21:58 PST
Created attachment 684356 [details]
test mail folder file, 4 cases : base64,attachment / base64,ATTACHMET, / BASE64,attachment / BASE64,ATTACMENT

Test mails:
Following-Content-Type header is common.
> Content-Type: application-octet-stream, name="...eml"
Test cases]
> Case-1 : Content-Transfer-Encoding: base64, Content-Disposition: attachment,filename="...eml"
> Case-2 : Content-Transfer-Encoding: base64, Content-Disposition: ATTACHMENT,filename="...eml"
> Case-3 : Content-Transfer-Encoding: BASE64, Content-Disposition: attachment,filename="...eml"
> Case-4 : Content-Transfer-Encoding: BASE64, Content-Disposition: ATTACHMENT,filename="...eml"

Problem was observed in Case-3/Case-4 with Tb 17.0 on Win-XP.
i.e. attachment/ATACHMENT is irrelevant. base64/BASE64 only is relevant.
Following alert was shown when "Open" of the eml attachment was requested.
> Alert
> ! This attachment appears to be empty.
> Please check with the person who sent this.
> Often company firewalls or antivirus programs will destroy attachments

Confirming.
Comment 5 WADA 2012-11-22 02:49:51 PST
Note-1:
No problem in Case-1/Case-2. i.e. bug 580017 was actually fixed.
Note-2:
If name="...TXT"(Content-Type)/filename="...TXT"(Content-Disposition) is used for base64 encoded application/octet-stream part, problem didn't occur even with uppercase BASE64 & uppercase ATTACHMENT.
Note-3:
Same alert was still observed if base64 encoded message/rfc822 part with file extension of ".eml".
In this case, base64 or BASE64 looked irrelevant. Despite lower case base64, alert was shown.

MIME interpretation of Tb seems pretty complicated...
Comment 6 Mike Koleszar 2012-11-27 15:28:09 PST
Hi WADA, thank you very much for looking into this bug. I have just tested this and get the same results that you got. When "base64" is used, the ".eml" attachment opens normally. When "BASE64" is used, Thunderbird reports the attachment as being "empty", and will not open it. This happens in Thunderbird 17.0.

- Mike
Comment 7 Hiroyuki Ikezoe (:hiro) 2012-11-27 16:38:16 PST
Created attachment 685887 [details] [diff] [review]
Fix

Mike Koleszar, Thanks for emailing me to notice this.
Comment 8 WADA 2012-11-27 18:47:21 PST
FYI.
Note-3 in my comment #5 is Bug 333880 what is for following case.
> Content-Type: message/rfc822; name="ATT1.eml"
> Content-Transfer-Encoding: base64
> Entire mail data stream is base64 encoded correctly, but it's RFC2045 violation.
> Not broken mail data stream by Tb due to Bug 326303.
Comment 9 Chip 2012-11-27 23:58:56 PST
Although the attachment is in violation of RFC 2045, it is also true that Thunderbird is in violation of the same RFC, due to the CASE SENSITIVE nature of the function EqualsLiteral().  Changing the identified line of source to use LowerCaseEqualsLiteral() instead, will make Thunderbird compliant with the RFC's requirement of being case insensitive.
Comment 10 Chip 2012-11-28 23:07:12 PST
Sample test_out1.eml file that fails to open all five (5) attachments in Thunderbird.  The third attachment does not open, Thunderbird claims it to be empty.

Date: Wed, 28 Nov 2012 23:58:39 -0700
From: Chip <someone@localhost>
To: Chip <someone@localhost>
X-Mailer: Blat v3.1.0, a Win64 (AMD64) SMTP/NNTP mailer http://www.blat.net
Message-ID: <01cdcdfe$Blat.v3.1.0$f62ee2fa$17f8481d@127.0.0.1>
Subject: Test subj
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="=_BlatBoundary-Rd6KFri5kEh2XZ7nWEsEa"

This is a multi-part message in MIME format.

--=_BlatBoundary-Rd6KFri5kEh2XZ7nWEsEa
Content-Description: Mail message body
Content-Transfer-Encoding: 7BIT
Content-Type: text/plain;
 charset="ISO-8859-1";
 reply-type=original

My test body

--=_BlatBoundary-Rd6KFri5kEh2XZ7nWEsEa
Content-Type: message/rfc822;
 name="test.eml";
 charset="ISO-8859-1";
 reply-type=original
Content-Transfer-Encoding: 7BIT
Content-Disposition: ATTACHMENT;
 filename="test.eml"
Content-Description: "test.eml"

Received: from jeanamd64 (x.cableone.net[1.2.3.4])
          by worldnet.att.net (frfwmhc01) with SMTP
          id <20091207183731H010014qrte>; Mon, 7 Dec 2009 18:37:31 +0000
X-Originating-IP: [1.2.3.4]
Message-ID: <36404BE0462C481C9FF21335047B4C5D@JeanAMD64>
From: "Jean" <someone@localhost>
To: "daughter" <someone@localhost>
Cc: "Chip" <someone@localhost>
Subject: Chip's home email address
Date: Mon, 7 Dec 2009 11:37:31 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579

For family --   someone @ localhost
Public --- someone @ localhost

--=_BlatBoundary-Rd6KFri5kEh2XZ7nWEsEa
Content-Type: text/plain;
 name="test1.eml"
Content-Transfer-Encoding: BASE64
Content-Disposition: ATTACHMENT;
 filename="test1.eml"

UmVjZWl2ZWQ6IGZyb20gamVhbmFtZDY0ICh4LmNhYmxlb25lLm5ldFsxLjIuMy40XSkNCiAg
ICAgICAgICBieSB3b3JsZG5ldC5hdHQubmV0IChmcmZ3bWhjMDEpIHdpdGggU01UUA0KICAg
ICAgICAgIGlkIDwyMDA5MTIwNzE4MzczMUgwMTAwMTRxcnRlPjsgTW9uLCA3IERlYyAyMDA5
IDE4OjM3OjMxICswMDAwDQpYLU9yaWdpbmF0aW5nLUlQOiBbMS4yLjMuNF0NCk1lc3NhZ2Ut
SUQ6IDwzNjQwNEJFMDQ2MkM0ODFDOUZGMjEzMzUwNDdCNEM1REBKZWFuQU1ENjQ+DQpGcm9t
OiAiSmVhbiIgPHNvbWVvbmVAbG9jYWxob3N0Pg0KVG86ICJkYXVnaHRlciIgPHNvbWVvbmVA
bG9jYWxob3N0Pg0KQ2M6ICJDaGlwIiA8c29tZW9uZUBsb2NhbGhvc3Q+DQpTdWJqZWN0OiBD
aGlwJ3MgaG9tZSBlbWFpbCBhZGRyZXNzDQpEYXRlOiBNb24sIDcgRGVjIDIwMDkgMTE6Mzc6
MzEgLTA3MDANCk1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47
DQoJZm9ybWF0PWZsb3dlZDsNCgljaGFyc2V0PSJpc28tODg1OS0xIjsNCglyZXBseS10eXBl
PW9yaWdpbmFsDQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA3Yml0DQpYLVByaW9yaXR5
OiAzDQpYLU1TTWFpbC1Qcmlvcml0eTogTm9ybWFsDQpYLU1haWxlcjogTWljcm9zb2Z0IE91
dGxvb2sgRXhwcmVzcyA2LjAwLjI5MDAuNTg0Mw0KWC1NaW1lT0xFOiBQcm9kdWNlZCBCeSBN
aWNyb3NvZnQgTWltZU9MRSBWNi4wMC4yOTAwLjU1NzkNCg0KRm9yIGZhbWlseSAtLSAgIHNv
bWVvbmUgQCBsb2NhbGhvc3QNClB1YmxpYyAtLS0gc29tZW9uZSBAIGxvY2FsaG9zdA==

--=_BlatBoundary-Rd6KFri5kEh2XZ7nWEsEa
Content-Type: application/octet-stream;
 name="test2.eml"
Content-Transfer-Encoding: BASE64
Content-Disposition: ATTACHMENT;
 filename="test2.eml"

UmVjZWl2ZWQ6IGZyb20gamVhbmFtZDY0ICh4LmNhYmxlb25lLm5ldFsxLjIuMy40XSkNCiAg
ICAgICAgICBieSB3b3JsZG5ldC5hdHQubmV0IChmcmZ3bWhjMDEpIHdpdGggU01UUA0KICAg
ICAgICAgIGlkIDwyMDA5MTIwNzE4MzczMUgwMTAwMTRxcnRlPjsgTW9uLCA3IERlYyAyMDA5
IDE4OjM3OjMxICswMDAwDQpYLU9yaWdpbmF0aW5nLUlQOiBbMS4yLjMuNF0NCk1lc3NhZ2Ut
SUQ6IDwzNjQwNEJFMDQ2MkM0ODFDOUZGMjEzMzUwNDdCNEM1REBKZWFuQU1ENjQ+DQpGcm9t
OiAiSmVhbiIgPHNvbWVvbmVAbG9jYWxob3N0Pg0KVG86ICJkYXVnaHRlciIgPHNvbWVvbmVA
bG9jYWxob3N0Pg0KQ2M6ICJDaGlwIiA8c29tZW9uZUBsb2NhbGhvc3Q+DQpTdWJqZWN0OiBD
aGlwJ3MgaG9tZSBlbWFpbCBhZGRyZXNzDQpEYXRlOiBNb24sIDcgRGVjIDIwMDkgMTE6Mzc6
MzEgLTA3MDANCk1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47
DQoJZm9ybWF0PWZsb3dlZDsNCgljaGFyc2V0PSJpc28tODg1OS0xIjsNCglyZXBseS10eXBl
PW9yaWdpbmFsDQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA3Yml0DQpYLVByaW9yaXR5
OiAzDQpYLU1TTWFpbC1Qcmlvcml0eTogTm9ybWFsDQpYLU1haWxlcjogTWljcm9zb2Z0IE91
dGxvb2sgRXhwcmVzcyA2LjAwLjI5MDAuNTg0Mw0KWC1NaW1lT0xFOiBQcm9kdWNlZCBCeSBN
aWNyb3NvZnQgTWltZU9MRSBWNi4wMC4yOTAwLjU1NzkNCg0KRm9yIGZhbWlseSAtLSAgIHNv
bWVvbmUgQCBsb2NhbGhvc3QNClB1YmxpYyAtLS0gc29tZW9uZSBAIGxvY2FsaG9zdA==

--=_BlatBoundary-Rd6KFri5kEh2XZ7nWEsEa
Content-Type: text/plain;
 name="test1.txt"
Content-Transfer-Encoding: BASE64
Content-Disposition: ATTACHMENT;
 filename="test1.txt"

UmVjZWl2ZWQ6IGZyb20gamVhbmFtZDY0ICh4LmNhYmxlb25lLm5ldFsxLjIuMy40XSkNCiAg
ICAgICAgICBieSB3b3JsZG5ldC5hdHQubmV0IChmcmZ3bWhjMDEpIHdpdGggU01UUA0KICAg
ICAgICAgIGlkIDwyMDA5MTIwNzE4MzczMUgwMTAwMTRxcnRlPjsgTW9uLCA3IERlYyAyMDA5
IDE4OjM3OjMxICswMDAwDQpYLU9yaWdpbmF0aW5nLUlQOiBbMS4yLjMuNF0NCk1lc3NhZ2Ut
SUQ6IDwzNjQwNEJFMDQ2MkM0ODFDOUZGMjEzMzUwNDdCNEM1REBKZWFuQU1ENjQ+DQpGcm9t
OiAiSmVhbiIgPHNvbWVvbmVAbG9jYWxob3N0Pg0KVG86ICJkYXVnaHRlciIgPHNvbWVvbmVA
bG9jYWxob3N0Pg0KQ2M6ICJDaGlwIiA8c29tZW9uZUBsb2NhbGhvc3Q+DQpTdWJqZWN0OiBD
aGlwJ3MgaG9tZSBlbWFpbCBhZGRyZXNzDQpEYXRlOiBNb24sIDcgRGVjIDIwMDkgMTE6Mzc6
MzEgLTA3MDANCk1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47
DQoJZm9ybWF0PWZsb3dlZDsNCgljaGFyc2V0PSJpc28tODg1OS0xIjsNCglyZXBseS10eXBl
PW9yaWdpbmFsDQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA3Yml0DQpYLVByaW9yaXR5
OiAzDQpYLU1TTWFpbC1Qcmlvcml0eTogTm9ybWFsDQpYLU1haWxlcjogTWljcm9zb2Z0IE91
dGxvb2sgRXhwcmVzcyA2LjAwLjI5MDAuNTg0Mw0KWC1NaW1lT0xFOiBQcm9kdWNlZCBCeSBN
aWNyb3NvZnQgTWltZU9MRSBWNi4wMC4yOTAwLjU1NzkNCg0KRm9yIGZhbWlseSAtLSAgIHNv
bWVvbmUgQCBsb2NhbGhvc3QNClB1YmxpYyAtLS0gc29tZW9uZSBAIGxvY2FsaG9zdA==

--=_BlatBoundary-Rd6KFri5kEh2XZ7nWEsEa
Content-Type: application/octet-stream;
 name="test2.txt"
Content-Transfer-Encoding: BASE64
Content-Disposition: ATTACHMENT;
 filename="test1.txt"

UmVjZWl2ZWQ6IGZyb20gamVhbmFtZDY0ICh4LmNhYmxlb25lLm5ldFsxLjIuMy40XSkNCiAg
ICAgICAgICBieSB3b3JsZG5ldC5hdHQubmV0IChmcmZ3bWhjMDEpIHdpdGggU01UUA0KICAg
ICAgICAgIGlkIDwyMDA5MTIwNzE4MzczMUgwMTAwMTRxcnRlPjsgTW9uLCA3IERlYyAyMDA5
IDE4OjM3OjMxICswMDAwDQpYLU9yaWdpbmF0aW5nLUlQOiBbMS4yLjMuNF0NCk1lc3NhZ2Ut
SUQ6IDwzNjQwNEJFMDQ2MkM0ODFDOUZGMjEzMzUwNDdCNEM1REBKZWFuQU1ENjQ+DQpGcm9t
OiAiSmVhbiIgPHNvbWVvbmVAbG9jYWxob3N0Pg0KVG86ICJkYXVnaHRlciIgPHNvbWVvbmVA
bG9jYWxob3N0Pg0KQ2M6ICJDaGlwIiA8c29tZW9uZUBsb2NhbGhvc3Q+DQpTdWJqZWN0OiBD
aGlwJ3MgaG9tZSBlbWFpbCBhZGRyZXNzDQpEYXRlOiBNb24sIDcgRGVjIDIwMDkgMTE6Mzc6
MzEgLTA3MDANCk1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47
DQoJZm9ybWF0PWZsb3dlZDsNCgljaGFyc2V0PSJpc28tODg1OS0xIjsNCglyZXBseS10eXBl
PW9yaWdpbmFsDQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA3Yml0DQpYLVByaW9yaXR5
OiAzDQpYLU1TTWFpbC1Qcmlvcml0eTogTm9ybWFsDQpYLU1haWxlcjogTWljcm9zb2Z0IE91
dGxvb2sgRXhwcmVzcyA2LjAwLjI5MDAuNTg0Mw0KWC1NaW1lT0xFOiBQcm9kdWNlZCBCeSBN
aWNyb3NvZnQgTWltZU9MRSBWNi4wMC4yOTAwLjU1NzkNCg0KRm9yIGZhbWlseSAtLSAgIHNv
bWVvbmUgQCBsb2NhbGhvc3QNClB1YmxpYyAtLS0gc29tZW9uZSBAIGxvY2FsaG9zdA==

--=_BlatBoundary-Rd6KFri5kEh2XZ7nWEsEa--
Comment 11 Chip 2012-11-28 23:15:34 PST
RFC 2045 says that if the Content-Type is "message/rfc822", then the body of the attachment must be textual.  RFC 2045 makes no claims about an attached filename's extension.  Thunderbird should be able to save any/all attachments that have actual bytes, as noted by all five attachments in the previous comment.  However, Thunderbird does not.  It mistakenly assigned "message/rfc822" to "text2.eml" due to the .eml extension, then claims that base64 encoding for "application/octet-stream" violates RFC 2045 due to "message/rfc822" assignment to the ".eml" extension.  The "application/octet-stream" _must_ take precedence, because the filename extension can be totally arbitrary, and the file should then be saved in binary format, not text format; it is, after all, an arbitrary stream of octets that happens to resemble ASCII text.
Comment 12 Mark Banner (:standard8) 2012-12-20 11:57:17 PST
Comment on attachment 685887 [details] [diff] [review]
Fix

Looks good, thanks.
Comment 13 Ludovic Hirlimann [:Usul] 2012-12-31 04:05:05 PST
No checking needed ?
Comment 14 Ryan VanderMeulen [:RyanVM] 2013-01-12 11:53:21 PST
https://hg.mozilla.org/comm-central/rev/a0f0716fcd30

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