Closed Bug 805620 Opened 12 years ago Closed 11 years ago

Content-Transfer-Encoding and Content-Disposition parameters should be case-insensitive, per RFC 2045

Categories

(MailNews Core :: MIME, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 21.0

People

(Reporter: chip.programmer, Assigned: hiro)

References

()

Details

Attachments

(2 files)

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.
Component: Untriaged → MIME
Product: Thunderbird → MailNews Core
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"
(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"?
(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"?
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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...
Summary: MIME header parsing is not compliant with RFC 2045 → MIME header parsing is not compliant with RFC 2045 (Even after fix of bug 580017, unable to open eml attachment, if Content-Transfer-Encoding:BASE64 is specified instead of base64 for base64 encoded application/octet-stream part with .eml file extention)
Summary: MIME header parsing is not compliant with RFC 2045 (Even after fix of bug 580017, unable to open eml attachment, if Content-Transfer-Encoding:BASE64 is specified instead of base64 for base64 encoded application/octet-stream part with .eml file extention) → MIME header parsing is not compliant with RFC 2045 (Even after fix of bug 580017, unable to open eml attachment, if Content-Transfer-Encoding:BASE64 is specified instead of base64 for base64 encoded application/octet-stream part with .eml file extension)
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
Attached patch FixSplinter Review
Mike Koleszar, Thanks for emailing me to notice this.
Assignee: nobody → hiikezoe
Attachment #685887 - Flags: review?(mbanner)
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.
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.
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--
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.
Summary: MIME header parsing is not compliant with RFC 2045 (Even after fix of bug 580017, unable to open eml attachment, if Content-Transfer-Encoding:BASE64 is specified instead of base64 for base64 encoded application/octet-stream part with .eml file extension) → Content-Transfer-Encoding and Content-Disposition parameters should be case-insensitive, per RFC 2045
Comment on attachment 685887 [details] [diff] [review]
Fix

Looks good, thanks.
Attachment #685887 - Flags: review?(mbanner) → review+
OS: Windows 7 → All
Hardware: x86_64 → All
No checking needed ?
Status: NEW → UNCONFIRMED
Ever confirmed: false
Keywords: checkin-needed
OS: All → Windows 7
Hardware: All → x86_64
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86_64 → All
https://hg.mozilla.org/comm-central/rev/a0f0716fcd30
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 21.0
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: