IssueTracker

I have the same problem. Interestingly, this is also happening in K9Mail.

Can someone create a patch?

Is the Gmail outgoing message option set to "ASCII" or "UTF-8"?  Maybe the app is
using this setting?  Scanning the whole message for 8-bit octets is quite expensive, I
believe non-MIME clients should be updated.  Just my 2 cents.

As far as I can tell, this issue is not related to the selection of the character
set, but simply improper use of base64 transfer encoding.

Despite the fact that modern mail clients can, in fact, parse base64 into plain text,
there is no compelling reason to send plain text messages as base64.  Doing so and
using the excuse that older clients should be updated strikes me as the expedient
decision that was made in the present version of Android.  But this should be
addressed because the behavior is not reasonable in the long-term as the user base grows.

Just as an aside, when I receive messages from Android users, my corporate mail
server increases the message's spam score slightly by triggering the "MIME_BASE64"
rule.  Not a huge issue but one of the many small reasons that base64 encoding plain
text is ill advised.

This really needs to be, at the very least, a selectable option. There is no good
reason to use base64 encoding for 7-bit ascii messages!

Not clear if this is a client (Android IMAP/POP 'Email') problem or some underlying
library routine.

All MUAs should support sending standard, plain text, non-encoded RFC-822 compliant messages. Encoding plain text as base64 is just plain dumb.

I see this fairly basic defect still remains many months and several Android releases
later, as do the problems with threading headers (defect 2629) and even message-id
generation (defect 3030).

Apparently the easiest (only?) way to send well-formed email that isn't embarrassing
(i.e. correct references and in-reply-to headers, no superfluous MIME obfuscation and
proper quoting without top-posting) from an Android device is by using an ssh client
and a remote mail client like mutt. That's pretty disappointing for a platform whose
selling point is supposed to be excellent internet integration out-of-the-box.

Perhaps this should be a separate bug report, but it doesn't even send the base64
properly. According to RFC 2049 § 2.1, 'A mail user agent that is MIME-conformant
MUST: (1) Always generate a "MIME-Version: 1.0" header field in any message it creates.'

My email client (Elm 2.4ME+) is unnecessarily strict about this. It refuses to honor
any Content-Transfer-Encoding if the Mime-Version: 1.0 header is not present. So when
I get something from an Android user, I only see the base64-encoded text.

This is a problem for the pine and Eudora MUAs.

RFC 2045
Part 4, MIME-Version Header Field reads in part:

   Messages composed in accordance with this document MUST include such
   a header field, with the following verbatim text:

     MIME-Version: 1.0

Additionally any complete reading of RFC 2045 and RFC 2046 makes it clear that it is
preferable to use the least encoding possible (ie unencoded US-ASCII is most
preferable and quoted-printable should be prefered over base64 for plain text),
although it is not an explicit requirement.

I'm getting complaints from co-workers who use correct but minimal text-based mail
readers that they can't read my msgs. We did a header examine,the MINE-Version header
is indeed missing and the least-encoding preference is ignored.

Come on, Google, fix it one way or the other.

Please please please escalate the priority here.  It is causing lots of problems.  
How hard can it be to add the correct Mime-Version: 1.0 header?  Please!

This is absolutely a must.  Below is the full message sent from the "Email" application on my Motorola DROID.

I've edited the emails to prevent Spam to me.  All other output is 100% unaltered.

=====
Return-path: <me@nospam.com>
Envelope-to: me@nospam.com
Delivery-date: Wed, 07 Apr 2010 13:09:16 -0600
Received: from user1 by box252.bluehost.com with local-bsmtp (Exim 4.69)
        (envelope-from <me@nospam.com>)
        id 1NzacL-0008MZ-D4
        for user1@domain.com; Wed, 07 Apr 2010 13:09:16 -0600
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on box252.bluehost.com
X-Spam-Level:
X-Spam-Status: No, score=-100.0 required=5.0 tests=USER_IN_WHITELIST
        shortcircuit=ham autolearn=disabled version=3.2.5
Received: from mail.mydomain.com ([1.2.3.4] helo=mydomain.com)
        by box252.bluehost.com with smtp (Exim 4.69)
        (envelope-from <me@domain.com>)
        id 1NzacL-0008Lk-0b
        for user1@mydomain.com; Wed, 07 Apr 2010 13:08:49 -0600
Received: (qmail 17749 invoked by uid 453); 7 Apr 2010 19:08:47 -0000
X-Virus-Checked: Checked by ClamAV on mydomain.com
Received: from [97.226.18.90] (HELO localhost) (97.226.18.90)
  (smtp-auth username user1, mechanism plain)
  by mydomain.com (qpsmtpd/0.40) with ESMTPA; Wed, 07 Apr 2010 12:08:47 -0700
Date: Wed, 07 Apr 2010 12:08:57 -0700
Subject: Header test
Message-ID: <rb9v14xph6nh8p6rxabrpo77.1270667318548@email.android.com>
From: Hummdis <me@mydomain.com>
To: Hummdis <user1@mydomain.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
X-Identified-User: {846:box252.bluehost.com:user1:mydomain.com} {sentby:spamassassin for local delivery
to identified user}

VGhpcyBzaG91bGQgYmUgZ29vZC4=
=====

That last line says "This should be good." and nothing else.  No attachments.  Either I'm blind or the MIME
header is missing.

Android OS 2.1 -- Motorola DROID -- Verizon Wireless

The bug was that MIME-Version: 1.0 was only being written in messages that had
multipart headers, e.g. with attachments.  This is now fixed, and we'll send
MIME-Version: 1.0 in *all* outgoing messages, no matter what else is in the message
structure.

I've tested this with receiving clients Alpine 2.00, Mutt 1.4.2.3i, and elm 2.4ME+
and all three were able to properly display the incoming messages (even with base64
encoding.)

Seriously? The problem is that you're sending base64 encoded messages AT ALL when plain text is sufficient.

Adding a MIME header doesn't fix that. Noway, nohow.

Maybe the MIME-Version header should come before the mime-encoded References header
in order to render without errors in Thunderbird. Seems the problem persists even
though the version header is there.. I get base64 data on screen and some lost
threads/in-reply-to occasionally.

/jonas

"msauve123" is correct.  Adding the MIME type is not going to completely resolve the
problem.  Base64 encoding should only be done if there are attachments being sent.  
More than likely about 95% of the emails sent from the DROID are plain text and
therefore should not be encoded base64 at all.

As for "bosson", the order of the headers shouldn't matter as per the RFC.  
Therefore, Thunderbird has a bug if it's requiring a special order for the MIME
headers.  Having been a user of Thunderbird for many years, I can't say that I've
ever seen a problem with the header order in Thunderbird.