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.

SWYgeW91J3JlIHJlYWRpbmcgdGhpcywgeW91J3ZlIHJlYWxpemVkIEkndmUgc3VibWl0dGVkIHRo
aXMgY29tbWVudCB1c2luZyBNSU1FNjQgZW5jb2RpbmcuICBXaHkgd291bGQgSSBzdWJtaXQgYSBw
bGFpbiB0ZXh0IGNvbW1lbnQgaW4gTUlNRTY0IGVuY29kaW5nPyAgVGhhdCdzIGEgdmVyeSBnb29k
IHF1ZXN0aW9uLiAgWW91IG1heSBhc2sgeW91cnNlbGYgd2h5IGFuIGUtbWFpbCBjbGllbnQgb24g
YSBtb2JpbGUgZGV2aWNlIHdvdWxkIHNlbmQgYSBwbGFpbiB0ZXh0IG1lc3NhZ2UgaW4gTUlNRTY0
LgoKSW1hZ2luZSBzZWVpbmcgdGhpcyBtZXNzIG9mIGNoYXJhY3RlcnMgaW4geW91ciBpbmJveC4=

Teonanactl1, it would have been better to provide actual text rather than proof of your Base64 encoded message.  We already know that Android OS does this.

The complaint is NOT that the Android email app (not the OS) can't decode base64, but that it sends it needlessly, and in violation of both the letter and intent of the RFCs. When the Android email client foolishly sends base64, such recipients see the crap that teonanactl1 posted. Google is a net newbie, and obviously clueless about how things are supposed to be done.

It was just an attempt at some silly humor.  I figured if I Base64 encoded my plain text comment needlessly, it would draw attention to precisely how nonsensical it is to Base64 encode plain text e-mail.

I think we're all on the same page here.  It had just been several months with no movement, so I wanted to do what little I could to get this in front of the powers that be.

msauve, I wouldn't say that Google is a net newbie since they have been right on par, if not already ahead, of many of the internet changes/updates.  HTML5 for example.  However, I would say that they are an email newbie since their Gmail service is one of the newer email services out there.

I also wouldn't say clueless, but rather ignorant or maybe misinformed.

I know that the email app sends messages in Base64, my message from April 7 indicates that much.

----

Teonanactl1, it appears to be a very touchy subject, especially with msauve123.  He clearly appears to take this personally and his April 9th email shows just how sensitive of a subject it is to him.  So maybe the silly humor was not the best approach.

----

The bottom line is that this needs to be repaired and a simple MIME specification in the headers is not going to fix this...if the email sent from the the email application in Android OS is parsed by an application such as a PHP-based ticket system, the message that appears is the Base64 encoding.  Not because the MIME version header was missing, but because the message is encoded in Base64 when it's not supposed to be encoded at all.

We already know that Thunderbird, Pine (a.k.a. Alpine), Mutt and other email clients can decode Base64.

The point of this is that the email client in Android OS is sending needlessly encoding messages in Base64, which is against RFC.

The bottom line is: make the email app RFC compliant.  Period.

Ha!  I can't help but laugh a little bit at this exchange.  It's a little funny because I am certain that the three of us are on the same page that this needs to be fixed and the right fix is simply to not Base64 encode plain text messages.

I am happy that you guys are still out there and clearly want this fixed as much as I do.  Cheers!

Someone who failed to properly understand the problem closed this ticket back in April so it's not clear that continuing this discussion will help unless there is mechanism for reopening the issue which I have overlooked. If you care about this, I would open a new bug instead if I were you.

So disappointing that, more than two years after I first reported this basic error, it's still present, and more generally the only way to get respectable email on Android is still to ssh to a shell account somewhere else. :(

I believe that this was fixed in k9 a few months back. The other big reason to use k9 is that the stock app stops polling and requires restart. Furthermore, k9 has many more features and is actually updated periodically. Use k9!

I think this bug was probably closed because this isn't an android issue. We'd need to find the official Email app forum to be officially heard.

Using k9, however good, fixes that single android output.  It doesn't fix
the ability of everyone else to be heard via eudora etal.

Hello,

I am the person who closed this bug on April 8th.  I would like to apologize because, due to a mistake, the bug was not actually assigned to me, and I did not receive any of the follow-up comments.  I'm fixing that right now.

I'd like to recap the issues brought up in this bug, what we knew then, and what we know now.

There are actually two different things being reported here, so let's tackle them independently.

1.  The email client is not sending MIME-Version headers

As reported, the client was not sending MIME-Version headers, and this was causing some clients to display the encoded message directly (not decoding them).  Not sending the header is clearly an RFC violation, and we fixed it right away.  We tested this against the clients that were known to be doing this, and all of them decoded the messages properly after this.  Based on this, I closed this bug.  Note - I marked it "FutureRelease" which meant that it was fixed but the update had not been delivered to any phones yet.  Since then, the fix has shipped with the Froyo release.

Note, the problems with Thunderbird were not reported until after this.  If users of Thunderbird (or any other client) are still having problems with messages sent by a *Froyo* device, we would definitely like to hear about it!  Please make sure that your update includes the following:

  * The raw message with headers (feel free to elide from/to or other sensitive info)
  * The specific client/version/os of the recipient


2.  The email client is using base64 for all outgoing messages

Some of the comments on this bug are asking that the client not use base64 unless necessary.  At this time we are not planning to make this change, for the following reasons.

a.  Although it has been claimed that the RFC's require it, I have not actually seen this (for example, I reviewed 2045 and 2046 just now.)  If you believe we've missed something, please mention so in a comment, but please add specific RFC #, section, and text.

b.  In general, we don't highly prioritize issues that are US-only optimizations.  In particular, changing this would have no benefit for our growing base of non-English speaking users, as even a single character outside of the 7-bit-ASCII range puts you right back into base64 encoding.

c.  Implementing this change requires more than a simple scan for high-bit characters.  In particular, RFC's 2822 and 2049 incur a number of additional encoding requirements (including line length, leading characters, and CRLF handling.)

I'm very open to further discussion on this, but to keep things productive, I encourage everyone to stick to specifics such as RFCs, specific interoperability failures, and so forth.

Thanks everyone for your input
Andy Stadler

Andy, thanks for your clear and thorough response on this matter.  I feel your principled interest in the RFCs is commendable and I had not considered the words of the RFCs when writing my earlier comments.  I've not reviewed the RFCs and apologize for not offering any justification based on them.

However, I would like to reiterate some reasons why base64 encoding plain-text messages is disagreeable to myself and (if I may speak for them) others in this thread:

