Sends non-English mails with garbled characters (uses iso-8859-1 instead of utf-8)
bbirtle - May 18, 2009 - 10:14
| Project: | SMTP Authentication Support |
| Version: | 6.x-1.0-beta3 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | franz |
| Status: | fixed |
Description
This seems to have been reported and fixed in the 5.x release, but still existed in the 6.x version that I am using.
It can be fixed by changing line 59 of class.php.mailer.php to:
public $CharSet = 'utf-8';But I am not sure if that breaks anything else?
Nice module by the way and thanks to the authors for contributing! In today's world of spam filters and SPF records, it's a disaster for mails not to originate from the designated SMTP handler for the domain (in our case Gmail). This should be part of the next Drupal core release.
#1
What mail modules are you using? This module sets the CharSet value if a content-type is specified. Otherwise, it leaves it alone.
#2
Same problem here while sending html invoices from ubercart.
I'm not sure if this is an ubercart issue but in smtp.module (v 1.17.2.8) it sets $mail->CharSet only when Content-Type is text/plain.
As a quick fix i applied the attached patch.
#3
Maybe I should just pull that code out to the same level as the other headers I'm processing. I don't even remember now why I put it where I did.
#4
I just wrote the exact same patch as #2 - mental note, search the issue queue first :)
Plus one to comment#2 though.
#5
There are 2 problems which I tried to address on my patch:
1) The 'charset=utf-8' might not end with a ';' (my case)
To solve this, I took utf-8 as a default charset, since it is default on Drupal, so in both cases where the substring is not parsed or the charset is not really set, then the charset should fallback to utf-8
2) the other content-types (my case: multipart/alternative) may also need the charset.
To solve this, I changed the position of the if/else clause to outside the switch statement (after it), so it will affect all content-types. I'm not sure if this is right, please, can someone check?
Now I'm quite unsure about all of this, because I applied some patch for smtp to work with mimemail, so I diffed only the relevant part.
#6
Any news?
#7
Please, ignore this comment.
#8
Did a better fix of this now. I took back my assumption of default charsets, since there could be a charset which was not adequately parsed and there could intentionally not be a charset at all, so the former patch was quite invasive.
I reformulated the parsing of variables on the "Content-type" header, and it's also faster on string handling, and now correctly detects the charset.
Please try the dev (after next midnight).