Similar to the http://drupal.org/node/1182360 issue.
The $sender variable in headers is double encoded.
In the function mimemail_headers() 

  // Convert From header if it is an array.
  if (is_array($headers['From'])) {
    $headers['From'] = mimemail_address($headers['From']);
  }

  // Run all headers through mime_header_encode() to convert non-ascii
  // characters to an rfc compliant string, similar to drupal_mail().
  foreach ($headers as $key => $value) {
    $headers[$key] = mime_header_encode($value);
  }

And before in mimemail_address() function:

if (is_array($address)) {
    // It's an array containing mail and/or name.
    if (isset($address['mail'])) {
      $output = '';
      if (empty($address['name']) || $simple_address) {
        return $address['mail'];
      }
      else {
        return '"'. addslashes(mime_header_encode($address['name'])) .'" <'. $address['mail'] .'>';
      }
    }

    // It's an array of address items.
    $addresses = array();
    foreach ($address as $a) {
      $addresses[] = mimemail_address($a);
    }
    return $addresses;
  }

When address field is array and contains unicode chanracter, 'From' header looks like "=?UTF-8?B?Ij0/VVRGLTg/Qj9VbVZ1ZEdsdVowbHVkR1Z5Ym1GMGFXOXVZV3d1WTI5dElGUm8=?=.=?...."

CommentFileSizeAuthor
#5 mimemail-1908318-5.patch807 bytessgabe
#4 mimemail-sender_is_double_encoded-1908318-4.patch553 byteszionduc
#3 mimemail-sender_is_double_encoded-1908318-3.patch553 byteszionduc

Comments

jvieille’s picture

jvieille commented
Status: Active » Needs review

(updated)
I propose to solve it this way :

In mimemail.inc, function mimemail_headers()

  foreach ($headers as $key => $value) {
+    if (($key !== 'From') and ($key !== 'Sender')){
       $headers[$key] = mime_header_encode($value);
+    }
  }
  return $headers;
harryster’s picture

harryster commented

Thanks, #1 this works. Such a basic issue, I wonder how it slipped through!

zionduc’s picture

zionduc commented
Version: 6.x-1.1 » 6.x-1.x-dev
Issue summary: View changes
StatusFileSize
new mimemail-sender_is_double_encoded-1908318-3.patch553 bytes

I had the same problem with 7.x-1.0-beta3 version too but #1 solve it for me too.
Here is the patch for 6.x-1.x-dev

zionduc’s picture

zionduc commented
Version: 6.x-1.x-dev » 7.x-1.x-dev
StatusFileSize
new mimemail-sender_is_double_encoded-1908318-4.patch553 bytes

And here is the patch for 7.x-1.x-dev

sgabe’s picture

sgabe commented
StatusFileSize
new mimemail-1908318-5.patch807 bytes

We may also remove the mime_header_encode() call in mimemail_address(). Let me know if this works for you.

sgabe’s picture

sgabe commented

@bisonbleu, please test again the attached patch in #5, that should be the solution. Note that you must clear the cache. Just to be sure would be better to create a new rule for testing.

bisonbleu’s picture

bisonbleu commented

I should apply patch in #5 ALONE i.e. without patch #4?

Thanks for helping me through @sgabe!

sgabe’s picture

sgabe commented

@bisonbleu, you understood me correctly, just alone the patch in #5 should be enough to solve the problem, since mimemail_address() is the one that gets called multiple times.

bisonbleu’s picture

bisonbleu commented

I just tested patch #5 on its own (without patch #4) on a fresh mimemail-7.x-1.0-beta3 and it doesn't fix this issue. I did clear the caches after the patch was applied (drush cc all). Here's what I see in the Mail delivery failed message.

To: "Véloce" <bisonbleu@somedomain.com>
Subject: =?UTF-8?B?Q29tbWFuZGUgMTI0IHN1ciBsZSBzaXRlIGRlIGxhIENhbWJyZSBkZSBDb21tZXI=?=  =?UTF-8?B?Y2UgQ2FuYWRvLVN1aXNzZSAoUXXDqWJlYykgaW5jLg==?=
MIME-Version:1.0
Content-Type:multipart/mixed;
boundary="bc0b87109467288ac17f0f211aeb1724a0a1c3821"
Content-Transfer-Encoding:8Bit
X-Mailer:Drupal
From:=?UTF-8?B?IlN3aXNzIENhbmFkaWFuIENoYW1iZXIgb2YgQ29tbWVyY2UgKFF1w6liZWMpIEk=?=
=?UTF-8?B?bmMuIiA8YWRtaW5AcmVuYXVkam91YmVydC5jb20+?=
Message-Id: <E1XheRn-0000GZ-Aw@s3-somecity.accountservergroup.com>
Date: Fri, 24 Oct 2014 08:58:27 -0400

Tested patch #5 on a fresh mimemail-7.x-1.x-dev and it also doesn't work. I cleared the caches after applying the patch. Here's what I see in the Mail delivery failed message.

To: "Véloce" <bisonbleu@somedomain.com>
Subject: =?UTF-8?B?Q29tbWFuZGUgMTI2IHN1ciBsZSBzaXRlIGRlIGxhIENhbWJyZSBkZSBDb21tZXI=?=  =?UTF-8?B?Y2UgQ2FuYWRvLVN1aXNzZSAoUXXDqWJlYykgaW5jLg==?=
MIME-Version:1.0
Content-Type:multipart/mixed;
boundary="02dd7fb478a335972e359138066da1a3d440e4391"
Content-Transfer-Encoding:8Bit
X-Mailer:Drupal
From:=?UTF-8?B?IlN3aXNzIENhbmFkaWFuIENoYW1iZXIgb2YgQ29tbWVyY2UgKFF1w6liZWMpIEk=?=
=?UTF-8?B?bmMuIiA8YWRtaW5AcmVuYXVkam91YmVydC5jb20+?=
Message-Id: <E1Xhedj-0002nm-3G@s3-somecity.accountservergroup.com>
Date: Fri, 24 Oct 2014 09:10:47 -0400

Reverting to mimemail-7.x-1.0-beta3 + patch #4 because it works.

sgabe’s picture

sgabe commented

That is strange since with the patch in #5 the From header is correctly encoded only once. There has to be another issue. I guess your working test messages contain From\Sender field without encoding.?

bisonbleu’s picture

bisonbleu commented

Correct me if I'm wrong but in #9, the From header is double encoded in both cases. It looks like this (note the absence of any email)

From:=?UTF-8?B?IlN3aXNzIENhbmFkaWFuIENoYW1iZXIgb2YgQ29tbWVyY2UgKFF1w6liZWMpIEk=?=
=?UTF-8?B?bmMuIiA8YWRtaW5AcmVuYXVkam91YmVydC5jb20+?=

while it looks as follows when it is successful:

From:"=?UTF-8?B?U3dpc3MgQ2FuYWRpYW4gQ2hhbWJlciBvZiBDb21tZXJjZSAoUXXDqWJlYykgSW4=?=
 =?UTF-8?B?Yy4=?=" <admin@adifferentdomain.com>

  • sgabe committed b452423 on 7.x-1.x authored by jvieille 
    #1908318 by jvieille, zionduc, bisonbleu | anrkaid: Sender is double...
sgabe’s picture

sgabe commented
Status: Needs review » Fixed

What you are seeing is that mimemail_address() only encodes the name while mimemail_headers() encodes both the name and the address in one step.

According to RFC 2047 the problem is that the address cannot be encoded:

An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec'.

Patch in #4 is committed, thanks everyone!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.