После переноса форума на другой VPS перестали приходить письма с подтверждением регистрации пользователям которые используют почту mail.ru

В журнале ошибок email ошибок нет. 

Подскажите где проблема?

Мной было замечено что на mail письма приходили с задержкой. от 5 минут до нескольких часов. 

отправьте тестовое письмо на майл.

если не придёт, (а на другие сервисы приходит) то нужно ковырять в сторону хостера

 

ps незабудьте проверить папку "Спам" может и туда придти

Kiritoo, ArcheR_AWG, возможно при смене хоста, проблема долгого прохождения в срабатывании grayslisting-а, а возможно проблема в том, что стандартные письма из IPS немного "хромают" в плане соответствия фильтрам spamasassin-а. В частности, если говорить о методе отправки через PHP это проявляется в излишнем кодировании заголовков, а при методе отправки через SMTP к этому еще и добавляется отсутствие правильного заголовка message_id. Эти пару мелких проблем, наряду с возможно кривой настройкой почты на хостинге или VPS могут приводить к превышению порога спам-фильтров. Я недавно состряпал простенький плагин, для решения по-крайней мере этих двух проблем, попробуйте, мождет и вам поможет. У меня, при правильно настренных МХ-записях + настроенном DKIM + SPF это дало снижение spamscore с 6-8 пунктов, до 0,8.

 

3 часа назад, Kiritoo сказал:

После переноса форума на другой VPS перестали приходить письма с подтверждением регистрации пользователям которые используют почту mail.ru

В журнале ошибок email ошибок нет. 

Подскажите где проблема?

Похожая проблема была с ИПБ - напишите в техноддержку хостинга. Решение моей проблемы ниже:

=========================

На форуме, размещенном на домене ..... перестали отправляться письма (подтверждения о регистрации).
Тест отправки почты показывает "невозможно отправить письмо". Это очень негативно сказывается на регистрациях и посещаемости. Как это можно исправить?
Проблеме около месяца, никаких обновлений форума не ставил, настройки не менял.

===========================

Отдел технической поддержки хостинга 22 февраля 2016 21:12

 

Здравствуйте!

Насколько мы видим, в локальном php.ini отсутствует директива sendmail_path. Вам необходимо прописать следующую строку в php.ini:
sendmail_path = "/usr/sbin/sendmail -t -i -f [email protected]"

В данной строке вместо «[email protected]» укажите существующий почтовый ящик, желательно не относящийся к доменам mail.ru, inbox.ru, list.ru, bk.ru.

Отправляем вам пошаговую инструкцию по изменению параметров PHP: https://www.reg.ru/support/hosting-i-servery/hosting-sajtov/yazyki-programmirovaniya-i-skripty/kak-izmenit-parametry-php

Обратите внимание, чтобы изменения вступили в силу, необходимо, чтобы web-сервер перечитал php.ini.
Самый простой способ — это сменить версию PHP на отличную от текущей, после чего вернуть прежнюю версию.

MIXOH, что мешает прикрепить плагин?

В 11.03.2016 в 21:08, MIXOH сказал:

говорить о методе отправки через PHP это проявляется в излишнем кодировании заголовков

Нет никакого излишнего кодирования заголовков. Согласно RFC, символы из не диапазона ASCII должны кодироваться. Отсутствия кодирования в заголовке From как минимум приведет к крокозябрам в поле отправителя, а в худшем случае может нарушить структуру заголовка. 

soka, это вы Spamasassin-у докажите.

2 часа назад, soka сказал:

Нет никакого излишнего кодирования заголовков. Согласно RFC, символы из не диапазона ASCII должны кодироваться

Излишнее кодирование, как раз и заключается в том, что заголовок в дипазоне ASCII дополнительно кодируется Base64, при том что этого не требуется. То есть если совсем по хорошему, то перед тем как кодировать заголовок, нужно проверять содержит ли он символы не ASCII.

Проблема решена можно закрывать. 
Я написал своему хостеру. Он сказал, что у ваш домен попал в спам фильтр (по какой причине я не знаю). Он мне скинул код ошибки. В этом коде ошибки есть ссылка на техподдержку mail, я написал им туда и все заработало.