1. Base64 encoding all emails from Android devices establishes a higher compatibility threshold for the receiving mail agents than I've seen in any other mail client.  Quickly reviewing the messages in my Thunderbird in-box, I do not see any other e-mails that are encoding plain-text with a base 64 transfer encoding.  Most use "7BIT".

2. Related to the above, legacy mail clients and MIME-compatible mail clients with buggy implementations of, say, the parsing of the MIME-Version header will default to parsing the e-mail as ASCII.

3. With plain-text content, base64 encoding adds about a third to the size, in bytes, of the message body.  A trivial matter perhaps given modern network sand disks, but nevertheless of interest.

4. As I mentioned earlier, my corporate mail server and perhaps others penalize e-mails encoded in base64 in their spam scoring algorithms.  It's a minor penalty, for certain, but one that should not be incurred simply because I elected to send an e-mail from my Android device.

5. Android devices may not be compatible with simplistic automatic e-mail applications.  For instance, legacy mailing list software, ticketing systems, or customer relationship management software that accept and process commands via plain-text e-mail bodies.  (See the original bug report at the top of this thread for more examples.)

First , my apologies -- I didn't understand that the Status: FutureRelease line in your comment of the 8th meant that that comment in fact represented the closing of the bug.

Second, some general thoughts on what I believe is the inappropriate use of base64 encoding for message bodies which can be represented as plain text:

1) It should never be necessary for a mail client on a modern Unix/Linux system such as Android to resort to trickery such as looking for set high bits to determine the character set in use.  This is because the system locale or, at worst, the active locale for the application, determines the character-set in use, and if the character-set in use is US-ASCII then the message can be of type text/plain and content-encoding 7bit.

I notice, however, that my US-market Motorola Droid produces mail messages which have the character-set set to UTF-8.  I can indeed find ways to enter messages into the mail client, using a combination of the on-screen and hard keyboards, which include non-US_ASCII characters, but I cannot find a way to generate characters which are not in the ISO-Latin-1 set.  Further, the soft keyboard must know which characters to present for input and thus _something_ in the system knows which subset of UTF-8 to produce; this problem should be tractable using, at worst, a combination of that knowledge and the simple expedient of using iconv() to convert the message body into first US-ASCII, then the various ISO-Latin-1 sets in turn, stopping when a unity transformation is discovered  (this sounds complicated.  perhaps in Java it is, though I'm skeptical.  In C it is approximately 10 lines of code and one table with approximately 20 entries).

2) Extending this general line of reasoning, if the character-set in use is any of the ISO8859 sets then the proper encoding to use is almost certainly quoted-printable.  This is because, as RFC 2045 points out, the quoted-printable encoding represents a compromise between efficient transmission of binary data and legibility of text.

3) Legibility of text matters.  Not just for quick human scanning of message parts -- I can see how Google would consider this reason obsolete or unpersuasive -- nor for compatibility with non-MIME-aware user agents used by humans, like Mail, mailx, or MM, but, more importantly, for compatibility with spam filters, mailing-list software, and general purpose mail filters such as procmail.  When tokens composed solely of 7-bit characters are base64 encoded, the result is that filter software which searches for specific character patterns is pointlessly defeated.  The quoted-printable encoding does not have this effect.

4) Again, following the reasoning of #3 above, consider the effect on a Bayesian spam filter of pointless base64 encoding, using the following two examples:

maxey:~ tls$ uuencode -m /dev/tty
begin-base64 644 /dev/tty
bob, hello
Ym9iLCBoZWxsbwo=
====
maxey:~ tls$ uuencode -m /dev/tty
begin-base64 644 /dev/tty
spam, hello
c3BhbSwgaGVsbG8K^D
====

Note that the token "hello" does not have a fixed, but rather a position-dependent, encoding in the output base64 stream.  The best-case effect is to significantly increase the cost of mail classification by requiring base64 decoding as a preliminary step, and, in fact, this is one reason why many large mail filtering systems such as SpamAssassin apply a negative score specifically to base64 mail, and others (including one large proprietary system of which I am aware) apply a considerably larger negative score to base64 mail which turns out, upon decoding, to be needlessly base64 encoded: this is (rightfully) believed to be a spam obfuscation strategy intended to defeat or increase the workload of spam filters.

Upon careful reading of RFC2045 and RFC2046 I agree that they do not prohibit or even expressly discourage the use of base64 encoding where it is unnecessary.  Such strictures are reserved for the pointless use of these encodings in headers, in the corresponding parts of the SMTP and HTTP standards.  But I believe the same basic reasons apply: many things (some of which are human-things and some of which are people-things) opportunistically scan bytestreams which have traditionally contained fixed byte patterns to see if particular such patterns are there.  The base64 encoding in particular is nasty because it defeats these scanners in a way even quoted-printable does not.  I would strongly urge that, if you do not wish to perform a "US-specific optimization" you consider changing the default encoding to quoted-printable, and making the use of q-p or base64 a setting which can be defaulted based on the language or locale used for the UI, which must presumable be set by the vendor for each market in any event.

heh.  "Human-things" and "people-things".  Just subsitute "software-things" for one of them and you'll get what I meant, rather than what I typed.

I have been fighting this on my captivate since I bought it.
If I send a message from my exchange account on the phone to another exchange user the text is gibberish it looks much like what was posted once before.

SWYgeW91J3JlIHJlYWRpbmcgdGhpcywgeW91J3ZlIHJlYWxpemVkIEkndmUgc3VibWl0dGVkIHRo
aXMgY29tbWVudCB1c2luZyBNSU1FNjQgZW5jb2RpbmcuICBXaHkgd291bGQgSSBzdWJtaXQgYSBw
bGFpbiB0ZXh0IGNvbW1lbnQgaW4gTUlNRTY0IGVuY29kaW5nPyAgVGhhdCdzIGEgdmVyeSBnb29k
IHF1ZXN0aW9uLiAgWW91IG1heSBhc2sgeW91cnNlbGYgd2h5IGFuIGUtbWFpbCBjbGllbnQgb24g
YSBtb2JpbGUgZGV2aWNlIHdvdWxkIHNlbmQgYSBwbGFpbiB0ZXh0IG1lc3NhZ2UgaW4gTUlNRTY0
LgoKSW1hZ2luZSBzZWVpbmcgdGhpcyBtZXNzIG9mIGNoYXJhY3RlcnMgaW4geW91ciBpbmJveC4=

