Примеры писем:
550 5.7.1 This message was not accepted due to domain owner DMARC policy (RFC 7489) https://help.mail.ru/mail-help/postmaster/dmarc
550-5.7.1 Unauthenticated email from mail.ru is not accepted due to domain"s 550-5.7.1 DMARC policy. Please contact administrator of mail.ru domain if this 550-5.7.1 was a legitimate mail. Please visit 550-5.7.1 https://support.google.com/mail/answer/2451690 to learn about DMARC
550 5.7.1 Email rejected per DMARC policy for ...
Проблема с доставкой сообщений связана с применением новой политики DMARC , связанной с ужесточением правил прохождения спам фильтров.
DMARC — это протокол защиты от спама и от несанкционированной рассылки почты от имени домена, основанный на существующих механизмах DKIM и SPF . Официальный сайт: dmarc.org .
Если вы получаете подобные приведённым выше сообщения, скорее всего, почта с сайта у вас отправляется от имени почтового ящика на базе @mail.ru , @bk.ru , @list.ru или @inbox.ru . Mail.Ru не принимает сообщения, отправленные через phpmail, если в почтовых заголовках числится ящик, принадлежащий mail.ru. Такие сообщения, согласно внедрённой Mail.Ru политике DMARC , отклоняются.
Решить проблему можно двумя способами:
Обычно e-mail, от имени которого рассылаются почтовые сообщения, прописывается в административной части CMS. Также его можно изменить напрямую в скрипте, рассылающем сообщения (поле «From»).
Необходимо, чтобы сообщения рассылались с ящика на базе вашего доменного имени, например «[email protected]» , где domain.ru — ваш домен. .
Также, почтовый ящик необходимо изменить в файле php.ini :
Изменение ящика в php.ini
найдите строку вида:
sendmail_path = "/usr/sbin/sendmail -t -i -f [email protected]"
В данной строке вместо «[email protected]»
укажите почтовый ящик, не относящийся к доменам @mail.ru
, @bk.ru
, @list.ru
и @inbox.ru
.
Желательно указать почтовый ящик на вашем домене, например, «[email protected]»
, где domain.ru
— ваш домен.
Кроме этого, прописанный в php.ini почтовый ящик должен существовать. Если вы пользуетесь почтой на хостинге, создайте почтовый ящик на домене по и пропишите его в файле php.ini .
Вы можете рассылать сообщения от имени вашего почтового ящика на базе Mail.Ru, настроив SMTP-авторизацию. В этом случае все сообщения через ваш сайт будут отправлять напрямую с серверов Mail.Ru.
Проблема недоставки почтовых сообщений – типичная проблема, которую приходится расследовать.
Причина возникновения таких проблем в том, что состояние текущих стандартов и практик почтовых систем не позволяет гарантировать доставку сообщений или даже получить четкий комментарий о недоставке.
Более того, на различных этапах доставки сообщений присутствует большое количество ошибочно настроенных фильтров.
Обычно, к сожалению, никаких эксклюзивных мер по расследованию проблемы потери почты предпринять нельзя. Данная статья дает окончательный алгоритм действий, придерживаясь которого, вы четко поймете, где возникла проблема и как устранить её, если это возможно.
По каждому варианту дается дополнительный комментарий о том, имеет ли смысл дальнейшее расследование по проблеме или окончательное решение по проблеме можно вынести немедленно.
Пожалуйста, убедитесь, что вы точно выполняете все советы статьи .
Самое важное:
1) Обратный адрес письма должен быть зарегистрированным ящиком на нашем хостинге!
2) Массовые рассылки запрещены, по умолчанию, с сайта можно отправить до 500 писем в день.
3) Письмо должно соответствовать почтовым стандартам. Ваш скрипт самостоятельно формирует письмо и если оно получилось не очень качественным, оно будет принято нашим сервером, но его доставка не произойдет, т.к. его задержат фильтры нашей системы или у получателя.
Письмо, которое вы отправляете, не присутствует в списке сообщений.
Это значит, наш почтовой сервер не принимал письмо. Причины могут быть следующие:
Письмо присутствует в списке сообщений в очереди.
Необходимо открыть «статистика доставки почты», «SMTP доставка».
Письмо присутствует в списке SMTP доставки.
Для одного сообщения может присутствовать несколько попыток доставки. Предварительные попытки могут быть неудачными, это нормально. Необходимо найти последний блок (строку), который имеет отношение к доставке вашего сообщения.
Блок «лог доставки» оканчивается сообщением 250 OK или любым другим сообщением, которое начинается с кода 250 (кроме последней строки «Connection closed normally» - её учитывать не нужно).
Это означает, что следующий в цепочке доставки почтовый сервер принял письмо и подтвердил факт получения сообщения. Все последующие вопросы о судьбе сообщения необходимо направлять администратору этого почтового сервера. Информация из блока «лог доставки», одновременно с датой и временем, поможет администратору понять судьбу сообщения и при необходимости устранить проблему.
Блок «лог доставки» оканчивается сообщением, которое начинается кодом, отличным от 250, либо сопровождается сообщением «Processing of job XXXXXXX incomplete or failed».
Это означает, что наш почтовый сервер не смог доставить сообщение адресату. При этом вы должны получить сообщение о недоставке почтового сообщения («возврат»). Дополнительная информация доступна из лога SMTP доставки, которую вы сейчас просматриваете.
Письмо отсутствует в списке SMTP доставки. Обратитесь в службу поддержки.
Вам необходимо зайти в личный кабинет, выбрать «статистика доставки почты», «очередь сообщений» для нужного вам ящика.
ВАЖНО:
расследовать проблему такого вида можно только для сообщений, которые были доставлены в ящик непосредственно, без участия списка рассылки либо спам-фильтра. Если ваш ящик получает сообщение косвенным образом (через список рассылки), вам необходимо расследовать проблему для ящика, который является основным ящиком списка рассылки. Если включен спам-фильтр - его необходимо выключить.
Сообщение присутствует в списке.
Это означает, что сообщение было принято сервером и размещено в ваш почтовый ящик. Проблемы с получением такого письма связаны с вашей системой либо её настройками.
Сообщение отсутствует в списке.
Это означает, что наш почтовый сервер не принимал сообщение.
Расследовать данную проблему с нашей стороны нет смысла. Это представляет собой проблему нашей почтовой системы только в том случае, если есть доказательства того, что сообщение было доставлено на наш сервер. Доказательством служит кусок лога SMTP клиента отправляющего сервера (случай, зеркально аналогичный ситуации 2.2.1 выше). Если такого доказательства нет, значит, расследовать данный случай недоставки должен администратор почтового сервера отправляющей стороны.
Также можно попробовать учесть различные обстоятельства работы вашего домена, которые могут привести к тому, что доставка почты на него вообще работать не будет.
Борьба со спамом - это головная боль всех ответственных администраторов почты. Чего только они не изобретают, чтобы любимым пользователям лучше жилось. Однако, как показала практика общения со многими системными администраторами, почему-то далеко не все представляют как правильно фильтровать спам.
Чаще всего встречается подход «добавим кучу RBL (DNSBL) и будем радоваться жизни». Подход не верный чуть более, чем полностью. Второй по популярности - контент-фильтры, зачастую купленные за бешеные деньги. Такой подход тоже в большинстве случаев совершенно неоправдан.
А ведь всё так просто, для спокойной жизни достаточно всего лишь пристально присматриваться к трём заголовкам входящей SMTP сессии. Порывшись на Хабре и в закоулках интернета так и не нашёл исчерпывающей статьи на тему правильной настройки SMTP сервера с точки зрения противодействия спаму. Поэтому решил расписать всё, что знаю на эту тему сам и чем успешно пользуюсь.
Кстати: эта статья конечно ориентирована в первую очередь на администраторов, желающих сделать качественный фильтр спама. Однако с другой стороны она содержит очень важные сведения для тех, кому приходится просто работать с почтой, но кто плохо разбирается во всех тонкостях процесса электронной пересылки корреспонденции.
Итак, если вы хотите обезопасить своих пользователей от спама или наоборот, хотите чтобы кто-то случайно не обезопасил пользователей от ваших писем - добро пожаловать под кат.
Небольшая замечание: статья написана с прицелом на настройку почтового сервера Postfix
, но в целом носит скорей теоретический характер. Описанные опции Postfix нужно указывать в соответствующих *_restriction
параметрах конфигурационного файла, за подробностями обращайтесь к любому руководству по настройке Postfix.
Немного отвлечёмся: представьте, что к вам придёт лицо крайне отталкивающей наружности и вручит плотно запечатанную посылку с обратным адресом «Трям из Тилимилитрямдии». Рискнёте принять и открыть? Вряд ли. Так вот, электронную почту можно тоже легко проверять и отсеивать исходя только из адресной информации, причём простор для возможных действий тут гораздо шире.
Как вам должно быть известно, почта в интеренете передаётся между почтовыми серверами по протоколу SMTP. Любое общение по этому протоколу начинается с трёх обязательных заголовков: HELO , MAIL FROM и RCPT TO . То есть перед тем, как начать передавать какие-либо данные, сервер сначала представляется (HELO), потом сообщает обратный адрес отправителя (MAIL FROM) и затем - адрес получателя (RCPT TO). Эти три заголовка и есть подпись на электронном конверте, и практически весь спам можно отсеять только исходя из их анализа. Большинство попыток передать что-то моему серверу не доходят дальше MAIL FROM, то есть письма отсеиваются ещё до фактического принятия, что значительно снижает нагрузку. То есть вместо того, чтобы открыть посылку от Тряма и обнаружить там споры сибирской язвы, я сразу посылаю почтальона куда подальше.
Итак, что же надо делать, чтобы не принимать письма, заведомо являющиеся спамом? Пойдём по порядку.
MX записи содержат адреса серверов, на которые должны доставляться письма для указанного домена. Однако в целях борьбы со спамом появилась технология, позволяющая указывать в DNS также адреса серверов, с которых могут приходить письма от указанного домена. Имя ей - Sender Policy Framework .
Подробно вдаваться во все тонкости технологии я не буду, скажу лишь, что TXT запись
V=spf1 +mx -all
Всегда прописывайте SPF запись для домена, а так же включайте проверку SPF на своих почтовых серверах. Я рекомендую жёстко запрещать отправку писем из вашего домена со всех хостов, кроме ваших MX серверов. Вкупе с проверкой SPF на вашем сервере подобная настройка сразу срежет все письма, посылаемые со сторонних хостов от имени пользователей вашего домена на адреса пользователей вашего же домена. А такого спама чуть ли не половина, поскольку обычно SMTP серверы очень плохо защищены от писем из своего же собственного домена, и спамеры этим активно пользуются. SPF раз и навсегда избавит вас от писем Васе Пупкину, написанных судя по конверту Васей же Пупкиным, но пришедших с сервера в каком-нибудь Никарагуа.
Как настроить SPF в Postfix вам расскажет гугл, информации навалом и ошибиться нельзя, так что не будем тратить время на технический подробности.
Есть ещё пару крайне важных замечаний по поводу DNS. Скорее всего вы знаете, что основные записи DNS, так называемые A записи, преобразуют имя в IP адрес. Кроме них есть ещё CNAME записи, которые назначают псевдоним уже существующему имени. Именно эти два типа записей составляют основу всей системы доменных имён.
Но мало кто из пользователей знает, что есть так же обратные записи, которые преобразуют IP в доменное имя. Они носят название PTR. Так вот, есть два неписаных (строго говоря) правила, которым всё же все следуют:
Если вы не соблюдёте одно из этих требований - приготовьтесь к тому, что минимум четверть почты с вашего домена будет распознаваться как спам. Обусловлено это простым тезисом: благонадёжный отправитель всегда всё настраивает соблюдая правила, соответственно если правила не соблюдены - то отправителю доверять не следует, а значит и принимать от него почту - тоже.
Ну а чтобы включить проверку PTR у себя, используйте опцию
Reject_unknown_client_hostname
Она требует, чтобы IP, с которого совершается соединение, резолвился в имя через PTR, а это имя резолвилось в свою очередь обратно в искомый IP.
Есть и менее жёсткое ограничение, задаваемое опцией
Reject_unknown_reverse_client_hostname
В этом случае сервер будет проверять только наличие PTR записи, но не будет требовать существования соответствующей записи A.
Reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
Первая запрещает приём писем от хостов, передающих приветствие с некорректным синтаксисом, вторая - от хостов, передающих не FQDN в HELO запросе.
Однако не FQDN передают только самые глупые спамеры (и продукты MS, но им, как известно, законы не писаны), в конце концов представиться gmail.com не составляет труда. Поэтому надо ещё немного присмотреться к HELO. Для этого служат опция
Reject_unknown_helo_hostname
Которая запрещает приём писем от серверов, представляющихся адресом, для которого не существует A или MX записи.
Однако если в адресе отправителя указан домен, который вовсе не существует, то письмо совершенно очевидно принимать не стоит. И уж точно не стоит принимать письмо, в котором в качестве обратного адреса указано нечто, вообще адресом не являющееся. За отказ в принятии для таких писем отвечают две опции:
Reject_non_fqdn_sender
reject_unknown_sender_domain
Первая - проверка адреса на написание, вторая - проверка существования домена.
Уже неплохо, но можно сделать кое-что ещё. Можно запросить сервер, обслуживающий указанный адрес отправителя, на предмет существования на нём пользователя с этим адресом. Действительно, вроде бы неплохая идея удостовериться в том, что обратный адрес действительно существует, иначе нам вполне может придти письмо от эфемерного фантома, о котором никто и не слыхивал.
Технически это реализуется очень просто: наш сервер открывает встречную SMTP сессию, пытаясь послать письмо по адресу отправителя. Если удаётся успешно пройти этап посылки RCPT TO с этим адресом, т.е. если принимающий сервер вдруг не заявляет, что указанного ящика на нём нет, то считается, что присланный нам обратный адрес существует. Данные (то есть письмо) при проверке естественно никакие не передаются, сессия прерывается после RCPT TO.
За такую проверку обратного адреса отвечает опция
Reject_unverified_sender
Из сказанного выше следует, что для любого адреса, с которого вы рассылаете почту из своего домена, должен существовать ящик на вашем сервере. Иначе ваши письма не пройдут проверку обратного адреса на стороне получателя и соответственно не будут доставлены по назначению. Это актуально для всяких рассылок и прочей вроде как односторонней коммуникации, не требующей ответа. Всегда создавайте ящики для всех адресов, с которых вы рассылаете почту. Если вы не хотите получать ответы на какой-то адрес, то просто посылайте письма на него в /dev/null, но принимать эти письма вы обязаны .
Reject_non_fqdn_recipient
Кроме того нам бы не хотелось принимать почту на адреса, для которых у нас нет почтовых ящиков. Чтобы настроить такое поведение надо сначала создать список обслуживаемых ящиков, дальше рассказать о нём Postfix через один из *_recipient_maps параметров конфигурационного файла, ну а дальше либо воспользоваться параметром конфигурационного файла
Smtpd_reject_unlisted_recipient = yes
Либо запрещающей опцией, имеющей тот же эффект:
Reject_unlisted_recipient
В любом случае Postfix перестанет принимать письма для обслуживаемых доменов , если не существует ящика для получателя. Однако это ограничение никак не скажется на пересылке корреспонденции на адреса, которые не находятся в обслуживаемых доменах.
Ну и наконец можно вообще запретить открытую пересылку писем через ваш Postfix, оставив только возможность принимать письма на известные адреса. Для этих целей служит опция
Reject_unauth_destination
Она запрещает отсылку писем всем незарегистрированным пользователям (да, вам придётся настроить SMTP авторизацию). Всегда используйте эту опцию! Иначе быстро попадёте во всякие DNSBL.
Минусом применения является небольшая (обычно не более получаса) задержка в доставке писем при первом соединении от неизвестного хоста. То есть если ещё не известный нашему постфиксу сервер хочет передать письмо, то при первой попытке соединения ему отправляется ошибка о временной недоступности. Если сервер повторил попытку соединения - то письмо принимается, а сервер заносится в надёжные узлы и в дальнейшем письма от него принимаются без задержек.
О настройке грейлистинга в Postfix так же предлагаю прочитать в Google, это несложно и ошибиться не получится.
Для администраторов почтовых серверов:
Конечно, предложенные настройки фильтруют не весь спам. Поэтому вполне возможно вам потребуется дополнительно использовать ещё и контекстный фильтр, который будет анализировать содержание писем, например,
Ошибки почтовой системы – это коды, которые присваиваются сообщениям во время получения или отказа в получении. Код ошибки позволяет выяснить причину, по которой возникла невозможность доставки почтового сообщения. Как правило, код ошибки представляет собой число, например #550 или #2001. Описание кодов ошибок приведено ниже.
Не удалось определить сервер, на который нужно переслать почтовое сообщение. Возможные причины:
Данного почтового ящика не существует, либо почтовый адрес указан с ошибкой
Сообщение возникает при отправке писем почтовым клиентом. Это сообщение не нашей почтовой системы. Оно означает, что у пользователя в локальной сети есть антиспам или фаервол, который проверяет все отправляющиеся письма.
LMTP
error after end of data: 552 5.2.2 Over quota
Ошибка возникает, в случае если у получателя переполнен почтовый ящик.
Sender verify callout failed
Проверка отправителя письма. Ошибка может быть либо полной, как указано ниже, либо сокращённой: «Sender verify failed [#1005]».
Ошибка присылается каким-либо сервером, который осуществил неудачную попытку отправить письмо нашему серверу.
Наш сервер указан в строчке «… while talking to mx3.сайт.:».
The following addresses had permanent fatal errors -----
Адрес [email protected] – это адрес получателя письма, он приведён только ради полноты информации.
Адрес отправителя [email protected] не прошёл проверку, о чём и написано в сообщении.
Для каждого письма производится проверка отправителя. Для этого наш сервер пытается подсоединиться к серверу, принимающему почту для домена отправителя (в примере – example.com) и отправить письмо с адреса «<>» на адрес отправителя (в примере [email protected]). Такие письма всегда должны приниматься, потому что именно так выглядят сообщения о неудачных доставках. Если сервер отвечает, что такого ящика не существует (в примере сервер, обслуживающий домен example.com, ответил «550-User unknown (200)») или по другим причинам отвергает попытку, то письмо с адреса [email protected] не принимается.
Проверка обратного адреса – это не защита от спама (хотя и помогает фильтровать его часть). Сервер должен иметь возможность послать отправителю сообщение в том случае, если он не смог доставить письмо получателю. Для гарантии этой возможности проверяется обратный адрес.
В настоящем случае Вы узнали о проблеме, потому что наш сервер не принял сообщение (сигнализируя о проблемах связи с доменом отправителя), а посылающий сервер сообщил об этом отправителю. Если бы наш сервер принял сообщение, не проверяя возможность обратной доставки, Вы не узнали бы о проблеме.
Письмо с неверным обратным адресом – это проблема, которую обязательно надо решать, но ни в коем случае не отключением средства, которое сигнализирует о ней.
Sorry, we don’t accept messages from the hosts without a PTR
record
Ошибка возникает, когда у узла отправителя отсутствует PTR
-запись.
We don’t accept dynamic ip-addresses, please use your provider’s smtp [#1007]
или dynamic ip rejected [#1007]
Данная ошибка возникает у пользователей, использующих для своего подключения динамический пул адресов. Проверка осуществляется на основании IP-адреса пользователя (наличие в нём слов dial, ppp, pool, dsl, dynamic, static и другие вхождения).
Sender verify failed
В заголовке smtp-сесии mail from указан неверный обратный адрес (несуществующий домен, например).
We don’t accept dynamic ip-addresses, please use your provider’s smtp [#1009]
Данная ошибка в основном возникает у пользователей использующих DSL
или DialUp подключения и отправляющих почту со своих локальных компьютеров, иными словами не использующих SMTP
-сервер своего провайдера. Проверка осуществляется на основе регулярного выражения для :
^({1,3}\D+){2}({1,3}[^\d\.]*).*\.(\w|-)+\.\w{2,4}$
Если вы по какой-то причине не можете использовать SMTP
-сервер вашего провайдера – напишите заявку в техническую поддержку с указанием вашего ip адреса, он будет добавлен в white-list.
Mail rejected, see http://www.spamcop.net/w3m?action=checkblock&ip=IP-адрес [#1014]
Мы используем DNS
-блеклисты spamcop.net для защиты от спама. Адрес отправителя находится в блеклистах spamcop.net
Relay not permitted
Совершена попытка отправить письмо на домен, который не обслуживается нашими почтовыми серверами.
Recipient verify failed
Проверка получателя письма. Ошибка возникает, если домен обслуживается нашими серверами, но такого адреса в домене не существует.
Recipient verify callout failed
Проверка получателя письма. Ошибка возникает, если удалённый сервер отвечает, что такого получателя не существует.
You are sending too many messages
Превышен лимит по отправке писем через smtp. Для повышения лимита необходимо обратиться в службу технической поддержки.
Authentication required
Для отправки требуется пройти аутентификацию по логину и паролю.
Примеры корректной настройки почтовых клиентов можно посмотреть