If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

With missing content-type, the default value "text/plain" doesn't work with "Content-Transfer-Encoding: base64"

RESOLVED DUPLICATE of bug 230377

Status

Thunderbird
General
RESOLVED DUPLICATE of bug 230377
12 years ago
12 years ago

People

(Reporter: intendentedelleacque, Assigned: Scott MacGregor)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; it; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; it; rv:1.8) Gecko/20051111 Firefox/1.5

If you receive or open a mail like this one:


From - Tue Jan 03 13:13:58 2006
Date: Thu, 15 Dec 2005 14:00:07 +0100 (CET)
From: email@provider.com.com
Message-Id: <200512151300.jBFD07fU008343@xxx.xxx.com>
To: recipients@provider.net
Subject: Test mail encoded in base64
Return-Path: me@myhouse.com
Content-Transfer-Encoding: base64

VGhpcyBpcyBhIHRlc3QgZW1haWwsIHdpdGggYSB0ZXh0IGVuY29kZWQgaW4gYmFzZTY0==


and open it on Thunderbird, you will see the text not decoded in plain text.
On the contrary, if you add the line

Content-type: text/plain 

to the headers, you can see the text decoded in plain text.
This doesn't seem correct: infact according to the rfc2045, point 5.2, 

"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. "

So the header "Content-type: text/plain" shouldn't be necessary to see decoded a text encoded in base64 in the mail above.
This is the behaviour of TB 1.0.7 , but also of TB 1.5rc2

Reproducible: Always

Steps to Reproduce:
1. receive or open a mail with a body in plain text, encoded in base64, with "Content-Transfer-Encoding: base64" and "Content-type" missing in the headers.
Actual Results:  
You'll see the body of the mail as not-decoded text and you must add "Content-type:text/plain" to the headers to see the decoded text.

Expected Results:  
You should see the text decoded also without any "Content-type" header, because according to the rfc2045, point 5.2, when the "Content-type" header is missing it's assumed to be "Content-type: text/plain; charset=us-ascii"

Comment 1

12 years ago
This is a dup of bug 230377.

Note that RFC 2045 requires that a message using one of the extensions from this RFC must contain a "MIME-Version:" header. So, technically the mail you quoted is not a valid RFC 2045 message. But I agree that this should should be fixed.

*** This bug has been marked as a duplicate of 230377 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.