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

Status: ASSIGNED

(MailNews Core :: MIME, defect)

Description

[Matěj Cepl]

Attachment: reproducer

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):
thunderbird-3.0-4.fc12.x86_64

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:

VVBEQVRFIGludmVuX21hbmFnZW1lbnRfcG8gU0VUIGN1c3RfYmluID0gJ0kwMi0wMS0wMicgIFdI
RVJFIHBvX2tleSA9MTE2NDQ5IEFORCBsaW5lbnVtID0gNDA=

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

[Phil Lacy]

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

Comment 2

[WADA:World Anti-bad-Duping Agency]

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}

Comment 3

[Matěj Cepl]

(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 http://www.ietf.org/rfc/rfc2046.txt section 4.1 then specifying just type text implies text/plain, doesn't it?

Comment 4

[Matěj Cepl]

BTW, to provide back link ... this was originally https://bugzilla.redhat.com/show_bug.cgi?id=548067

Comment 5

[Phil Lacy]

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

[Matěj Cepl]

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

[Phil Lacy]

(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

[Phil Lacy]

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

Comment 9

[Phil Lacy]

if OExp and html clients are going to support it, I'll try to do a patch.

Comment 10

[Phil Lacy]

informational:

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

[Don Shank]

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

[Don Shank]

(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

[Phil Lacy]

Attachment: 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

[Phil Lacy]

Attachment: 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.