And interesting side note. This does not happen if I send from Yahoo or Gmail.
And to further the mystery if I respond to a message from the same person I am testing my composed messages to it works fine just not while composing.
I use the default mail client on my captivate. I don't think it has anything to do with third party apps because I have had this issue since day one.

I'm absolutely thrilled that folkes like [teonanactl1] and [t...@panix.com] are so well-written and expressive.
I agree with them wholeheartedly, and have a really hard time believing that such a core element is so "broken".

I just got my first smartphone, a Motorola, and have struggled for quite some time trying to get the basic e-mail set up.  Apparently, TLS isn't handled very gracefully, but that's another story meant for a separate bug report.

When I finally got it to work, I was disappointed to see that the message come out as base64 encoded.  For all of the reasons that t...@panix.com so eloquently stated in comment 31, encoding plain text is just a bad idea.  To top that off, it does, indeed, raise the hackles of spam-detection systems, and caused my test message to go right into the Bulk mailbox of my Yahoo test account.

As someone who occasionally uses mailx, and *hates* receiving encoded or html-only mail, I refuse to be among those who send it.  I was about to resign myself to the thought that I just bought a silly little webbrowser, when I discovered secure9 mail [ http://code.google.com/p/secure9mail/ ], which nicely does what it should - sends plain text mail, *and* handles TLS correctly.  Wheee!  =)

I would love to see this fixed, as it would be nice to use the builtin mail program on my droid, but in the meantime, I won't hold my breath.

I still use Eudora 7 at home, and emails composed on my Samsung Galaxy S GT-I9000 have newlines turned into single spaces when viewed in Eudora, so that an email with several paragraphs just looks like a single paragraph! Please add an option to send plain text!

Latest Android 2.3 release still encodes all plain text mail as base64, but at least has a MIME-Version header.


Return-Path: <user@example.com>
Received: from example.org ([unix socket])
         by xxxxx (Cyrus v2.2.13-Debian-2.2.13-19) with LMTPA;
         Thu, 09 Dec 2010 08:33:14 -0800
X-Sieve: CMU Sieve 2.2
Received: from localhost (localhost [127.0.0.1])
        by example.org (Postfix) with ESMTP id 5E4BEE037
        for <user@example.org>; Thu,  9 Dec 2010 08:33:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at example.org
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5
        tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from example.org ([127.0.0.1])
        by localhost (xxxxxxxxxxxx [127.0.0.1]) (amavisd-new, port 10024)
        with ESMTP id CTQkCUBli6yU for <user@example.org>;
        Thu,  9 Dec 2010 08:33:12 -0800 (PST)
Received: from xxxxx (xxxxx [xxx.xxx.xxx.xxx])
        by example.org (Postfix) with ESMTPS id D535DE021
        for <user@example.org>; Thu,  9 Dec 2010 08:33:11 -0800 (PST)
Received: from xxxxxxx ([xxx.xxx.xxx.xx] helo=x.x.x.x)
        by xxxxxxxxx with esmtpsa (TLSv1:RC4-MD5:128)
        (Exim 4.72)
        (auth plain:user@example.com)
        (envelope-from <user@example.com>)
        id 1PQjQc-0005d9-AR
        for user@example.org; Thu, 09 Dec 2010 08:33:11 -0800
Date: Thu, 09 Dec 2010 08:33:06 -0800
Subject: Android 2.3 mail check
Message-ID: <up0xj5gk1rpqreum5cpda267.1291912386514@email.android.com>
From: <user@example.com>
To: user@example.org
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

RG9lcyB0aGlzIHNlbmQgYSBwcm9wZXIgcGxhaW4gdGV4dCBlbWFpbD8=

I'm wondering what the argument was to choose BASE64 transfer encoding over quoted-printable (or 8bit) (for text/plain at least)?
I agree that it's not against the RFC to use base64 but it causes some issues (by default!) so a bit of extra effort could be possible.

Please fix this!

Hey there!

I don't know why but some emails I sent aren't showing properly. If I write something like: "hey, what have you planned for tomorrow"?

It's delivered like this:

=?UTF-8?B?5pS25Yiw5LqM5pak5Zub55uS6ZOB6KeC6Z+z?=
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

5pyJ6aOe6Ii5MTnngrnpppnmuK/mnLrlnLrnoIHlpLTliLDmvrPpl6jvvIzooYzmnY7mlL7lpojl
pojlpITjgILmiJHov5nmoLfku47mvrPpl6jov4flhbPkuZ/lj6/ku6XjgILlpJzph4zljrvmi7Hl
jJfnp5/phZLlupfjgII8cD48YnI+546L5pyJ5Li6ICZsdDsxMzMxMTg4M jExOUAxMjYuY29tJmd0
OyB3cm90ZTo8cD7lhbblrp7kuZ3lt57muK/lvojkuI3mlrnkvr/vvIznprvmi7HljJflj4jkuI3o
v5E8YnI+PGJyPuWcqOaIkeeahOaRqeaJmOe9l+aLieaJi+acuu WPkemAgTxicj48YnI+RGF2aWQg
V2FuZyAmbHQ7ZHR3c2wxOTYyQGdtYWlsLmNvbSZndDvnvJblhp nvvJo8YnI+PGJyPuWlveeahO+8
jCDnn6XpgZPllabvvIwg5oiRMTflj7fmmZrkuIrlh7rlj5HvvI wxOOWPt+WknOmHjOeUsemmmea4
r+acuuWcuueggeWktOWdkDIw77yaMDDpo57oiLnlvoDnj6Dmtb fkuZ08YnI+5rSy5riv77yMMTnl
j7fov5vljrvmvrPpl6g8YnI+PGJyPjxkaXYgY2xhc3M9ImdtYW lsX3F1b3RlIj4yMDEyLzYvMyDn
jovmnInkuLogPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPS JtYWlsdG86MTMzMTE4ODIxMTlA
MTI2LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjEzMzExODgyMTE5QD EyNi5jb208L2E+Jmd0Ozwvc3Bh
bj48YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIi BzdHlsZT0ibWFyZ2luOjAgMCAw
IC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZG luZy1sZWZ0OjFleCI+PGJyPjxi
cj7liJrmiY3osIPor53msqHlkKzop4HvvIzlhazlj7jmnInkur rljrvlub/lt57lh7rlt67vvIzp
obrkvr/orqnku5bku6zljrvnnIvlpojlpojvvIzojLblj7bmmK/ljp/mnKzpgIHlrqLmiLfnmoTo
gIzkuJTmmK8xMDAw5YWD5LiA5pak55qE77yM5oiR6K6p5LuW5L us5YWI6YCB5aaI5aaI5oiR5YaN
6KGl57uZ5LuW5Lus77yM5L2g55qE6Iy26L+Y5rKh5Lmw77yM5o iR5Y675pe25Lya5bim5Y67PGJy
Pjxicj7lnKjmiJHnmoTmkanmiZjnvZfmi4nmiYvmnLrlj5HpgI E8YnI+PGJyPkRhdmlkIFdhbmcg
Jmx0OzxhIGhyZWY9Im1haWx0bzpkdHdzbDE5NjJAZ21haWwuY2 9tIiB0YXJnZXQ9Il9ibGFuayI+
ZHR3c2wxOTYyQGdtYWlsLmNvbTwvYT4mZ3Q757yW5YaZ77yaPG RpdiBjbGFzcz0iSE9FblpiIj48
YnI+PGJyPjxkaXYgY2xhc3M9Img1Ij48YnI+PGJyPuWlueivtO aIkeivt+S9oOS5sOeahOS6jOaW
pOWkp+e6ouWtou+8jOS9oOi/mOayoeacieS5sO+8jOaIkeWImue7meS9oOeUteivne+8jOS9oO ay
oeacieaOpeOAguWFtuS7luaXoOS6i+OAgjxicj48L2Rpdj48L2 Rpdj48L2Jsb2NrcXVvdGU+PC9k
aXY+PGJyPjxicj4=

At first I thought it was because of some ROM so I made a clean install of Gingerbread.This didn't fix it so I updated to ICS. It didn't help as well.

Not even changing my written language from Chinese to English helped.

I'm kinda desperate since I didn't see anybody else having this issue and so I have to check every single sent email to confirm that they have been sent correctly.

Thank you for your attention!

[Comment deleted]

My attempt to directly email stadler from comment #29 failed, so I'm hoping someone will notice this here.

========
I saw your very helpful comment #29 in this thread:

http://code.google.com/p/android/issues/detail?id=2630

and had a related question.  I didn't want to pollute that thread with
what I believe is a complimentary, but distinct bug.  Could you please
provide me a pointer to the best way to submit further details, or the
contact info of the correct person to address this?

Briefly, it looks like the default android email client on 2.3.4 and
later, in some cases, ignores the explicit "Content-Transfer-Encoding:" header value of "quoted-printable" on a received message attachment (the opposite of the bug in the above cited thread, which is about what the client emits), and *assumes* the attachment must be base64 encoded.  As a result, the app
base64-decodes the attachment into garbage.  My testing shows this
*seems* to be related to the total size of the message plus
attachments.  Something over about 22K or so seems to trigger this
erroneous behavior, while smaller attachments do not.

Simple example to reproduce:

1) Use any mail client which can encode text attachments as "quoted-printable" and which include the "Content-Transfer-Encoding:" header for the attachment.

