From my comments on a related issue:

Offense occurs at line 446 of LocalStore.java. Trying to figure out how to fix it
without screwing everything up.

The system seems to create nicely formed messages, then store them on local storage,
then totally mangle them all into multipart messages when it re-loads them form local
storage. I've got a partial fix, but it's a mess because I don't entirely understand
the sending process. In the mean time, this eliminates the garbage and makes the
messages valid.

(No comment was entered for this change.)

Here's user randalla's description of the problem from duplicate  issue 28 :

What steps will reproduce the problem?
1. Send email to mailing list
2. Get reply back from list saying multipart/alternative is not supported

What is the expected output? What do you see instead?
I need to be able to send email to mailing lists that support only plain
text email. Every email client I've worked with on the computer has the
ability to switch into this format. Honestly, I'm curious as to why K9 and
the rest of the email applications (GMail included) on Android send as
multipart/alternative since there seems to be no way to author rich text
emails.

Whenever I do send to these lists, I get a response back from the list
stating that multipart/alternative is not supported.

What version of the product are you using? On what operating system?
K-9 Mail v0.7
Android R19

Please provide any additional information below.
The account is set up via IMAP.

(No comment was entered for this change.)

I too find it strange that plain text is being encoded as base64. It's not like this helps reduce the 
transmission size since it's not being compressed. Because I use an intermediate SMTP server to archive 
outgoing messages before handing it off to my email service provider's SMTP server, it needs to be plain 
text to be properly processed. As a result. Right now I'm not able to send email using my G1 unless I 
want to give up the archiving.

(No comment was entered for this change.)

I do not know if this relates to the same issue but here is what I did to reproduce.

o I setup IMAP on the G1 via k9 and the normal email app. 
o NOTE: We use smtp authentication for sending mail over SSL/TLS.
o I sent a message from the phone to a my email address on the same domain.  
o The following is the message headers then a line break then the body
o NOTE: I removed part of the email address as they appeared other then that the
following is unchanged.

Received: from mailhost.unt.edu (129.120.188.67) by ad.unt.edu
 (129.120.209.55) with Microsoft SMTP Server id 8.1.340.0; Tue, 10 Mar 2009
 13:38:57 -0500
Message-ID: <7lo31d$2vitci@mailhost.unt.edu>
X-SBRS: None
X-Policy: SUSPECTLIST_NO_SBRS-$THROTTLED_NO_SBRS
X-ExtLoopCount1: 1
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApMlAKNQtknQNg5F/2dsb2JhbACMaykBhnsDggSuNZMEBmE
X-IronPort-AV: E=Sophos;i="4.38,337,1233554400"; 
   d="scan'";a="100234647"
Received: from m450e36d0.tmodns.net (HELO localhost) ([208.54.14.69])  by
 mailhost.unt.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Mar 2009 13:38:55
 -0500
MIME-Version: 1.0
Content-Type: text/plain
From: <REMOVED@unt.edu>
To: Undisclosed recipients:;
Return-Path: REMOVED@unt.edu
Date: Tue, 10 Mar 2009 13:38:57 -0500

Message-ID: <lmhngfi156ow2q8q6ei1u3tv.1236710175420@email.android.com>
Subject: Testes
From: REMOVED REMOVED <REMOVED@unt.edu>
Date: Tue, 10 Mar 2009 13:36:13 -0500
To: REMOVED@unt.edu
Content-Type: multipart/mixed; boundary="----GHWHEWDAPBY01AKB9BFMLWMRJ5QAWO"
MIME-Version: 1.0

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

VGVzdGVzCgoKCg==

------GHWHEWDAPBY01AKB9BFMLWMRJ5QAWO--

how to add html in the body from Android, and sent him to intent.extra_text I get
text, leaving blank intent.extra_stream

I'd like an option to just send plain un-base64ed text with no html part. I'm typing
in plain text and I'd like it to stay plain text (unless I put any extended
characters in) and I never want an html alternative since it wastes too much
bandwidth when I'm stuck on very slow GPRS when in the middle of nowhere and it's
completely unneeded.

P.

Ok,

I have this issue too but it results in getting two copies of the message body when
reading in Mail for OSX. This is my related issue report,
http://code.google.com/p/k9mail/issues/detail?id=456 

Andy

Appears to be fixed in 114. :)

It does, although the message type is still:
  Content-Type: multipart/mixed;
when there is only one part, however, and it's still base64 encoded when the content
is plain 7bit text.

 Issue 510  has been merged into this issue.

This is making my sent mail unreadable by gmail users.  FYI

@jerryab

Are you sure this is the cause? I can read emails sent from K-9 without pb in GMail

 Issue 571  has been merged into this issue.

 Issue 623  has been merged into this issue.

Seeing the same issue in 1.100 beta -- messages being sent in base64.

I see the same issue in 1.102 beta.

Moreover, it causes my mail to be detected as spam:
http://code.google.com/p/k9mail/issues/detail?id=669

I am still experiencing this problem in the most recent 2106 release. I am running
IMAP with outgoing mail through SSL on port 993 and IMAP with TLS on port 2525. Any
other options are at their default values.

It would appear that when the message is sent there is a carrier return between
Subject: and To: in the email header, but have no idea what is causing it. This
happens independent of which domain the mail is being sent to. I don't have any logs
available at this time, but will get them if it would be valuable to the community. I
would really like to see progress on this project and am willing to contribute as
much as my knowledge will allow.

A last note, I am using a Motorola DROID on Verizon.

(No comment was entered for this change.)

I've recently begun having the same problem with my IMAP account in K9mail. This wasn't a problem for me 
until I recently updated K9mail to version 2.000. No other changes made to the account configuration in 
K9mail or on the server side (per the mail system admins). Until then, I had been sending via TLS just fine. 
Since then, I've uninstalled/reinstalled K9mail, and removed/readded the server configuration. Same result.

Dismissing this as a client-side issue is avoiding the problem. I've yet to find a single user that is capable of 
reading e-mail that I send from K9. To me, there's very clear evidence that it's a K9 bug.

This new problem has rendered K9mail largely useless for me. Very frustrated.

 Issue 997  has been merged into this issue.