Notice: Undefined index: charset in SmtpMailSystem->mail()

Probably a duplicate of #1330714: Character encoding conflict between Drupal and phpmailer., where there is a better fix. Closing for now ...

instead of line 165, what need to be fix as the error below:
Notice: Undefined offset: 1 in SmtpMailSystem->mail() (line 125 of /var/www/drupal/sites/all/modules/smtp/smtp.mail.inc).
Notice: Undefined offset: 1 in SmtpMailSystem->mail() (line 125 of /var/www/drupal/sites/all/modules/smtp/smtp.mail.inc).
Unable to send e-mail. Contact the site administrator if the problem persists.

anyone?

I was getting this when sending an email using rules and smtp
your patch fixed it. Thanks.

Latest version:

Undefined index: charset in SmtpMailSystem->mail() (line 165 of /var/www/mysitename/sites/all/modules/smtp/smtp.mail.inc).

so the problem is still happening even though the other topic claims to have solved the character issue.
The problem only happens when using mimemail. When using htmlmail, the problem does not appear. However, mimemail is by far the most used way to send html mails, so a fix would be appreciated.

The following:

$charset = $vars['charset'];
if ($charset) {
  $mailer->CharSet = $charset;
}

should become:

if (!empty($vars['charset'])) {
            $mailer->CharSet = $vars['charset'];
}

It worked perfect. I wonder what makes this modification to work

What makes it work?

This module assumes that a content-type always specifies a charset... which is the case in a simple say plain-text email w/o attachment e.g.:

Content-Type: text/plain; charset = "utf-8"

However, multipart emails such as for example HTML emails with plain-text alternative have charset embedded in the content-type of the multi-part sections and not necessarily always in the content-type of the email itself e.g.:

Content-Type: multipart/alternative;
...
Content-Type: text/plain; charset = "utf-8"
Content-Transfer-Encoding: 8Bit
...
Content-Type: text/html; charset = "utf-8"
Content-Transfer-Encoding: 8Bit

The better approach is for this module to look for, but not assume that charset is set on the content-type of the email. So the patch resolves this nicely and IMO should be implemented in the module if at the very least it is more defensive coding.

Found a problem with the patch. In the case of a HTML email with plain-text alternative the patch yields:

Content-Type: multipart/alternative;
...
Content-Type: text/plain; charset = "iso-8859-1"
Content-Transfer-Encoding: 8Bit
...
Content-Type: text/html; charset = "iso-8859-1"
Content-Transfer-Encoding: 8Bit

Which I presume is some system wide PHP default or something. In any event, if the charset is not specified directly in the email Content-Type I would think its best to simply assume that it is UTF-8 vs. doing nothing otherwise things like HTML entities e.g. © will not render properly not to mention other content.

So I propose that the code be altered to as follows:

          if (isset($vars['charset'])) {
            $mailer->CharSet = $vars['charset'];
          }
          else {
            $mailer->CharSet = 'utf-8';	          
          }

Content-Type: multipart/alternative;
...
Content-Type: text/plain; charset = "utf-8"
Content-Transfer-Encoding: 8Bit
...
Content-Type: text/html; charset = "utf-8"
Content-Transfer-Encoding: 8Bit

So this altered code accomplishes what the author intended with the patch AND provides a much better default IMHO than setting no charset at all or forcing someone to try to change some system wide PHP setting or something.

Here there is a patch that works for me http://drupal.org/node/1330714#comment-5232856

Is this still a problem in 7.x-1.0-beta2?

It seemed that the patch from #1330714: Character encoding conflict between Drupal and phpmailer. had been commited already ...

Best,

Fabian

I can confirm this has been fixed in beta2