Posted by bbirtle on May 18, 2009 at 10:14am
| Project: | SMTP Authentication Support |
| Version: | 6.x-1.0-beta3 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | franz |
| Status: | closed (fixed) |
Issue Summary
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.
Comments
#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).
#9
Automatically closed -- issue fixed for 2 weeks with no activity.
#10
sorry to reopen this
looks like it wasnt fixed
I am still getting the same problem
I could be missing the right code,
however,
I looked at revision 6.x-1.0-beta4 in which this bug was fixed and could not find the code that fixed the issue
Is the fix for this issue missing from the code?
My module mailing chain is as follows:
webform --> mimemail --> smtp
and i am sending a mixed HTML and attachment mails
A simple (and ugly!) hack such a forcing it in
smtp_drupal_mail_wrapper()so that<?php$mail->CharSet = 'UTF-8'
?>
would resolve it
obviously, such hacks are not welcome
it seems like the right way to resolve this would be setting the default charset in class.phpmailer.php
however,
since this code is not under Drupal maintenance, i think that for the sake of code standardization it is better to set the default charset in the SMTP module
In any case i opened
https://sourceforge.net/tracker/?func=detail&aid=3321761&group_id=26031&...
Is there a reason why not to use the default charset as 'UTF-8'?
Avner