Kiritoo Опубликовано 11 марта, 2016 Поделиться Опубликовано 11 марта, 2016 После переноса форума на другой VPS перестали приходить письма с подтверждением регистрации пользователям которые используют почту mail.ru В журнале ошибок email ошибок нет. Подскажите где проблема? Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
ArcheR_AWG Опубликовано 11 марта, 2016 Поделиться Опубликовано 11 марта, 2016 Мной было замечено что на mail письма приходили с задержкой. от 5 минут до нескольких часов. отправьте тестовое письмо на майл. если не придёт, (а на другие сервисы приходит) то нужно ковырять в сторону хостера ps незабудьте проверить папку "Спам" может и туда придти Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
MIXOH Опубликовано 11 марта, 2016 Поделиться Опубликовано 11 марта, 2016 Kiritoo, ArcheR_AWG, возможно при смене хоста, проблема долгого прохождения в срабатывании grayslisting-а, а возможно проблема в том, что стандартные письма из IPS немного "хромают" в плане соответствия фильтрам spamasassin-а. В частности, если говорить о методе отправки через PHP это проявляется в излишнем кодировании заголовков, а при методе отправки через SMTP к этому еще и добавляется отсутствие правильного заголовка message_id. Эти пару мелких проблем, наряду с возможно кривой настройкой почты на хостинге или VPS могут приводить к превышению порога спам-фильтров. Я недавно состряпал простенький плагин, для решения по-крайней мере этих двух проблем, попробуйте, мождет и вам поможет. У меня, при правильно настренных МХ-записях + настроенном DKIM + SPF это дало снижение spamscore с 6-8 пунктов, до 0,8. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
cepbep Опубликовано 11 марта, 2016 Поделиться Опубликовано 11 марта, 2016 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 на отличную от текущей, после чего вернуть прежнюю версию. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
Respected Опубликовано 11 марта, 2016 Поделиться Опубликовано 11 марта, 2016 MIXOH, что мешает прикрепить плагин? Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
soka Опубликовано 13 марта, 2016 Поделиться Опубликовано 13 марта, 2016 В 11.03.2016 в 21:08, MIXOH сказал: говорить о методе отправки через PHP это проявляется в излишнем кодировании заголовков Нет никакого излишнего кодирования заголовков. Согласно RFC, символы из не диапазона ASCII должны кодироваться. Отсутствия кодирования в заголовке From как минимум приведет к крокозябрам в поле отправителя, а в худшем случае может нарушить структуру заголовка. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
MIXOH Опубликовано 13 марта, 2016 Поделиться Опубликовано 13 марта, 2016 soka, это вы Spamasassin-у докажите. 2 часа назад, soka сказал: Нет никакого излишнего кодирования заголовков. Согласно RFC, символы из не диапазона ASCII должны кодироваться Излишнее кодирование, как раз и заключается в том, что заголовок в дипазоне ASCII дополнительно кодируется Base64, при том что этого не требуется. То есть если совсем по хорошему, то перед тем как кодировать заголовок, нужно проверять содержит ли он символы не ASCII. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
Kiritoo Опубликовано 13 марта, 2016 Автор Поделиться Опубликовано 13 марта, 2016 Проблема решена можно закрывать. Я написал своему хостеру. Он сказал, что у ваш домен попал в спам фильтр (по какой причине я не знаю). Он мне скинул код ошибки. В этом коде ошибки есть ссылка на техподдержку mail, я написал им туда и все заработало. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
soka Опубликовано 14 марта, 2016 Поделиться Опубликовано 14 марта, 2016 В 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% пользователей русского пространство название форума содержит кириллицу. Изменение в этом случае не только бесполезное, но еще и вредное, тем более что вы советуете его и другим пользователям. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
MIXOH Опубликовано 14 марта, 2016 Поделиться Опубликовано 14 марта, 2016 18 минут назад, soka сказал: Пишите тогда багрепорт разработчикам Нет ни возможности ни желания ни необходимости. 19 минут назад, soka сказал: У вменяемых сервисов с этим проблем нету. Ну я бы не назвал тот же gmail уж слишком невменяемым 20 минут назад, soka сказал: Изменение в этом случае не только бесполезное, но еще и вредное, тем более что вы советуете его и другим пользователям Все опционально, так что если есть необходимость, включаем, нет, то и нет. Даже по-умолчанию все выключено. Да и с чего вы взяли что я что-то советую пользователям? Не более чем попробовать при наличии проблем именно с этими настройками, не более! Не думаю что топикстартер это все. 27 минут назад, soka сказал: в данном случае работает правило "принудительного кодирования", Нет таких правил, это не более чем очередная ваша неверная трактовка RFC Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
soka Опубликовано 14 марта, 2016 Поделиться Опубликовано 14 марта, 2016 1 час назад, MIXOH сказал: Нет таких правил, это не более чем очередная ваша неверная трактовка RFC Это не трактовка RFC, и никаких "моих" я не давал, это аналог "принудительного приведения типа". 1 час назад, MIXOH сказал: Все опционально, так что если есть необходимость, включаем, нет, то и нет. В нее нет необходимости потому что она как минимум бесполезна. Это не более чем ваша очередная фантазия на тему, что имеет значение закодированная строка в заголовке "чистый" ASCII или utf-8. Кстати, а тесты проводились на двух закодированных строк в разных кодировках? Может быть фильтр был настроен таким образом, чтобы он просто срабатывал на кодированную строку в From. Spamassassin это ПО с набором правил, его результат во многом зависит от того, каким образом он был настроен и сколько "баллов" указанно для того или иного правило. Что действительно реально играет роль для спамфильтра это подписи DKIM и SPF. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
MIXOH Опубликовано 14 марта, 2016 Поделиться Опубликовано 14 марта, 2016 С такими "железными" аргументами, увы не вижу смысла в дальнейшем споре Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
soka Опубликовано 31 марта, 2016 Поделиться Опубликовано 31 марта, 2016 (изменено) 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}>"; Изменено 31 марта, 2016 пользователем soka Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
Рекомендуемые сообщения
Присоединяйтесь к обсуждению
Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Примечание: Ваш пост будет проверен модератором, прежде чем станет видимым.