CiviCRM Community Forums (archive)

not yet,  we are in the middle of a migration.  you should have received an email about it this morning.  let me know if you did not.

when the migration is over we will investigate this further.

thanks for your patience,

-Shane

ok,  all looks OK on our end with the XML escaping. so that is not an issue.

please let me know what you find out.

-Shane

My gut feeling is this happens with any base64-encoded emails – it’s just that Outlook 2007 sends these more often than other clients (i.e., is more easily – always? – triggered into sending base64 instead of ~plain text).

I just performed a test sending through CiviSMTP and replying using an Evolution client. Here is the resulting source of the garbled reply.

Return-Path: <do-not-reply@lists.democratsabroad.org>
Delivered-To: 6-dmgray0325@fareast.com.au
X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on
   ip-208-109-30-20.ip.secureserver.net
X-Spam-Level:
X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,UPPERCASE_25_50
   autolearn=ham version=3.1.9
Received: (qmail 31898 invoked from network); 5 Apr 2008 10:29:27 +1100
Received: from civismtp.uas.coop (67.212.170.242)
  by ip-208-109-30-20.ip.secureserver.net with SMTP; 5 Apr 2008 10:29:27 +1100
Received: from lists.democratsabroad.org (HELO localhost) (208.69.4.60)
  (smtp-auth username da-ccrmu, mechanism cram-md5)
  by civismtp.uas.coop (qpsmtpd/0.40) with ESMTPA; Fri, 04 Apr 2008 18:29:12 -0500
MIME-Version: 1.0
Subject: Re: Mail to test Mantis Issue #341
To: dmgray0325@fareast.com.au
From: "Dennis Gray" <dmgray0325@fareast.com.au>
Reply-To: dmgray0325@fareast.com.au
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Date: Fri, 04 Apr 2008 19:29:27 -0400
Message-Id: <20080404232912.99E39124C090@civismtp.uas.coop>



--=-YRzFqvp5mNvHJaklbK68
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

This is an HTML formatted reply sent from Evolution.

--=-YRzFqvp5mNvHJaklbK68
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

&amp;lt;!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"&gt;
&amp;lt;HTML&gt;
&amp;lt;HEAD&gt;
  &amp;lt;META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"&gt;
  &amp;lt;META NAME="GENERATOR" CONTENT="GtkHTML/3.14.3"&gt;
&amp;lt;/HEAD&gt;
&amp;lt;BODY&gt;
This is an HTML formatted reply sent from Evolution.
&amp;lt;/BODY&gt;
&amp;lt;/HTML&gt;

--=-YRzFqvp5mNvHJaklbK68--

I took a look at the CiviCRM 1.9 sources.  The following from CRM/Mailing/BAO/Reply.php is almost certainly wrong:
        $message =& new Mail_Mime("\n");
        $headers = array(
            'Subject'       => "Re: {$mailing->subject}",
            'To'            => $mailing->replyto_email,
            'From'          => $from,
            'Reply-To'      => empty($replyto) ? $dao->email : $replyto,
            'Return-Path'   => "do-not-reply@{$domain->email_domain}",
        );
        $message->setTxtBody($body);
        $b = $message->get();
        $h = $message->headers($headers);

If you look at the code in packages/Mail/mime.php,  you'll see that the Mail_Mime object sets its headers for a text message unless you explicitly ask it to do otherwise.  In addition, the body of the email is passed on to the object via the setTxtBody message.  This is fine if your message is text.  I'm guessing that there isn't a check to make sure that the body was really text.

An easy option might be to include the mail as a mime attachment instead of using the TxtBody (which is obviously wrong).

So using this function in Reply.php from mime.php

    /**                                                                                                                     
     * Adds a file to the list of attachments.                                                                               
     *                                                                                                                       
     * @param  string  $file       The file name of the file to attach                                                       
     *                             OR the file data itself                                                                   
     * @param  string  $c_type     The content type                                                                         
     * @param  string  $name       The filename of the attachment                                                           
     *                             Only use if $file is the file data                                                       
     * @param  bool    $isFilename Whether $file is a filename or not                                                       
     *                             Defaults to true                                                                         
     * @return mixed true on success or PEAR_Error object                                                                   
     * @access public                                                                                                       
     */
    function addAttachment($file, $c_type = 'application/octet-stream',
                           $name = '', $isfilename = true,
                           $encoding = 'base64')

lobo

The code is called from amavisd (approx line 16667) via the SOAP interface. So the arguments are marshalled and sent in via Perl/SOAP

regarding the cost/benefit issue, i'm a bit unsure how to answer that. It will take us some time also to figure out the code, replicate the problem and fix it. As an open source project we do appreciate contributions and patches to existing issues

lobo

Please file an issue and we'll take care of this in the 2.1 release cycle

lobo