2) Use a largish, >22K pure 7-bit ascii payload for the attachment.  Body doesn't seem to matter.

3) Read the message on a 2.3.4 android device with the default email app, and attempt to view the attachment in some other handler app

4) Notice that the attachment is now garbage

5) Go into the mail server spool and examine the message in situ and note that the attachment is actually clear, readable text.

I've reproduced this on a stock, non-rooted G2 (HTC) handset running
2.3.4, and a later Samsung device.

It seems as though, since the email app always emits base64 encoding
(for the reasons you described in that above cited thread) it also
*assumes* an attachment must be base64 encoded if over a certain size.
 This assumption over-rules the explicit directive of the header.
This is in violation of RFC 2045 section 6.2 quote:

   6.2.  Content-Transfer-Encodings Semantics

   This single Content-Transfer-Encoding token actually provides two
   pieces of information.  It specifies what sort of encoding
   transformation the body was subjected to and hence what decoding
   operation must be used to restore it to its original form, and it
   specifies what the domain of the result is.

Any follow up or contact info you can provide, as to how I can get
this information to the right person would be greatly appreciated.

Thanks,

Jesse

Permit me to translate Comment 29.  It appears to read "We don't see any need to follow standards."  

Note that this issue is still marked "FutureRelease," but the "fix" of adding the required header has long been in the code base. Further, lack of a MIME-Version header was an incidental finding. While it's of course good that this was corrected, it fails to address the fundamental issue.

Mr. Stadler cites that the MIME RFC's do not *require* US-ASCII messages be rendered in plain-text.  He's correct.  That's because the RFC **was not written** to address plain text messages.

I refer, though, to an early, fundamental, and oft-cited principle of Internet architecture as stated by John Postel in RFC721, section 3.2:

"The implementation of a protocol must be robust.  Each implementation must expect to interoperate with others created by different individuals.  While the goal of this specification is to be explicit about the protocol there is the possibility of differing interpretations.  In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior.  That is, it must be careful to send well-formed datagrams, but must accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear)."

In this case, I interpret being conservative in sending behavior as meaning one should not apply RFC2046, et seq., to a message to which the requirements for MIME does not apply.  MIME was developed in part for "[...]textual message bodies in character sets other than US-ASCII[...]"  For an RFC-822 compliant body written in US-ASCII be *conservative* in what you send--stick to RFC-822.

I also assert that this same conservative principle would lead one to use quoted-printable encoding instead of base64 where such encoding results in less transformation of the original message body.

Respectfully,

--Pete

p.s. +1 me too!

hi,
when i send mails from galaxy s4, some people receive something like this:
>
Reply-To: dilancetin <xxx@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.android.email_556670196931380"

----_com.android.email_556670196931380
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

SG9wIGhpcAoKClNhbXN1bmcgTW9iaWxlIHRhcmFmxLFuZGFuIGfDtm5kZXJpbGRp

----_com.android.email_556670196931380
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj48ZGl2PjwvZGl2PjxkaXY+
SG9wIGhpcDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGRpdiBzdHls
ZT0iZm9udC1zaXplOjc1JTtjb2xvcjojNTc1NzU3Ij5TYW1zdW5nIE1vYmlsZSB0YXJhZsSxbmRh
biBnw7ZuZGVyaWxkaTwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+

----_com.android.email_556670196931380--

what should i do?
please explain like you're talking to 4 year old

It's not your fault. Google is being a stupid poopy-head.

This is a pretty bad interpretation. I am using UNIX and sendmail, and am just using the default smrsh implementation to execute scripts on certain addresses.