В 13.03.2016 в 17:23, MIXOH сказал:

это вы Spamasassin-у докажите.

В 13.03.2016 в 14:42, soka сказал:

Пишите тогда багрепорт разработчикам. У вменяемых сервисов с этим проблем нету.

 

В 13.03.2016 в 17:23, MIXOH сказал:

Излишнее кодирование, как раз и заключается в том, что заголовок в дипазоне ASCII дополнительно кодируется Base64, при том что этого не требуется. То есть если совсем по хорошему, то перед тем как кодировать заголовок, нужно проверять содержит ли он символы не ASCII.

По хорошему возможно и надо было, хотя лично я считаю что это не обязательно - в данном случае работает правило "принудительного кодирования", но у вас также никакой проверки нету, а вот не закодированной заголовок в utf-8 действительно является ошибкой которая может доставить неприятности, учитывая то, что у 90% пользователей русского пространство название форума содержит кириллицу. Изменение в этом случае не только бесполезное, но еще и вредное, тем более что вы советуете его и другим пользователям. 

18 минут назад, soka сказал:

Пишите тогда багрепорт разработчикам

Нет ни возможности ни желания ни необходимости.

19 минут назад, soka сказал:

У вменяемых сервисов с этим проблем нету.

Ну я бы не назвал тот же gmail уж слишком невменяемым

20 минут назад, soka сказал:

Изменение в этом случае не только бесполезное, но еще и вредное, тем более что вы советуете его и другим пользователям

Все опционально, так что если есть необходимость, включаем, нет, то и нет. Даже по-умолчанию все выключено. Да и с чего вы взяли что я что-то советую пользователям? Не более чем попробовать при наличии проблем именно с этими настройками, не более! Не думаю что топикстартер это все.

27 минут назад, soka сказал:

в данном случае работает правило "принудительного кодирования",

Нет таких правил, это не более чем очередная ваша неверная трактовка RFC

1 час назад, MIXOH сказал:

Нет таких правил, это не более чем очередная ваша неверная трактовка RFC

Это не трактовка RFC, и никаких "моих" я не давал, это аналог "принудительного приведения типа".

 

1 час назад, MIXOH сказал:

Все опционально, так что если есть необходимость, включаем, нет, то и нет.

В нее нет необходимости потому что она как минимум бесполезна. Это не более чем ваша очередная фантазия на тему, что имеет значение закодированная строка в заголовке "чистый" ASCII или utf-8. Кстати, а тесты проводились на двух закодированных строк в разных кодировках? Может быть фильтр был настроен таким образом, чтобы он просто срабатывал на кодированную строку в From. Spamassassin это ПО с набором правил, его результат во многом зависит от того, каким образом он был настроен и сколько "баллов" указанно для того или иного правило. Что действительно реально играет роль для спамфильтра это подписи DKIM и SPF. 

С такими "железными" аргументами, увы не вижу смысла в дальнейшем споре 

https://en.wikipedia.org/wiki/Unicode_and_email#Unicode_support_in_message_header

Кодирование заголовка трогать нельзя. Настройка которая носит в себе потенциальный баг не должна быть ни опционально, ни в отключенном виде по умолчанию. Если хочется угодить spamassasin'у с его непонятной логикой в правиле "FROM EXCESS BASE64" используйте условие на "non-ASCII" символы, которое, кстати, в этом же месте используется чуть ниже с помощью регулярного выражение. Из функций можно использовать mb_check_encoding.

$this->headers['From']		= ( $this->fromName ) ? ( !mb_check_encoding( $this->fromName, 'ASCII' ) ? '=?UTF-8?B?' . base64_encode( $this->fromName ) . "?= <{$this->from}>" : $this->fromName . " <{$this->from}>" ) : "<{$this->from}>";

Но в php есть специальная функция для кодирования email заголовка в случае если он не соответствует требованиям RFC. Она тоже используется в коде для кодирования заголовков, поэтому не понятно почему IPS заговнокодили здесь ручным кодированием.

$this->headers['From']		= ( $this->fromName ) ? ( mb_encode_mimeheader( $this->fromName ) . " <{$this->from}>" ) : "<{$this->from}>";

 

Edited 31 марта, 20168 yr by soka