When sending a newsletter with a from name that includes German umlauts (ö, ä, ü, ß, ...), the sender name is MIME-encoded twice.
The problem is this line in simplenews.mail.inc:
// Windows based PHP systems don't accept formatted emails.
$formatted_address = drupal_substr(PHP_OS, 0, 3) == 'WIN' ? $address : '"' . mime_header_encode($name) . '" <' . $address . '>';
Sender name is MIME-encoded here once and then passed to the Mime Mail module later on, if you send HTML emails with Simplenews. Mime Mail module, however, also MIME-encodes the from name, so it gets encoded twice. The result is a broken from name in newsletters.
For me, removing the call of mime_header_encode() solved the problem. But I don't know if this still works, if you use Simplenews without Mime Mail module.
Also see http://drupal.org/node/1209018 for this problem.
Comment | File | Size | Author |
---|---|---|---|
#34 | fix_formatted_fromaddress-1387648-34.patch | 746 bytes | anrikun |
#30 | fix_formatted_fromaddress-1387648-30.patch | 802 bytes | anrikun |
#28 | fix_formatted_fromaddress-1387648-28.patch | 1.97 KB | anrikun |
#26 | fix_formatted_fromaddress-1387648-26.patch | 1.97 KB | anrikun |
#23 | fix_formatted_fromaddress-1387648-23.patch | 1.83 KB | anrikun |
Comments
Comment #1
Berdir#1209018: From: in headers not properly encoded confirms that core does encode headers, so we are doing it wrong.
Moving to 7.x-1.x to get fixed there first.
Comment #2
BerdirOk, attached is a patch that removes the mime encoding and also adds a simple test for this that simply makes sure that the from address isn't encoded.
Comment #3
BerdirCommited, needs to be backported to 6.x-2.x
Comment #4
Simon Georges CreditAttribution: Simon Georges commentedFixed on 6.x-2.x too. Thanks!
Comment #5
caktux CreditAttribution: caktux commentedStill seeing this issue using Mime Mail, which seems to encode the whole sender instead of just the name...
Comment #6
Simon Georges CreditAttribution: Simon Georges commentedAre you using the last 6.x-2.x version?
Comment #7
BerdirYes mimemail is encoding the whole header string.
There is nothing we can do, we actually don't do any encoding anymore at all.
You need to report that to mimemail.
Comment #8
vitovt CreditAttribution: vitovt commentedI have the same problems with simplenews -alpha3
Sender: =?UTF-8?B?ItCd0LDRgNC+0LTQvdC40Lkg0J7Qs9C70Y/QtNCw0YciIDxuZXdzQHNkLm9yZy4=?=
=?UTF-8?B?dWE+?=
From: =?UTF-8?B?ItCd0LDRgNC+0LTQvdC40Lkg0J7Qs9C70Y/QtNCw0YciIDxuZXdzQHNkLm9yZy4=?=
=?UTF-8?B?dWE+?=
It happens only when I use non-ascii symbols in
/admin/content/simplenews/types/edit/2 --> Sender information --> From name:
When I write there only ASCII - it is ok.
I've tried disable mimamail - it didn't help. Only Sender field became OK, but From still has problem.
Comment #9
lucuhb CreditAttribution: lucuhb commentedI got this problem too when a non ASCII character was in the sender of a newsletter.
The problem seems to be solved when I put, in the from name of the sender information, the name directly encoded in base 64 , added with the part
=?UTF-8?B?
before and?=
after this encoded words.For exemple, if the sender of the email that should appear is "Université", that is
=?UTF-8?B?VW5pdmVyc2l0w6k=?=
what must indicate in the settings of the newsletter.Comment #10
BerdirWhat module are you using the send mails?
Based on what we have seen do Drupal core and Mime Mail automatically mime encode all headers. You are *not* supposed to have to do that yourself.
We need to follow the model that is given by core to prevent double encoding, if another module is not doing the encoding then that is IMHO a bug in that module and you might want to report that.
Comment #11
lucuhb CreditAttribution: lucuhb commentedI use mimemail with simplenews, and of course it is not a real solution I give in my post.
In fact the problem I try to solve is that our postfix server don't recognize the email address and adds @localdomain.local after the sender informations.
It seems that it is because in Sender and From of the headers, not only the name of the sender is encoded, but also the email address is encoded, and so not understandable.
Perhaps it was possible to encode only the name of the sender but not the email address ?
I made a test to compare with webform module, with a same sender (name = Université and email address toto@titi.fr".
When a email was send when I use the webform module, I have :
[Sender] => "=?UTF-8?B?VW5pdmVyc2l0w6k=?=" <toto@titi.fr>\n [From] => "=?UTF-8?B?VW5pdmVyc2l0w6k=?=" <toto@titi.fr>\n
in headers, and no problem with postfix.
But with simplenews, I have something like :
[Sender] => =?UTF-8?B?IlVuaXZlcnNpdMOpIiA8dG90b0B0aXRpLmZyPg==?=\n [From] => =?UTF-8?B?IlVuaXZlcnNpdMOpIiA8dG90b0B0aXRpLmZyPg==?=\n
Here you see that the words
Université <toto@titi.fr>
are all encoded.Comment #12
BerdirYes, that is in fact what we did before. The problem is that both core and mime mail unconditionally encode all headers so we had to remove that to prevent the mentioned double encoding. See http://api.drupal.org/api/drupal/modules!system!system.mail.inc/function...
I am not sure what the best solution is but it's not something that we can fix in this module. I think we need to fix core and mimemail to treat the From and similar headers like Return-Path differently and don't encode everything. Or at least prevent double-encoding so we can encode it again ourself.
Maybe you can check if there are existing related issues in Mimemail/Core and link them here so that we can further discuss this in these issues.
Comment #13
BerdirLooking at http://api.drupalhelp.net/api/mimemail/mimemail.inc/function/mimemail_ad..., that's maybe not actually the case for mime mail, it seems to support partial encoding but we need to pass in an array. I will need to discuss this with the maintainer of that module.
Comment #14
lucuhb CreditAttribution: lucuhb commentedHere is a patch that solves my problem.
This patch seems correct?
Comment #15
BerdirThe problem is that Drupal core and probably all other mail send modules expect a string and not an array. So while that works for Mime Mail, it will fail pretty hard without it :)
So one way would be to add some module_exists() checks and pass different data in but especially in Drupal 7, you don't know which mail system will actually be used, you might also have something like mail log installed to prevent mails from being sent on development sites, which would then fail again.
Something that might work is if we could set the name/address array keys within $params and mime_mail would check there first. But that's something that I need to discuss with the mime mail maintainer.
Comment #16
lucuhb CreditAttribution: lucuhb commentedOK.
So it is perhaps better that I add, as this was before, the call to mime_header_encode in the _simplenews_set_from function (see #1209018: From: in headers not properly encoded ).
It is strange that the call to mime_header_encode function had to be removed since this function only encode strings that contain non-ASCII characters, so a from already encoded should not be re-encoded, no?
Comment #17
mducharme CreditAttribution: mducharme commented#2: no_mime_encoding.patch queued for re-testing.
Comment #19
anrikun CreditAttribution: anrikun commentedLet's fix this in 7.x first.
Comment #20
anrikun CreditAttribution: anrikun commentedThis patch fixed the issue for me.
And it seems to work whether Mime Mail is used or not.
Comment #22
anrikun CreditAttribution: anrikun commentedThis test fails:
But is this itseft correct?
System encodes headers but here, we need to encode the name itself, not the
'" <' . $edit_category['from_address'] . '>'
part.After this, any further call to mime_header_encode will ignore this header because there is no non-ASCII char left.
I guess the test itself is wrong here.
Comment #23
anrikun CreditAttribution: anrikun commentedHere is an updated patch that fixes test too.
Comment #24
anrikun CreditAttribution: anrikun commentedComment #25
BerdirNot necessarly. The test was added as part of the removal of mime_encode_header() and might be wrong.
We had issues with double encoded from names, are you sure that this doesn't happen with your patch?
It's not trivial to test, not sure what the best way is. What we could try is to call mime_encode_header() again in the test and make sure it's not encoded twice or something like that.
Comment #26
anrikun CreditAttribution: anrikun commentedOk let's try this (added an extra test to ensure there won't be twice encoding, as you suggested).
Comment #27
BerdirThe result is the same, but logically, it would make more sense to me to the encoding on $mail['from'] and then compare it with what we expect it to be instead of the other way round.
Have you tested this with Mimemail? If it works correctly there as well, then I guess I messed up :)
Comment #28
anrikun CreditAttribution: anrikun commented@Berdir: thank you for your feedback.
Yes you're right, even if the result is the same, it's more logical to do it the second way.
Here is an updated patch.
Yes, I confirm it works as expected with Mime Mail: I use it on my site!
Comment #29
BerdirOk, great, thanks, commited and pushed. Back to 6.x-2.x
Comment #30
anrikun CreditAttribution: anrikun commentedI have just found another place where From was not properly encoded.
Here is a patch to fix it too (tested live).
Comment #31
andrenoronha CreditAttribution: andrenoronha commentedI dont know if here is the right place for this, but the email sent by simplenews shows the sender name as
"\"Name of my site\"
How to get rid of those "\" ?
I'm using Simplenews 7.x-1.0-beta2 after update from drupal 6.
Is this corrected in the last dev version from may 5?
Thanks
Comment #32
BerdirThanks, commited.
Comment #33
andrenoronha CreditAttribution: andrenoronha commentedI noticed that my problem in #31 was due to the 'ú' caracter of my site's name.
I tried 'ú' but it didn't work.
What code could I use to print an 'ú' in the 'From' field of the email?
Comment #34
anrikun CreditAttribution: anrikun commentedHere is the patch for 6.x-2.x
Comment #35
perk11 CreditAttribution: perk11 commentedThis patch worked for me, please commit it to the release
Comment #36
BerdirCommited to 6.x-2.x and 6.x-1.x
Comment #38
GaëlGIf these patches are not enough to solve the bug, try using this one too (both at the same time): https://www.drupal.org/node/300387#comment-985929