Committed, thanks!

Changes have been made in Git (master):

commit 9bd6a44fc314b635f66c5e95f0e21c3fea3793ab
Author: horde@albasoft.com <horde@albasoft.com>
Date:   Mon Dec 3 12:44:54 2012 -0500

     Bug: 11805  Ensure we use the proper transfer encoding when 
saving to sent.

     Signed-off-by: Michael J Rubinsky <mrubinsk@horde.org>

  .../Core/lib/Horde/Core/ActiveSync/Driver.php      |    3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)

http://git.horde.org/horde-git/-/commit/9bd6a44fc314b635f66c5e95f0e21c3fea3793ab

Sorry, I said "to my SMTP server", but this bug applies only to IMAP 
sent folder.
Thunderbird can't decode what it finds on sent folder.

When I send an email from an iPhone with iso-8859-1 chars at the 
message body,  I get an unreadable message on my email client 
(Thunderbird email reader), and an error on iPhone while reading sent 
folder.

iPhone properly composes the message with base64, and so there's a 
header like:
  Content-Transfer-Encoding: base64
but message arrives to my SMTP server with that header unchanged but 
body content already decoded. So my email reader unsuccessfully tries 
to decode it again.

I think there are some errors in Core/ActiveSync/Driver.php with 
charset handling. At line 1183:
   $msg = $copy->toString(array('headers' => $headers->toString()));
where $headers are a copy of the original headers (including 
Content-Transfer-Encoding: base64), but $copy ->toString  will 
generate a string with quoted-printable encoding. The resulting 
message will be unreadable.

If I insert the following lines fixing encoding just before line 1183, 
everything works as expected:
if ($headers->getValue('Content-Transfer-Encoding')) {
   
$copy->setTransferEncoding($headers->getValue('Content-Transfer-Encoding'), 
array('send' => true));
}
Now body message encoding matches that at headers (base64).