For example
actonpager:    "|/etc/smrsh/actuponpager.sh"

Because of the lack of sticking to the standards, or using the simplest standard, no user can use the system to send in a simple text based email that I can strip thru the body and complete actions upon.

I can of course instruct users to use the subject lines, other pieces of data. But it seems to me silly to put things in base64 when the email is plain text and there are no attachments to be used.

Thanks for following up to this bug, which I originally opened with Google
four and a half years ago. Unfortunately, it was incorrectly closed three
and a half years ago by someone who didn't understand the bug report.

I therefore doubt any Google developer is likely to read your supporting
observations any more. To be honest, there isn't much evidence that anyone
competent from Google ever read any of the comments on this bug even before
it was closed.

Of course, the bundled Android mail client still remains unusable because of
base64 obfuscation nearly five years later. If you don't want to be
embarrassed by inappropriate use of MIME in public, I strongly advise
disabling it and installing an alternative written by someone less clueless.

In 2014, it's still a problem with Android 4.3.

Should we open a new bug report since there seems to be no way to re-open this one, or has everyone here just given up on the default mail client in Android?

I previously used K-9, which was fine, so I could go back to that, but I'll still have to deal with this issue for mail sent to me by users of the default Android mail app.

P.S.

K-9 did this:

  Content-Type: text/plain;
   charset=utf-8
  Content-Transfer-Encoding: quoted-printable

Default Android mail app does this:

  Content-Type: text/plain; charset=utf-8
  Content-Transfer-Encoding: base64

No, this does not bother me any more.

-�ystein

I've solved this one too by not using the buggy program, but it's quite a
tragic indictment that the stock Android email client is still broken all
these years after I first reported its anti-social behaviour.

In other words, K-9 did the totally sensible, obvious thing: default
to quoted-printable encoding; while because some Android developer
decided to dig in his or her heels and not change the holy code in
response to this bug report, the default client still gets it wrong.

Sigh.

SXQncyBuZWFybHkgMjAxNSwgYW5kIEFuZHJvaWQgNS4wIGlzIG91dC4gSXMgdGhlIHN0b2NrIEFu
ZHJvaWQgbWFpbCBjbGllbnQKc3RpbGwgYnJva2VuIGluIHRoaXMgcHJldHR5IGJhc2ljIHdheT8K

WWVzLCBpdCBpcy4gR29vZ2xlIGlzIGEgYnVuY2ggb2YgY2x1ZWxlc3MgbmV3YmllcyB3aXRoIG5vIGFkdWx0IHN1cGVydmlzaW9uLg==

Why not just use "Content-Transfer-Encoding: binary" for everything? It is identical to 7bit if you only use ASCII characters (you can even read email in telnet or openssh), it supports Unicode in any language, it can be used for binary attachments, it's not against the standard, and it's the future, because nowadays every link in the Internet supports 8 bits...

JJ

It's 2016 and users are still experiencing this issue. I am a third party IT engineer who my customer just sent me an email sent from his Samsung droid phone that he has had only 2 months and the message is not kosher.

clip of email:
[Beginning of email body]

MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_84342032445920"

----_com.samsung.android.email_84342032445920
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

CgoKClNlbnQgZnJvbSBteSBWZXJpem9uLCBTYW1zdW5nIEdhbGF4eSBzbWFydHBob25lCgoKCgoK
Ckp1c3QgYSBmb2xsb3cgdXAgaGVyZS4gwqBBbnkgbHVjayBvbiBvdXIgY29udGFjdCB0byBzZXQg
dGhlc2UgaW5zdGFsbGF0aW9ucyB1cD8KCgoKCgoKClNlbnQgZnJvbSBteSBWZXJpem9uLCBTYW1z
dW5nIEdhbGF4eSBzbWFydHBob25lCgoKCgoKCgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0t...L3A+CjwvZGl2Pgo8L2Rpdj4KPC9ib2R5PjwvaHRtbD4=

----_com.samsung.android.email_84342032445920--

[End of email body]

i don't know if this will work but i suggested using the microsoft email client for android.

TWF5YmUgR29vZ2xlIGRvZXNuJ3QgdW5kZXJzdGFuZCBwbGFpbiB0ZXh0LCB0aGV5IG9idmlvdXNseSB3YW50IGV2ZXJ5dGhpbmcgYmFzZTY0IGVuY29kZWQuCg==

SEPTEMBER 2016- PLEASE HELP ME PREVENT FURTHER EMBARRASSING EMAILS.

 Sending text only emails from my samsung Android thru hotmail/outlook exchange email looks like this to my recipients:

MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_64578122574110"

----_com.samsung.android.email_64578122574110
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

R29vZCBldmVuaW5nIExhZGllcywKQXMgS2luZGVyZ2FydGVuIHJvb20gcGFyZW50cyB3ZSBhcmUg
cmVzcG9uc2libGUgZm9yIE1vbmRheSdzIG1haW4gZGlzaC4gwqBUbyBteSBrbm93bGVkZ2UgdGhp
cyBpcyBzdGlsbCB1bmRlY2lkZWQuIMKgSWYgeW91IGtub3cgb3RoZXJ3aXNlIHBsZWFzZSByZXBs
eSBhbGwgdG8gdGhlIGZpcnN0IGVtYWlsIHdlIGFsbCByZWNlaXZlZCByZWdhcmRpbmcgdGhlIGNs
YXNzIGRpc2ggc3BlY2lmaWNzLgpBbnlvbmUgaGF2ZSBhbnkgY3Jvd2QgZmF2b3JpdGUgZGlzaGVz
IHRoZXkgd2lzaCB0byBzaGFyZT8gwqBXZSBjb3VsZCBkaXZpZGUgdXAgdGhlIGluZ3JlZGllbnRz
IGFuZC9vciBwcmVwYXJhdGlvbnMgb3IgYXNzZW1ibGUgdGhlIGRpc2ggdG9...."

Yup still happening for us as well, so I guess this never actually got resolved, I just wonder why, most email clients can of course decode it but I have received numerous complaints about this.

I've sent several of these emails and my manager has said something. What's so frustrating is that for my case it only happens once in a while. I think I may have isolated the problem. It seems to only happen when I add an email to a reply. I use a Samsung GS7 and will be taking the advice from an old post; thank you #56 parkerch...@gmail.com from 6/14/16, going to try the MS email client on the phone. It should be easy to switch between personal and work email on the app.

I failed to be clear in my initial post; correction caps below.

