thunderbird does not decode base64 emails ("Conten-Type: text" instead of proper text/plain)

Assigned to


MailNews Core
9 years ago
6 years ago


(Reporter: Matěj Cepl, Assigned: Phil Lacy)


1.9.1 Branch

Firefox Tracking Flags

(Not tracked)



(3 attachments)



9 years ago
Created attachment 418189 [details]

Description of problem:
An email that is base64 encoded is not decoded.  Making it somewhat difficult
to read.  Using another mail client allows me to read that email just fine,
leading me to believe that it is thunderbird, not the email itself.

Version-Release number of selected component (if applicable):

Steps to Reproduce:
1. Get base64 email
2. attempt to read
3. scratch head

Actual results:
Thunderbird will show the contents of the email like this:


Expected results:

Decode my message!  Like evolution does.

Additional info:

Sample base64 encoded message attached.  It appears a perl script that uses
MIME::Lite to send messages to me is especially good at creating base64 emails
that thunderbird happily forgets to decode.

Comment 1

9 years ago
additional info:

not IMAP, occurs in local folders also.

if you copy to draft folder and then edit it it does show up ok in composer
The mail has next heders({LF}=0x0A). Wrong mime-type is specified.
> X-Mailer: MIME::Lite 3.027 (F2.74; T1.28; A2.04; B3.07; Q3.07)
> Content-Type: text{LF}

If major-type/sub-type is correctly specified, Tb 3 displayed normaly.
> [case-1] Content-Type: text/plain{LF}
> [case-2] Content-Type: text/css{LF}
If next(no sub-type after /), Tb displayed as expected.
> [case-3] Content-Type: text/{LF}
Summary: thunderbird does not decode base64 emails → thunderbird does not decode base64 emails ("Conten-Type: text" instead of proper text/plain)

Comment 3

9 years ago
(In reply to comment #2)
> The mail has next heders({LF}=0x0A). Wrong mime-type is specified.
> > X-Mailer: MIME::Lite 3.027 (F2.74; T1.28; A2.04; B3.07; Q3.07)
> > Content-Type: text{LF}

Wrong? If I read section 4.1 then specifying just type text implies text/plain, doesn't it?

Comment 4

9 years ago
BTW, to provide back link ... this was originally

Comment 5

9 years ago
There's lots of revs etc but I found this in RFC 2045, but we may still want to support using plain if the encoding is giving

[[[[[[[[[[[[[ quote ]]]]]]]]]]]]]]]]
5.1.  Syntax of the Content-Type Header Field

   In the Augmented BNF notation of RFC 822, a Content-Type header field
   value is defined as follows:

     content := "Content-Type" ":" type "/" subtype
[[[[[[[[[[[[[ snip ]]]]]]]]]]]]]]]]
   Note also that a subtype specification is MANDATORY -- it may not be
   omitted from a Content-Type header field.  As such, there are no
   default subtypes.
[[[[[[[[[[[[[ quote ]]]]]]]]]]]]]]]]

Comment 6

9 years ago
Not that I wouldn't be warned against MIME RFCs, but apparently they are really quite a piece of art ;). Am I wrong to suggest that these two parapgraphs are contradicting each other?

Comment 7

9 years ago
(In reply to comment #5)
> [[[[[[[[[[[[[ quote ]]]]]]]]]]]]]]]]
>      content := "Content-Type" ":" type "/" subtype
> [[[[[[[[[[[[[ snip ]]]]]]]]]]]]]]]]

following I think would be more like an optional part

>      content := "Content-Type" (":" type "/" subtype)

Comment 8

9 years ago
sorry meant
      content := "Content-Type" ":" type ("/" subtype)

Comment 9

9 years ago
if OExp and html clients are going to support it, I'll try to do a patch.
Assignee: nobody → philbaseless-firefox
OS: Linux → All
Hardware: x86_64 → All

Comment 10

8 years ago

we do need to support this per rfc2045 recommendations:

5.2.  Content-Type Defaults

   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.
   It is also recommend that this default be assumed when a
   syntactically invalid Content-Type header field is encountered.

Comment 11

8 years ago
In searching for this bug, there seem to be many reports regarding base64. Perhaps they are all related to base64?

I sometimes receive emails with paramenters:
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

This displays as plain text without CR/LF.  If I save in drafts, it correctly shows new lines now, but still plain text without any html tags processed.

Comment 12

8 years ago
(In reply to comment #11)
I'm new to C, but not new to programming.  I may be willing to get my feet wet on this one with some guidance.

Comment 13

8 years ago
Created attachment 428131 [details]
problem email due to bug

This is the problem email. Download and drag to your folder. Maybe it has to be an IMAP folder I don't know.

Comment 14

8 years ago
Created attachment 428132 [details]
same message as problem only it displays ok

Same message with content-type changed from text to text/plain.
Again drag into folder and it displays ok.

The patch needs to handle messages malformed with no subtype per RFC per previous comment. You're welcome to give it a go.  I haven't started it so just reassign to you. Not sure where you can start maybe David Bienvenu can get you started.
You need to log in before you can comment on or make changes to this bug.