php, again about encodings

Question

PHP

Hotmail sends emails to junk due to a mismatch between the encoding of the email itself (KOI8-R) and its body. Headers to, subject, from are displayed normally. Page with form in UTF-8.

  $data_charset = 'UTF-8'; // кодировка переданных данных
  $send_charset = 'KOI8-R'; // кодировка письма
  $to = mime_header_encode($name_to, $data_charset, $send_charset). ' <' . $email_to . '>';
  $subject = mime_header_encode($subject, $data_charset, $send_charset);
  $from = mime_header_encode($name_from, $data_charset, $send_charset).' <' . $email_from . '>';
  if($data_charset != $send_charset) {
    $body = iconv($data_charset, $send_charset, $body);
  }

In the source code of the letter, the cracks "ëÏÎÔÁËÔÙ" are displayed. Lebedev decoder says: CP1252 → KOI8-R.
OK. I make a replacement as suggested by Ogra :

-	$body = iconv($data_charset, $send_charset, $body);
+	$body = iconv('utf-8', 'cp1252', $body);
+	$body = iconv('cp1251', 'KOI8-R', $body);

Now the body of the message is generally empty.
And $body is lost when utf-8=>cp1252.

Email headers:

  $headers = "From: $from\r\n";
  $headers .= "Reply-To: [email protected]\r\n";
  $headers .= "Return-Path: [email protected]\r\n";
  $headers .= "X-Mailer: Drupal\n";
  $headers .= 'MIME-Version: 1.0' . "\n";
  $headers .= "Content-type: text/plain; charset=$send_charset; format=flowed\r\n";
  $headers .= "Content-Transfer-Encoding: 8bit\r\n";

Answer 1

OK. I make a replacement as suggested by Ogra:
— $body = iconv($data_charset, $send_charset, $body);
+ $body = iconv('utf-8', 'cp1252', $body);
+ $body = iconv('cp1251', 'KOI8-R', $body);
Now the body of the message is generally empty.
And $body is lost when utf-8=>cp1252.

Not surprising. You first convert the string from a larger character set encoding (utf-8) to a less extensive character set encoding (cp1252). Secondly, convert the string to cp1252 encoding, which does not contain Russian characters. Thirdly, you first convert the string to cp1252 encoding, and then for some reason you think that your string is now not in cp1252 encoding, but in cp1251 encoding, and you will already convert it back to utf-8.
In short, this recoding manipulation is not needed, and the decoder should not be trusted, because it may have a large error.

Answer 2

dkim, spf? show the headers of the letter on the hotmail. In Gmail, Yandex does not get into spam?

Answer 3

Not the fact that it will help directly, but ...
Just in case, try to normalize line feeds in headers.
You have before the heading "Content-type" the previous two lines end in a single "\n".
Because of this, the email parser may not see the “Content-type” header at all, because will consider it a continuation of the previous heading, in this case a continuation of “X-Mailer”.

Answer 4

Sometimes "utf-8" with a dash does not work, try without just "utf8". And you also have different encodings there, utf-8=>cp1251 cp1252 =>koi8-R

Answer 5

The mime_header_encode function from Drupal (which you, judging by the email headers you provided) does not have parameters that specify encodings.

Answer 6

Mailer .

Answer 7

pf=permerror (sender IP is X.X.X.X) [email protected]; dkim=none
configure spf and dkim habrahabr.ru/post/106589/

Answer 8

Mail headers written with non-ANSI characters must be written in a special way: =?кодировка?B?тело-заголовка-в-base64?=in accordance with RFC-1342. As far as I remember, an incorrect entry is poorly perceived by outlook

Answer 9

Oh, you are suffering. There is a Mandrill with a huge limit of free letters, all these problems have been solved there a hundred times. You can use both smtp and API - it's much easier to send attachments and all that. Do not waste time on solving a hundred times solved problems.

Answer 10

When converting from utf-8, there may be characters missing in the target encoding. Then the conversion stops at that character. Try running iconv with the //IGNORE option