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@example.com Message-Id: <200512151300.jBFD07fU008343@xxx.xxx.com> To: firstname.lastname@example.org Subject: Test mail encoded in base64 Return-Path: email@example.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"
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 ***