I've sent several of these emails and my manager has said something. What's so frustrating is that for my case it only happens once in a while. I think I may have isolated the problem. It seems to only happen when I add an email ADDRESS to a reply. I use a Samsung GS7 and will be taking the advice from an old post; thank you #56 parkerch...@gmail.com from 6/14/16, going to try the MS email client on the phone. It should be easy to switch between personal and work email on the app.

CgoKClNlbnQgZnJvbSBteSBTYW1zdW5nIEdhbGF4eSBzbWFydHBob25lLgoKCuCkr+ClguCkquCl
gCAxMDAg4KSV4KWHIOCkpOCkueCkpCDgpLLgpJfgpY3gpJzgpLDgpYAg4KS14KS+4KS54KSo4KWL
IOCkleClgCDgpLLgpL7gpILgpJrgpL/gpILgpJcgMyDgpJXgpYsg4KS54KWL4KSX4KWA4KSr4KWL
4KSf4KWLIOCkuOCkueCkv+CkpMKgwqDgpK7gpL/gpLDgpY3gpJzgpL7gpKrgpYHgpLDgpaQg4KS2
4KS+4KS44KSoIOCkleClgCDgpK7gpLngpKTgpY3gpLXgpJXgpL7gpILgpJXgpY3gpLfgpYAg4KSv
4KWL4KSc4KSo4KS+IOCkoeClieCkr+CksiDgpK/gpYLgpKrgpYAgMTAwIOCkleClgCDgpKTgpYjg
pK/gpL7gpLDgpL/gpK/gpL7gpIIg4KSq4KWC4KSw4KWAIOCkueCliyDgpJfgpIgg4KS54KWI4KWk
IDMg4KSm4KS/4KS44KSC4KSs4KSwIOCkleCliyDgpIfgpLgg4KSv4KWL4KSc4KSo4KS+4KS+IOCk
leCkviDgpLbgpYHgpK3gpL7gpLDgpK7gpY3gpK0g4KS54KWL4KSX4KS+4KWkIOCkquClgeCksuCk
v+CkuCDgpIXgpKfgpYDgpJXgpY3gpLfgpJUg4KSV4KSy4KS+4KSo4KS/4KSn4KS/IOCkqOCliOCk
peCkvuCkqOClgCDgpKjgpYcg4KSs4KSk4KS+4KSv4KS+IOCkleCkvyAzIOCkpuCkv+CkuOCkguCk
rOCksCDgpJXgpYsg4KSm4KWL4KSq4KS54KSwIOCkruClh+CkgiDgpKHgpL7gpK/gpLIg4KSv4KWC
4KSq4KWAIDEwMCDgpLjgpYfgpLXgpL4g4KSy4KS+4KSC4KSaIOCkueCli+Ckl+ClgOClpCDgpK7g
pL/gpLDgpY3gpJzgpL7gpKrgpYHgpLAg4KSV4KWLwqAgMjcg4KSs4KWL4KSy4KWH4KSw4KWLIDgg
4KSH4KSo4KWL4KS14KS+IOCkr+ClguCkquClgCAxMDAg4KSV4KWHIOCksuCkv+Ckr+ClhyDgpKrg
pY3gpLDgpL7gpKrgpY3gpKQg4KS54KWB4KSIIOCkueCliOCkguClpCDgpKbgpL/gpKjgpL7gpILg
pJXCoCAwMyDgpKbgpL/gpLjgpILgpKzgpLAg4KSV4KWLIOCksOCkvuCkpCA4OjAwIOCkrOCknOCl
hyDgpLjgpYcg4KSh4KS+4KSv4KSyIDEwMCDgpJXgpYAg4KS44KSt4KWAIOCkleClieCksiDgpK/g
pYLgpKrgpYAgMTAwIOCkquClhyDgpKHgpL7gpIfgpLXgpLDgpY3gpJ8g4KS54KWL4KSC4KSX4KWA
4KWkIOCkh+CkuOClgCDgpKbgpL/gpKgg4KSq4KWB4KSy4KS/4KS4IOCksuCkvuCkh+CkqCDgpKrg
pLDgpYfgpKEg4KSX4KWN4KSw4KS+4KSJ4KSC4KShIOCkruClh+CkgiDgpK/gpYLgpKrgpYAgMTAw
IOCkuOClh+CkteCkviDgpLLgpL7gpILgpJrgpL/gpILgpJcg4KSV4KS+IOCkleCkvuCksOCljeCk
r+CkleCljeCksOCkriDgpLngpYvgpJfgpL7gpaQg4KSH4KS4IOCkleCkvuCksOCljeCkr+CkleCl
jeCksOCkriDgpJXgpYcg4KSm4KWM4KSw4KS+4KSoIOCkruClgeCkluCljeCkryDgpIXgpKTgpL/g
pKXgpL8g4KSm4KWN4KS14KS+4KSw4KS+IOCkoeCkvuCkr+CksiAxMDAg4KSV4KWAIOCkl+CkvuCk
oeCkvOCkv+Ckr+Cli+CkgiDgpJXgpYsg4KS54KSw4KWAIOCkneCkguCkoeClgCDgpKbgpL/gpJbg
pL7gpJXgpLAg4KSw4KS14KS+4KSo4KS+IOCkleCkv+Ckr+CkviDgpJzgpL7gpI/gpJfgpL4g4KWk
IOCkl+CkvuCkoeCkvOCkv+Ckr+Cli+CkgiDgpJXgpL4g4KSw4KWC4KSfIOCkruCliOCkqiDgpJTg
pLAg4KSh4KWN4KSv4KWC4KSf4KWAIOCkmuCkvuCksOCljeCknyDgpKTgpYjgpK/gpL7gpLAg4KSV
4KSw4KS14KS+IOCksuCkv+Ckr+CkviDgpJfgpK/gpL4g4KS54KWI4KWkIOCkrOCkpOCkvuCkr+Ck
viDgpJXgpL8g4KSk4KWA4KSoIOCkpuCkv+CkteCkuCDgpJXgpL4g4KS44KSC4KSs4KSC4KSn4KS/
4KSkIOCkuOCljeCkn+ClieCkqyDgpJXgpYAg4KSf4KWN4KSw4KWH4KSo4KS/4KSC4KSXIOCkleCk
sOCkvuCkiCDgpJzgpL7gpI/gpJfgpYAg4KWkIOCksuCkvuCkguCkmuCkv+CkguCklyDgpJXgpYcg
4KS44KS+4KSlIOCkueClgCDgpLDgpL7gpKQgODowMCDgpKzgpJzgpYcg4KSV4KWHIOCkrOCkvuCk
piDgpK7gpL/gpLDgpY3gpJzgpL7gpKrgpYHgpLAg4KSV4KWAIOCknOCkqOCkpOCkviDgpIfgpLgg
4KS44KWH4KS14KS+IOCkleCkviDgpLjgpYDgpKfgpYct4KS44KWA4KSn4KWHIOCksuCkvuCkrSDg
pIngpKDgpL4g4KS44KSV4KSk4KWAIOCkueCliCDgpaQg4KSv4KS5IOCksuCkvuCkguCkmiDgpK7g
pL/gpLDgpY3gpJzgpL7gpKrgpYHgpLAg4KSV4KWAIOCkhuCkriDgpJzgpKjgpK7gpL7gpKjgpLgg
4KSV4KWHIOCksuCkv+CkjyDgpJDgpKTgpL/gpLngpL7gpLjgpL/gpJUg4KS54KWL4KSX4KS+IOCl
pCDgpKrgpYHgpLLgpL/gpLgg4KSF4KSn4KWA4KSV4KWN4KS34KSVIMKg4KSV4KSy4KS+4KSo4KS/
4KSn4KS/IOCkqOCliOCkpeCkvuCkqOClgCDgpKrgpY3gpLDgpKTgpY3gpK/gpYfgpJUg4KSm4KS/
4KSoIOCkleClgCDgpKTgpYjgpK/gpL7gpLDgpYAg4KSV4KWAIOCkruClieCkqOCkv+Ckn+CksOCk
v+CkguCklyDgpLjgpY3gpLXgpK/gpIIg4KSV4KSwIOCksOCkueClhyDgpLngpYjgpILgpaQg4KSH
4KS44KSV4KWHIOCkqOCli+CkoeCksiDgpIXgpKfgpL/gpJXgpL7gpLDgpYAg4KSF4KSq4KSwIOCk
quClgeCksuCkv+CkuCDgpIXgpKfgpYDgpJXgpY3gpLfgpJUg4KSo4KSX4KSwIOCkhuCktuClgeCk
pOCli+CktyDgpLbgpYHgpJXgpY3gpLLgpL4g4KSV4KWLIOCkrOCkqOCkvuCkr+CkviDgpJfgpK/g
pL4g4KS54KWIIOClpCDgpIfgpLgg4KSV4KS+4KSw4KWN4KSv4KSV4KWN4KSw4KSuIOCkleClhyDg
pKbgpYzgpLDgpL7gpKgg4KSh4KWJ4KSV4KWN4KSf4KSwIOCknOCkqOCkquCljeCksOCkpOCkv+Ck
qOCkv+Ckp+Ckvywg4KSf4KWA4KSa4KSwLCDgpLjgpK3gpY3gpLDgpL7gpILgpKQg4KS14KWN4KSv
4KSV4KWN4KSk4KS/IOCkhuCkpuCkvyDgpJXgpL7gpLDgpY3gpK/gpJXgpY3gpLDgpK4g4KS44KWN
4KSl4KSyIOCkquCksCDgpIngpKrgpLjgpY3gpKXgpL/gpKQg4KSw4KS54KWH4KSC4KSX4KWH4KWk
CuCkrOCkv+CknOCksuClgCDgpLXgpL/gpK3gpL7gpJcg4KSo4KWHIOCkteCkuOClguCksuClhyDg
pKHgpYfgpKIg4KSy4KS+4KSWwqAo4KSu4KWA4KSw4KSc4KS+4KSq4KWB4KSwKeClpCDgpJzgpK7g
pL7gpLLgpKrgpYHgpLAgwqDgpKzgpY3gpLLgpL7gpJUg4KSq4KSw4KS/4KS44KSwIOCkruClh8Kg
IOCkruCkguCkl+CksuCkteCkvuCksMKgIOCkleCliyDgpKzgpL/gpJzgpLLgpYAg4KS14KS/4KSt
4KS+4KSXIOCkpuCljeCkteCkvuCksOCkviDgpKzgpL/gpJzgpLLgpYAg4KSV4KS+IOCkrOCkv+Ck
siDgpJzgpK7gpL4g4KSV4KSw4KS+4KSo4KWHIOCkleClhyDgpLLgpL/gpI8g4KSV4KWI4KSu4KWN
4KSqwqAg4KSV4KS+IOCkhuCkr+Cli+CknOCkqCDgpJXgpL/gpK/gpL4g4KSX4KSv4KS+IOClpCDg
pJXgpYjgpK7gpY3gpKrCoCDgpK7gpYcg4KSP4KSVIOCksuCkvuCkliDgpLjgpYjgpKTgpL7gpLLg
pYDgpLgg4KS54KSc4KS+4KSwIOCksOClgeCkquCkr+ClhyDgpJzgpK7gpL4g4KSV4KSw4KS+4KSk
4KWHIOCkueClgeCkjyDgpKzgpK/gpL7gpLLgpYDgpLgg4KSJ4KSq4KSt4KWL4KSV4KWN4KSk4KS+
4KSTIOCkleCkviDgpJXgpKjgpYfgpJXgpY3gpLbgpKgg4KS14KS/4KSa4KWN4KSb4KWH4KSm4KSo
IOCkleClgCDgpJXgpL7gpLDgpY3gpK/gpLXgpL7gpLngpYAg4KSV4KWAIOCkl+Ckr+ClgOClpOCk
tuCkv+CkteCkv+CksCDgpK7gpYcg4KSJ4KSq4KSt4KWL4KSV4KWN4KSk4KS+4KSTIOCkuOClhyDg
pKrgpL7gpJog4KS44KWMIOCksOClguCkquCkr+ClhyDgpJXgpYcg4KSo4KWL4KSfIOCkreClgCDg
pKzgpL/gpLIg4KSV4KWHIOCksOClguCkqiDgpK7gpYcg4KSy4KS/4KSv4KWHIOCkl+Ckr+ClhyDg
paQg4KSP4KS4IOCkoeClgCDgpLjgpYAg4KSs4KS/4KSc4KWH4KSC4KSm4KWN4KSwIOCkuOCkv+Ck
guCkuSDgpKbgpY3gpLXgpL7gpLDgpL4g4KSq4KWI4KSk4KS+4KSy4KWA4KS4IOCkrOCkv+CksuCl
iyDgpJXgpL4g4KS44KSC4KS24KWL4KSn4KSoIOCkleCksOCkpOClhyDgpLngpYHgpI8g4KSs4KS/
4KSyIOCknOCkruCkviDgpJXgpLDgpL7gpK/gpL4g4KSX4KSv4KS+IOClpCDgpLbgpL/gpLXgpL/g
pLAg4KSu4KWHIOCkheCkteCksCDgpIXgpK3gpL/gpK/gpILgpKTgpL4g4KS24KWI4KSy4KWH4KS2
IOCkleClgeCkruCkvuCksCwg4KSP4KS4IOCkoeClgCDgpJMg4KSPMCDgpKrgpYAwIOCkr+CkvuCk
puCktSwg4KSF4KSc4KSvIOCkquCkvuCkguCkoeClh+Ckrywg4KS44KSo4KWN4KSk4KWL4KS3IOCk
ieCkquCkuOCljeCkpeCkv+CkpCDgpLDgpLngpYcg4KWkCuCkluClh+CkpCDgpLjgpYcg4KSq4KSC
4KSq4KS/4KSC4KSXIOCkuOClh+CknyDgpJXgpYAg4KSa4KWL4KSw4KWAwqDgpJzgpK7gpL7gpLLg
pKrgpYHgpLAgKOCkruClgOCksOCknOCkvuCkquClgeCksCAp4KWkIOCkuOCljeCkpeCkvuCkqOCl
gOCkryDgpKXgpL7gpKjgpL4g4KSV4KWN4KS34KWH4KSk4KWN4KSwIOCkleClhyDgpJbgpYfgpK7g
pIjgpKzgpLDgpYAg4KSX4KS+4KSC4KS1IOCkruClhyDgpLjgpYvgpK7gpLXgpL7gpLAg4KSV4KWL
IOCksOCkvuCkpOCljeCksOCkvyDgpKbgpLgg4KSs4KSc4KWHIOCkleClhyDgpKzgpL7gpKYg4KSF
4KSc4KWN4KSe4KS+4KSkIOCkmuCli+CksOCliyDgpKbgpY3gpLXgpL7gpLDgpL4g4KSq4KWN4KSv
4KS+4KSw4KWHIOCkuOCkv+CkguCkuSDgpJXgpYcg4KSW4KWH4KSkIOCkruClhyDgpLDgpJbgpYcg
4KSq4KSu4KWN4KSq4KS/4KSXIOCkuOClh+CknyDgpKrgpLAg4KSa4KWL4KSw4KWLIOCkqOClhyDg
pLngpL7gpKUg4KS44KS+4KSrIOCkleCksCDgpKbgpL/gpK/gpL4g4KWkIOCkleCkv+CkuOCkvuCk
qCDgpKjgpYcg4KSX4KWH4KSC4KS54KWCIOCkleClgCDgpLjgpL/gpJrgpL7gpIgg4KSV4KWHIOCk
suCkv+CkjyDgpKrgpK7gpY3gpKrgpL/gpJcg4KS44KWH4KSfIOCkleCliyDgpJbgpYfgpKQg4KSq
4KSwIOCksOCkluCkviDgpKXgpL4g4KWkIOCkquCljeCkr+CkvuCksOClhyDgpLjgpL/gpLkg4KSo
4KWHIOCkuOClgeCkrOCkuSDgpJjgpJ/gpKjgpL4g4KSV4KWAIOCknOCkvuCkqOCkleCkvuCksOCl
gCDgpLngpYvgpKjgpYcg4KSq4KSwIOCkpeCkvuCkqOClhyDgpK7gpYcg4KSk4KS54KSw4KWA4KSw
IOCkpuCkv+Ckr+CkviDgpaQKCuCkruCkvuCksOCkquClgOCknyDgpK7gpYcg4KSm4KS+4KSC4KSk
IOCkleCkvuCkn+Ckviwg4KSc4KSu4KS+4KSy4KSq4KWB4KSwwqAgKOCkruClgOCksOCknOCkvuCk
quClgeCksCAp4KWkIOCkuOCljeCkpeCkvuCkqOClgOCkryDgpKXgpL7gpKjgpL4g4KSV4KWN4KS3
4KWH4KSk4KWN4KSwIOCkleClhyDgpK7gpKDgpKjgpL4g4KSX4KS+4KSC4KS1IOCkruClhyDgpK7g
pILgpJfgpLLgpLXgpL7gpLAg4KSV4KWLIOCkueCliOCkpuCksCDgpIXgpLLgpYAg4KS1IOCkquCl
jeCksOCkueCljeCksuCkvuCkpiDgpLjgpL/gpILgpLkg4KSu4KWHwqAg4KS54KWB4KSIIOCkruCk
vuCksOCkquClgOCknyDgpK7gpYcg4KSq4KWN4KSw4KS54KWN4KSy4KS+4KSmIOCkuOCkv+CkguCk
uSDgpKbgpY3gpLXgpL7gpLDgpL4g4KS54KWI4KSm4KSwIOCkheCksuClgCDgpJXgpL4g4KSu4KWB
4KS5IOCkmuCkrOCkvuCkleCksCDgpKbgpL7gpKTgpYsg4KS44KWHIOCkluCkviDgpLLgpL/gpK/g
pL4g4KWkIOCkquClgOCkoeCkvOCkv+CkpCDgpKrgpJXgpY3gpLcg4KSo4KWHIOCkpeCkvuCkqOCl
hyDgpK7gpYcg4KSk4KS54KSw4KWA4KSwIOCkpuCkv+Ckr+CkviDgpLngpYgg4KWkCgo=

I can confirm this issue Samsung GS. Messages are send using Exchange and end up unreadable for recipients.
.....
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_1421473044661970"

----_com.samsung.android.email_1421473044661970
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
.....

@63 machiel.. - Your post shows you are using Samsung's email app, not the AOSP email app. Please contact Samsung for issues with their app. Thanks.

Easy fix is to copy paste all the content of the mail to notepad then save with the extension of .html or .doc and open :)

Meassage to #65 alex.eng..@gmail.com
I have looked through this thread and find it rather alarming. I am receiving emails like this from my friend with a samsung. I have tried your suggested fix but it doesn't seem to work. I get the same undecoded characters in .html opening in Chrome
.

I sent 2 emails to a friend today. The first,I inadvertently put my thumb on the screen and it "sent".  She got a mime encrypted email from me. I did it again, sent normally. Same thing. Hubby identified mime encryption base64. I have an LG android phone running Chrome. I think. What do I do?

You'll have to get another mail app - that's basically the only solution. I like K-9 Mail and it handles this just fine.