Отказ dns или нет информации о сервере поэтому письмо попадет в спам
Борьба со спамом — это головная боль всех ответственных администраторов почты. Чего только они не изобретают, чтобы любимым пользователям лучше жилось. Однако, как показала практика общения со многими системными администраторами, почему-то далеко не все представляют как правильно фильтровать спам.
Чаще всего встречается подход «добавим кучу RBL (DNSBL) и будем радоваться жизни». Подход не верный чуть более, чем полностью. Второй по популярности — контент-фильтры, зачастую купленные за бешеные деньги. Такой подход тоже в большинстве случаев совершенно неоправдан.
А ведь всё так просто, для спокойной жизни достаточно всего лишь пристально присматриваться к трём заголовкам входящей SMTP сессии. Порывшись на Хабре и в закоулках интернета так и не нашёл исчерпывающей статьи на тему правильной настройки SMTP сервера с точки зрения противодействия спаму. Поэтому решил расписать всё, что знаю на эту тему сам и чем успешно пользуюсь.
Кстати: эта статья конечно ориентирована в первую очередь на администраторов, желающих сделать качественный фильтр спама. Однако с другой стороны она содержит очень важные сведения для тех, кому приходится просто работать с почтой, но кто плохо разбирается во всех тонкостях процесса электронной пересылки корреспонденции.
Итак, если вы хотите обезопасить своих пользователей от спама или наоборот, хотите чтобы кто-то случайно не обезопасил пользователей от ваших писем — добро пожаловать под кат.
Небольшая замечание: статья написана с прицелом на настройку почтового сервера Postfix, но в целом носит скорей теоретический характер. Описанные опции Postfix нужно указывать в соответствующих *_restriction параметрах конфигурационного файла, за подробностями обращайтесь к любому руководству по настройке Postfix.
Немного об SMTP протоколе
Электронная почта имеет много аналогий с почтой обычной. Самое для нас главное сейчас то, что вся информация на электронном «конверте» представляет из себя всего лишь два адреса: получателя и отправителя, а также штампик почтальона, конверт доставившего.
Немного отвлечёмся: представьте, что к вам придёт лицо крайне отталкивающей наружности и вручит плотно запечатанную посылку с обратным адресом «Трям из Тилимилитрямдии». Рискнёте принять и открыть? Вряд ли. Так вот, электронную почту можно тоже легко проверять и отсеивать исходя только из адресной информации, причём простор для возможных действий тут гораздо шире.
Как вам должно быть известно, почта в интеренете передаётся между почтовыми серверами по протоколу SMTP. Любое общение по этому протоколу начинается с трёх обязательных заголовков: HELO, MAIL FROM и RCPT TO. То есть перед тем, как начать передавать какие-либо данные, сервер сначала представляется (HELO), потом сообщает обратный адрес отправителя (MAIL FROM) и затем — адрес получателя (RCPT TO). Эти три заголовка и есть подпись на электронном конверте, и практически весь спам можно отсеять только исходя из их анализа. Большинство попыток передать что-то моему серверу не доходят дальше MAIL FROM, то есть письма отсеиваются ещё до фактического принятия, что значительно снижает нагрузку. То есть вместо того, чтобы открыть посылку от Тряма и обнаружить там споры сибирской язвы, я сразу посылаю почтальона куда подальше.
Итак, что же надо делать, чтобы не принимать письма, заведомо являющиеся спамом? Пойдём по порядку.
Немного о DNS
MX записи содержат адреса серверов, на которые должны доставляться письма для указанного домена. Однако в целях борьбы со спамом появилась технология, позволяющая указывать в DNS также адреса серверов, с которых могут приходить письма от указанного домена. Имя ей — Sender Policy Framework.
Подробно вдаваться во все тонкости технологии я не буду, скажу лишь, что TXT запись
v=spf1 +mx -all
для вашего домена скажет всем клиентам, поддерживающим проверку SPF, что письма из вашего домена могут приходить исключительно с серверов, указанных в MX записях. Можно сделать правило мягче, написав вместо -all ~all. За подробностями обращайтесь в Google и на официальный сайт SPF.
Всегда прописывайте SPF запись для домена, а так же включайте проверку SPF на своих почтовых серверах. Я рекомендую жёстко запрещать отправку писем из вашего домена со всех хостов, кроме ваших MX серверов. Вкупе с проверкой SPF на вашем сервере подобная настройка сразу срежет все письма, посылаемые со сторонних хостов от имени пользователей вашего домена на адреса пользователей вашего же домена. А такого спама чуть ли не половина, поскольку обычно SMTP серверы очень плохо защищены от писем из своего же собственного домена, и спамеры этим активно пользуются. SPF раз и навсегда избавит вас от писем Васе Пупкину, написанных судя по конверту Васей же Пупкиным, но пришедших с сервера в каком-нибудь Никарагуа.
Как настроить SPF в Postfix вам расскажет гугл, информации навалом и ошибиться нельзя, так что не будем тратить время на технический подробности.
Есть ещё пару крайне важных замечаний по поводу DNS. Скорее всего вы знаете, что основные записи DNS, так называемые A записи, преобразуют имя в IP адрес. Кроме них есть ещё CNAME записи, которые назначают псевдоним уже существующему имени. Именно эти два типа записей составляют основу всей системы доменных имён.
Но мало кто из пользователей знает, что есть так же обратные записи, которые преобразуют IP в доменное имя. Они носят название PTR. Так вот, есть два неписаных (строго говоря) правила, которым всё же все следуют:
- Для каждой A записи должна существовать зеркальная PTR запись, то есть по имени хоста через DNS получаем IP, а по IP — обратно то же имя хоста.
- В качестве адреса в MX записи всегда должно стоять имя (не IP!) хоста, для которого существует A запись. То есть нельзя, чтобы в MX записи стоял IP или псевдоним (CNAME).
Если вы не соблюдёте одно из этих требований — приготовьтесь к тому, что минимум четверть почты с вашего домена будет распознаваться как спам. Обусловлено это простым тезисом: благонадёжный отправитель всегда всё настраивает соблюдая правила, соответственно если правила не соблюдены — то отправителю доверять не следует, а значит и принимать от него почту — тоже.
Ну а чтобы включить проверку PTR у себя, используйте опцию
reject_unknown_client_hostname
Она требует, чтобы IP, с которого совершается соединение, резолвился в имя через PTR, а это имя резолвилось в свою очередь обратно в искомый IP.
Есть и менее жёсткое ограничение, задаваемое опцией
reject_unknown_reverse_client_hostname
В этом случае сервер будет проверять только наличие PTR записи, но не будет требовать существования соответствующей записи A.
Проверяем приветствие
Итак, кто-то захотел передать вашему серверу письмо. Передача начинается с приветствия — заголовка HELO. В HELO должно быть указано полное доменное имя (FQDN) отправителя, соответственно если это не так — можете смело сразу же отказывать в принятии. В Postfix для этого служат две опции:
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
Первая запрещает приём писем от хостов, передающих приветствие с некорректным синтаксисом, вторая — от хостов, передающих не FQDN в 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, оставив только возможность принимать письма на известные адреса. Для этих целей служит опция
В качестве промежуточного итога
Вот так только на основе анализа трёх заголовков конверта можно отсеять огромное количество спама. Однако спамеры хитрые, поэтому этого всё же недостаточно.
Грейлистинг
Минусом применения является небольшая (обычно не более получаса) задержка в доставке писем при первом соединении от неизвестного хоста. То есть если ещё не известный нашему постфиксу сервер хочет передать письмо, то при первой попытке соединения ему отправляется ошибка о временной недоступности. Если сервер повторил попытку соединения — то письмо принимается, а сервер заносится в надёжные узлы и в дальнейшем письма от него принимаются без задержек.
О настройке грейлистинга в Postfix так же предлагаю прочитать в Google, это несложно и ошибиться не получится.
Блоклисты, или как делать не надо
Некоторые администраторы почты при фильтрации спама полагаются на так называемые DNSBL (RBL) — чёрные списки узлов, замеченных в рассылке спама. Так вот, никогда не добавляйте никаких проверок DNSBL на ваши почтовые сервера. Тому есть две причины: первая, и самая основная, кроется во второй части первого предложения этого раздела. В эти списки узлы заносятся совершенно беспорядочно и нет никаких гарантий, что туда не попадёт нормальный хост (на котором, может быть, в какой-то момент поселился вирус, рассылающий спам, но теперь вирус уже вылечили, или проще и гораздо реальней — один внешний IP для большой сети, в которой завёлся спамер). Вторая причина более банальна: предложенный выше механизм фильтрации гораздо эффективней любых DNSBL и при этом не полагается на непроверенные данные от третьих лиц.
С ног на голову, или посмотрим с другой стороны баррикад
Фильтровать спам научились, теперь же я постараюсь свести воедино всю информацию на тему того, что же надо делать, что бы не попасть в спам.
Для администраторов почтовых серверов:
- Всегда делайте MX записи ссылающимися на записи A.
- Запись A для почтового сервера всегда должна иметь зеркальную PTR запись.
- Хост из HELO заголовка должен иметь A или MX запись.
- Всегда создавайте SPF записи (да-да, это-то как раз не обязательно, но просто правило хорошего тона).
- Для всех писем, рассылаемых из обслуживаемого домена, ящик для обратного адреса должен существовать и принимать почту.
Резюме
Конечно, предложенные настройки фильтруют не весь спам. Поэтому вполне возможно вам потребуется дополнительно использовать ещё и контекстный фильтр, который будет анализировать содержание писем, например, spamassassin, хотя я ничего подобного и не использую.
Однако никогда не забывайте про описанное в этой статье при настройке почты, потому что приведенные параметры позволяют снизить нагрузку на сервер на порядки по отношению к использованию только контекстных фильтров, да и дополнительно обеспечивают отличную фильтрацию.
UPD: Во-первых спасибо Vanav за критически важные замечания. Во вторых подразумеваемое изначально мной, но видимо всё же не до конца понятое резюме по приведённым опциям:
Актуальная версия статьи
ХострТрекер предлагает проверить, не попал ли Ваш домен в DNS блеклист. Это может случится по целому ряду причин: например, подозрение в рассылке спама, размещении запрещенного контента (или даже просто ссылок на сайты, где таковой имеется) и т.п. Как это выявить и как с этим бороться? Читайте под катом.
Почему так происходит?
Критерии, по которым составляются блеклисты доменов, довольно сильно разнятся, а также изменяются с эволюцией алгоритмов. Поэтому нет никакой гарантии, что даже кристально чистый с точки зрения закона, морали и негласных правил Интернета домен случайно не попадет туда со временем. Причин, по которым это может произойти, множество — перечислять их все особого смысла нет.
Недавно мы столкнулись с этой проблемой. Как сервис мониторинга, мы постоянно рассылаем оповещения о состоянии сайтов, ежедневные и другие периодические отчеты. И в какой-то момент оказалось, что у некоторых клиентов эти письма попадают в спам.
Что делать?
Во-первых, необходимо вовремя обнаружить проблему. Для этого мы специально разработали новую бесплатную функцию — проверку наличия домена в DNSBL:
Стоит отметить, что эта функция не является уникальной — есть и другие подобные сервисы, например Mxtoolbox, с помощью которого мы обнаружили, что наш домен попал в пару «черных списков». Но мы решили, что среди прочих инструментов, которые предлагает ХостТрекер, этот также будет уместным и полезным.
Типичный результат нашей проверки DNSBL представлен на первом изображении к этой статье. Если обнаружены какие-либо проблемы, указывается причина попадания сайта в блеклист.
Как правило, сначала домен включается в список «для выяснения обстоятельств». С Вашей стороны можно эти обстоятельства выяснить — для начала, просто доказать, что Вы человек, а не робот. Для этого зайдите на сайт соответствующего блеклиста и следуйте инструкциям. Все довольно просто — вводите название домена, нажимаете кнопку «разблокировать». В некоторых случаях может понадобиться написать письмо с просьбой удалить из списка. Но перед этим, конечно же, следует устранить причину попадания.
Например, в случае с подозрением в спам-рассылке, необходимо удостовериться, что Ваш почтовый сервер никто не использует в зловредных целях. Крайне рекомендуется настроить обратное определение DNS для почтового сервера. Также можно настроить SPF. Для большинства спам-списков этого будет достаточно, чтобы более Вас туда не вносить.
Конечно, могут быть и другие причины, по которым домен может угодить в подобный список. Но почти всегда гордое имя Вашего сайта возможно отбелить, если, конечно, оно попало в этот список действительно случайно. Немаловажна в этом деле быстрота Вашей реакции — чем быстрее Вы заметите проблему и начнете на нее реагировать — тем больше вероятность, что домен не успеет «расползтись» по всем блеклистам и прочно там укорениться. И вот именно для этого мы и предлагаем Вам наш новый инструмент.
Эффективность сайта в немалой степени зависит от его репутации. Избавить пользователя от спама – одна из важнейших задач в сети для добросовестного бизнеса. Для борьбы со спамом формируются списки хостов-спамеров, которые помещаются в блеклисты, формируя DNSBL. ХостТрекер предлагает функционал, который, помимо обычной проверки доступности сайта, проверяет домен на попадание в DNSBL.
Как работает DNSBL?
- Базы почтовых серверов неправильной конфигурации, сформированный автоматически по списку открытых релеев, позволяющих распространять спам
- Отзывов и жалоб пользователей различных сайтов и сервисов
- Списков IP подозрительных почтовых серверов, критерии могут быть различными
- Списков анонимных прокси, способствующих скрытым действиям в сети любого пользователя, в том числе и для мошенничества и рассылки спама.
Как проверить наличие сайта в блеклистах?
ХостТрекер предлагает сделать это очень просто — при создании мониторинга нужно лишь установить необходимый флаг, и параллельно с обычными проверками, будут идти проверки на попадание в DNSBL. Кроме того, если обычный мониторинг не нужен — можно создать отдельное задание для мониторинга DNSBL.
Рассмотрим несколько примеров
Что делать если Ваш домен попал в DNSBL?
Резкий спад посещения сайта может быть связан с попаданием в блеклисты по IP. Нет никакой гарантии, что случайный спамер не закажет хостинг на одном сервере, одном IP, с вашим сайтом. То есть вы можете попасть в эти списки без каких-либо действий с вашей стороны. По-хорошему этим, конечно же, должен заниматься хостер. Но это по-хорошему. А даже если и занимается, это может занять какое-то время, поэтому поощрительный пинок с вашей стороны явно не навредит. В данной ситуации необходимо проверить наличие сайта в блеклистах, и если же он обнаружен в каком-то из них – следует создать запрос администраторам конкретной базы DNSBL и попытаться исключить адрес из черного списка. Ну а если уж джекпот сорван: и хостер попался нерадивый, и спамер все не унимается, и из DNSBL не спешат удалять ваш домен — тогда можно изменить способ маршрутизации почты, то есть MX записей для Вашего домена. В записи МХ содержится IP. Данные изменения относятся к коррекции записи DNS сервера, где и расположен домен. На каждом таком сервере свой функционал. Изучив его, можно внести необходимые изменения.
Хотим подчеркнуть, что мгновенные проверки DNSBL можно сделать с сайта сервиса совершенно бесплатно и без регистрации. Поэтому надеемся, что эта функция будет полезной. Будем рады услышать ваши пожелания и отзывы.
Электронная почта — один из самых популярных каналов распространения спама, малвари и фишинговых ссылок. Существует куча софта, который защищает почтовые серверы от этих напастей, да вот незадача: большинство таких программ стоит денег, и порой немалых. В этой статье я расскажу, как усилить безопасность корпоративных почтовых серверов (MS Exchange и Postfix) с помощью доступных штатных средств — DKIM-, SPF- и DMARC-записей, не требующих использования дорогостоящих коммерческих продуктов.
Заключение
Вот и все! Если проделать все описанное, то о проблемах с доставкой почты можно забыть.
Практика и еще раз практика
В практической части мы рассмотрим конфигурирование описанных выше настроек безопасности на примере двух наиболее популярных почтовых серверов — опенсорсного Postfix на Debian (ну, или Ubuntu Server) и проприетарного Microsoft Exchange Server 2013+. Предполагается, что почтовые серверы у тебя уже установлены и настроены под твой домен, поэтому рассматривать будем только само конфигурирование фич на обезличенных данных.
Настраиваем SPF, DKIM и DMARC на Postfix (Debian)
Общий принцип работы нашего почтового сервера будет таков:
Кто отправляет письма
По умолчанию все PHP-приложения используют для отправки почты функцию mail() , которая, в свою очередь, отправляет их через локальный SMTP-сервер, описанный в php.ini .
Или в виртуальном хосте:
Как не попасть в спам
Другие статьи в выпуске:
Борьба со спамом породила множество технологий. Самая старая из них — blacklist, в который заносятся все IP и домены, занимавшиеся рассылкой спама, сюда же могут попасть открытые релеи, прокси и Dialup-адреса, используемые для удаленного доступа (то есть они теоретически не должны рассылать почту). Организованы такие blacklist по-разному. Популярностью пользуются DNSBL (DNS blacklist) — черные списки в формате DNS, которые легко опрашивать. На сегодня доступно множество баз, не все они популярны и используются. Проблема в том, что списка для конкретного почтового сервиса нет, сколько и какие они опрашивают — это тайна.
Проверить IP или домен можно самостоятельно, отослав DNS-запрос к выбранному DNSBL-серверу при помощи утилиты dig:
Прогоняем домен по DNSBL-базам
От чего нельзя защититься с помощью DKIM, SPF и DMARC
С использованием DKIM, SPF и DMARC можно противостоять email-спуфингу и распространению малвари. Однако важно понимать, что это не гарантирует безопасности в случае взлома сервера, например путем компрометации админки или применения эксплоита, а также если письма форвардятся через иные почтовые сервисы с сомнительной репутацией или с полностью отсутствующими записями DKIM, SPF и DMARC.
Некоторые полезные ссылки для проверки корректности настройки DKIM- и SPF-записей, а также репутации домена:
SPF Policy Tester — онлайн-сервис проверки корректности SPF-записи. Для проведения теста на сайте указываешь почтовый адрес, с которого хочешь отправлять письма, и IP-адрес почтового сервера. Если все хорошо, то после нескольких секунд ожидания внизу страницы должна появиться зеленая надпись PASS .
Разбираемся с SPF
Несмотря на то что для SPF придуман отдельный тип записи, он так и остался опциональным (при наличии поля его лучше тоже создать, хуже не будет), TXT обязательна.
Если домен может отправлять почту с нескольких адресов, все их прописываем здесь или указываем в MX-записи. Если VDS имеет IPv6-адрес, обязательно прописываем его здесь в ipv6: . Расшифруем:
- v=spf1 — используемая версия SPF;
- a — прием писем от узла с IP-адресом, указанным в A-записи домена;
- mx — подключает адреса, указанные в MX-записях;
- all — что делать с серверами, не перечисленными в SPF. Причем все указанное после all проверяться не будет, оно должно стоять последним.
В 2004 году в MS предложили схожую с SPF технологию, названную Sender ID и использующую DNS-записи spf2.0/pra , или spf2.0/mfrom , или spf2.0/mfrom,pra . Проверяется MAIL FROM, а не адрес возврата. Технология в настоящее время не получила широкого распространения, и MS рекомендует при отсутствии явных записей spf2.0 рассматривать v=spf1 как эквивалент spf2.0/mfrom,pra и использовать его при анализе. Вот, собственно, и все, что нужно о ней знать.
Проверяем SPF
WARNING
Перед любыми операциями по конфигурированию системы не забывай сделать бэкап! Даже одна неправильно включенная опция может отрезать всех пользователей от получения и отправки почтовой корреспонденции. И обязательно тестируй все изменения перед переносом в их продакшен!
Настройка SPF-записи
- v=spf1 — используемая версия SPF;
- + — принимать корреспонденцию (Pass). Этот параметр установлен по умолчанию. То есть, если никаких параметров не установлено, это автоматически Pass ;
- - — отклонить (Fail);
- ~ — мягкое отклонение (SoftFail). Письмо будет принято, но будет помечено как спам;
- ? — нейтральное отношение, то есть никаких действий не предпринимать;
- mx — включает в себя все адреса серверов, указанные в MX-записях домена;
- ip4 — опция позволяет указать конкретный IP-адрес или подсеть IP-адресов;
- a — указываем поведение в случае получения письма от конкретного домена;
- include — включает в себя хосты, разрешенные SPF-записью указанного домена;
- all — все остальные серверы, не перечисленные в SPF-записи.
WARNING
Важно помнить, что, к сожалению, настройка DKIM-, SPF- и DMARC-записей не панацея от всех бед. Если почтовый сервер был взломан, эти функции безопасности не смогут защитить от нелегитимного трафика. Поэтому важно заранее продумать эшелонированную защиту системы, включая антиспам-фильтры, антивирусное детектирование и прочее.
Настраиваем DKIM
Демон будет работать с правами opendkim:opendkim. Генерируем ключи для селектора mail.
В текущем каталоге появятся два файла: mail.private — закрытый ключ и mail.txt — открытый. Добавляем в DNS-запись типа TXT из mail.txt .
Настройки OpenDKIM в Ubuntu находятся в файле /etc/opendkim.conf . Их, в принципе, может быть много, и могут использоваться дополнительные файлы, так как один демон часто обслуживает несколько доменов. В /usr/share/doc/opendkim/examples есть пример. Но в простом случае достаточно изменить несколько параметров под свои условия.
После установки демон opendkim слушает сокет /var/run/opendkim/opendkim.sock , но при необходимости можно указать сетевой порт и интерфейс. После правки файла перезапускаем демон:
Добавляем в /etc/postfix/main.cf данные сокета:
Коротко это все настройки.
Проверить DKIM можно с помощью утилиты opendkim-testkey:
Настройки в /etc/opendkim.conf
Доступны три варианта политик:
Собственно, в указанном примере и вся суть DMARC. Остальные параметры доступны в RFC.
Что такое SPF?
Важно помнить, что SPF-запись должна быть только одна для одного домена, хотя уже в рамках одной SPF может содержаться несколько записей. И надо сказать, что для поддоменов будут нужны свои записи. И никак иначе! Безопасность требует времени и усердия. 🙂
Принцип работы SPF
Что такое DKIM?
Для работы с DKIM требуется выполнение следующих условий:
- поддержка DKIM почтовым сервером (а она есть у всех современных почтовиков);
- создание приватного и публичного ключа шифрования (это нужно сделать ручками);
- занесение в DNS домена записей, связанных с DKIM (и это тоже ручками).
Для интересующихся этой темой в нашем журнале публиковался краткий гайд «Как настроить почтовый сервер для обхода спам-фильтров: руководство по DNS, SPF, DKIM», который поможет тебе взглянуть на проблему рассылки спама, вредоносного ПО и фишинга глазами владельца почтового ботнета. 🙂
Если письмо не доставляется
Способ обращения в службу поддержки у разных сервисов отличается, найти их на сайте не всегда просто.
Продолжение доступно только участникам
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Вариант 2. Открой один материал
Правильная DNS
То же касается и самописных PHP-скриптов.
Заголовки Received отличаются, хотя есть общие правила. Типичный выглядит так:
Для IPv6 используется ip6.arpa. В принципе, знать об особенностях PTR необязательно, так как PTR, за редким исключением, настраивает только хостинг-провайдер. И если оно не устраивает, то нужно просто обратиться в поддержку. Проверить PTR можно при помощи запроса:
Как вариант — можно отключить IPv6 и отправлять только по IPv4. В /etc/postfix/main.cf Postfix для этого следует использовать всего одну строку:
После чего перезапустить сервис.
В Exim в /etc/exim/exim.conf
Не забываем, что SMTP-сервер обычно использует IPv4 и IPv6
Иногда используется значение $mydomain, которое по умолчанию содержит доменную часть полного имени машины.
Exim в HELO/EHLO использует значение переменной primary_hostname, которая по умолчанию совпадает с именем хоста. Но можно задать его вручную:
Но если на одном VDS несколько доменов, то такая схема уже будет проблематичной. В принципе, в RFC нет явного запрета на несколько PTR-записей для одного IP, но есть уже устаревшая рекомендация IETF, в которой расписана эта проблема и совет не делать этого в первую очередь из-за возможных ошибок. Очевидно, его и придерживаются, во всяком случае, провайдеры не хотят добавлять еще PTR-записи. В такой ситуации нужно или оставить техническое имя сервера, или (лучше) выбрать один из используемых доменов как основной и настроить PTR и hostname под него.
Иван Пискунов
Что такое DMARC?
Принцип работы DMARC
Немного теории о том, что мы будем настраивать
Итак, прежде чем мы приступим непосредственно к изменению настроек безопасности нашего почтового сервера, нужно разобраться с тем, что именно мы собираемся настраивать. Если тебя не пугают страшные на вид аббревиатуры, состоящие из трех и более заглавных букв латинского алфавита, ты можешь пропустить этот раздел. Остальных приглашаю освежить свои знания, ибо повторение, как гласит народная мудрость, мать учения.
Читайте также: