SPAM фильтры - DKIM, SPF, DMARC и FBL

  • Михаил
  • 10 мин. на прочтение
  • 85
  • 27 Jan 2018
  • 28 Jul 2023

Надежная защита от спуфинга электронной почты необходима всем, кто дорожит своей репутацией, доверием адресатов. Технология DKIM защитит конфиденциальные данные, исключит отправку e-mail от вашего имени, повысит доверие со стороны получателей. Антиспам фильтры на почтовых серверах продвинулись далеко вперед. Теперь зачастую недостаточно просто поставить почтовый сервер и настроить MX запись в соответствующей зоне DNS. Если при попытке отправить сообщение на почтовые сервера Gmail вы вдруг получили ошибку типа «Our system has detected that this message is 550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail, 550-5.7.1 this message has been blocked.», то это почти всегда значит, что на вашем почтовом сервере не настроены DKIM, SFP и DMARC. Крупные почтовые серверы (Gmail, mail.ru, Яндекс и т.д.) требуют наличие данных записей. В этой статье будет показано, как правильно настроить функционал почтового сервера Zimbra Collaboration Suite для корректного прохождения почтовых сообщений через современные спам-фильтры.

Спуфинг (spufing) – вид интернет-мошенничества, при котором злоумышленник выдает себя за знакомое адресату лицо для получения доступа к конфиденциальной информации, проведения финансовых махинаций и заражения ПК и других устройств вирусами.

 

Настройка DKIM.

DKIM (DomainKeys Identified Mail) — это метод e-mail аутентификации, основанный на проверке подлинности цифровой подписи. DKIM необходим для того, чтобы почтовые сервисы проверяли отправителя и защищали получателя письма от мошеннических рассылок, которые производятся с подменой адреса отправителя.

Метод предусматривает шифрование заголовков исходящих сообщений с помощью закрытого ключа домена, и добавление открытой версии ключа в записи DNS домена, доступного всем. MTA сервера-получателя запрашивает для расшифровки заголовков входящих сообщений открытый ключ у DNS-сервера отправителя, а затем проверяет, действительно ли сообщение отправлено от заявленного источника.

Встроенные в Zimbra возможности DKIM стали доступны начиная с версии 8.0. Настройка состоит из двух этапов.

Генерация ключей и селектора.

Генерация пары ключей с использованием OpenSSL

Генерация пары ключей с использованием OpenDKIM

Для генерации приватного ключа в командной строке введите: openssl genrsa -out privatekey.pem 1024, где «privatekey.pem» — файл приватного ключа, «1024» — длина ключа.

Пример результата:

Для генерации публичного ключа введите команду: openssl rsa -pubout -in privatekey.pem -out publickey.pem, где «publickey.pem» — файл публичного ключа

Пример результата:

Для генерации ключей используйте команду opendkim-genkey -d example.ru -s mail, где «example.ru» — ваш домен, «mail» — селектор.

При этом в текущей директории будут созданы файлы mail.private с приватным ключом и mail.txt с готовым публичным ключом в формате DNS-записи.

Добавляем данные DKIM к домену, у которого еще нет существующей конфигурации DKIM. Если реализована много серверная схема развёртывания Zimbra, то данные действия проводим на сервере, где установлена роль OpenDKIM (как правило это сервер с ролью MTA)

su zimbra
/opt/zimbra/libexec/zmdkimkeyutil -a -d subbnet.ru

На выходе получаем что-то типа этого:

Запоминаем (коипруем в блокнот) строки после фразы "Public signature to enter into DNS:" Данную запись в дальнейшем нам нужно будет вставить в DNS зону соответствующего домена.

Также можно обновить DKIM данные для домена:

/opt/zimbra/libexec/zmdkimkeyutil -u -d subbnet.ru s

Удалить DKIM данных для домена:

/opt/zimbra/libexec/zmdkimkeyutil -r -d subbnet.ru

Извлечь сохраненные данных DKIM для домена:

/opt/zimbra/libexec/zmdkimkeyutil -q -d subbnet.ru

Внесение записей в зону DNS.

На предыдущем шаге мы запомнили строку, выданную при генерации ключей. Теперь эту строку необходимо внести в соответствующую зону DNS. Выглядеть это будет примерно следующим образом:

После внесения записи, перечитываем файл зоны и проверяем результат выполнения команды:

host -t txt SELECTOR._domainkey.DOMAIN

где SELECTOR - набор символов, предшествующий ._domainkey в записи TXT. Например:

host -t txt ECAC22D2-DCA2-11E6-BA30-B554729FE32B._domainkey.example.com ns1.example.com

Если ключ извлекается используйте /opt/zimbra/common/sbin/opendkim-testkey, чтобы убедиться, что открытый ключ соответствует закрытому.

opendkim-testkey -d example.com -s ECAC22D2-DCA2-11E6-BA30-B554729FE32B -x /opt/zimbra/conf/opendkim.conf

Если при выполнении данной команды получили ошибку:

opendkim-testkey: /opt/zimbra/conf/opendkim.conf: configuration error at line 0

то это означает, что файл /opt/zimbra/conf/opendkim.conf отсутствует и его необходимо создать командой:

zmprov ms `zmhostname` +zimbraServiceEnabled opendkim ./libexec/configrewrite opendkim

Если возникнет необходимость отозвать ключ подписи DKIM, установите пустой параметр «р=» тег в записи TXT.

По умолчанию создается 1024-битный ключ (зависит от версии ZCS), изменить размер можно параметром -b.

 

Настройка SPF (Sender Policy Framework).

SPF (Sender Policy Framework) — расширение для протокола отправки электронной почты через SMTP. SPF определен в RFC 7208. SPF-запись защищает от подделки вашего домена и позволяет предотвратить попадание в спам писем, отправленных с ваших адресов. SPF настраивается для адреса, используемого в envelope-from (SMTP конверте).

С помощью spf-записи владелец домена может указать список серверов, имеющих право отправлять email-сообщения для домена. В общем случае порядок следующий:

[версия] [механизмы] [-all | ~all | redirect]
Версия всегда spf1, модификаторы сообщают, кто может посылать почту:

  • a, mx — сервера из DNS записей A или MX соответственно,
  • ip4, ip6 — адрес сервера (можно указывать подсети, например: ip4:1.2.3.4/24),
  • include — взять данные с другого адреса

Параметры:

  • -all означает не принимать почту, если проверка механизма не прошла,
  • ~all если проверка не прошла, то действовать на усмотрение сервера получателя.
  • redirect означает забрать правила с другого сервера.

Рассмотрим примеры добавления TXT записей в соответствующую зону DNS.

Пример 1.

subbnet.ru. IN TXT «v=spf1 ip4:92.100.158.44 a mx -all»
Для домена example.com принимать письма, отправленные с ip-адреса 92.100.158.44, так же принимать с серверов указанных в A и MX записях, сообщения с других серверов должны быть отклонены.

Пример 2.

subbnet.ru. IN TXT «v=spf1 redirect:yandex.ru»
Получить правила с домена example.com.

Пример 3.

subbnet.ru. IN TXT «v=spf1 include:_spf.google.com -all»
Получать письма только с smtp-серверов компании Google.

 

Настройка DMARC.

Domain-based Message Authentication, Reporting and Conformance (идентификация сообщений, создание отчётов и определение соответствия по доменному имени) или DMARC — это техническая спецификация, созданная группой организаций для борьбы со спамерами, подделывающими адреса отправителей. Она основана на идентификации почтовых доменов отправителя на основании правил и признаков, заданных на почтовом сервере получателя. Перед настройкой dmarc необходимо настроить spf и dkim записи, это связано с тем, что технология DMARC использует данные средства. Если отправленное сообщение не прошло проверку DKIM и SPF, то оно не пройдет и DMARC. Если же сообщение успешно прошло хотя бы одну проверку (DKIM или SPF), то и проверку DMARC сообщение пройдет успешно.

Таким образом почтовый сервер сам решает, хорошее сообщение или плохое и действует согласно DMARC записи. Благодаря настройке DMARC владельцы доменов могут создавать правила обработки писем, которые поступили с доменов, не прошедших авторизацию.

осле создания записей SPF и DKIM необходимо настроить проверку DMARC, добавив в DNS запись типа TXT (аналогично SPF). Параметры могут быть следующими:

Название тега

Назначение

Пример

Требуется

Дополнительно

v

Версия протокола

v=DMARC1

да

 

p

Правила для домена

p=reject

да

none — не принимать никаких действий

quarantine — отправлять сообщения в спам

reject  — не принимать сообщения

aspf

Режим проверки

соответствия для

SPF-записей 

aspf=s

нет

r (relaxed) — разрешать частичные совпадения,
например субдоменов данного домена

s (strict) — разрешать только 
полные совпадения

pct

Сообщения,

подлежащие

фильтрации (в %) 

pct=40

нет

 

sp

Правила для

субдоменов 

sp=reject

нет

none — не принимать никаких действий

quarantine — отправлять сообщения в спам

reject  — не принимать сообщения

rua

Адрес для сводных

отчетов 

rua=mailto:admin@test.ru

нет

 

Пример записи: "v=DMARC1;p=none;rua=mailto:postmaster@example.com;ruf=mailto:postmaster@example.com;fo=s"

Более подробно можно узнать в реестре тегов DMARC.

Пример готовой DNS зоны TXT записями для DKIM, SPF и DMARC.

$ORIGIN .
$TTL 3600
subbnet.ru IN SOA subbnet.ru. hostmaster.subbnet.ru. (
2017011011 ; serial
3600 ; refresh [1h]
600; retry [10m]
1209600 ; expire [14d]
3600 ; min TTL [1h]
)
NS ns1.subbnet.ru.
MX 10 ns1.subbnet.ru.
A 92.100.158.44
IN TXT "v=spf1 a mx ip4:92.100.158.44 ~all"
$ORIGIN subbnet.ru.
ECAC22D2-DCA2-11E6-BA30-B554729FE32B._domainkey IN TXT ( "v=DKIM1; k=rsa; "
"p=MIIBIjANBgkqhkiEAs5OCY0sX04ziF+sOHt/1kq3A7iAzAjBjb4JteaoFzu1q2uBOiQS0uyaFeY6CgSgRRbvPnq8cWLG/XMU0tM9gSGtgtWDmHOs6/+QgKp6zRmetfsyABA2Y2U+XJlVURUE5ai3KIA/njt7IGZ5yeFsdZIKmhOCAOPGCovq10xkZXHdjRwiqxbCYGXv2m3o74BcWtOLPfEvexD5PYx"
"aTWFbelJpGlDN7WdBCE+ObpLGkJ9co/1sVOfPq3jcBAFm7oPX2ak7Fb7cslVK77lA2hBgMYqI2Sh+T64o6R33dU++Ej7CuImmv7PAqVUn5MjYr05t3LK9dwWM8Cm6aJ/QIDAQAB" ) ; ----- DKIM key ECAC22D2-DCA2-11E6-BA30-B554729FE32B for subbnet.ru
_dmarc IN TXT "v=DMARC1; p=none; rua=mailto:postmaster@subbnet.ru"
ns1 IN A 92.100.158.44
www 86400 IN CNAME subbnet.ru.

 

Настройка FBL.

FBL (Feedback Loop) — это стандарт выдачи информации о жалобах на спам от провайдера услуг электронной почты отправителю писем. 

Если говорить проще — любой отправитель писем (например, веб-сервис) может получать в реальном времени информацию о том, что конкретный пользователь пожаловался (нажал кнопку «Это спам») на конкретное письмо, пришедшее от этого сервиса. 

После нажатия кнопки «Это спам» наш сервис формирует отчет в специальном формате ARF (Abuse Reporting Format), который содержит исходное письмо и электронный адрес пользователя; также отчет может содержать дополнительную мета-информацию.

Формат письма ARF состоит из нескольких частей:

  • Текстовая версия. Предназначена для отображения пользователю, который может читать этот отчет. Может содержать некоторую подробную информацию (о чем этот отчет и почему был сгенерирован).
  • Служебная информация об этом отчете (Content-Type: message/feedback-report). Содержит информацию о типе отчета (abuse — для отчетов по жалобам на письма), а также может содержать разного рода дополнительную информацию.
  • Исходное письмо, на которое пожаловались, в виде вложения.

Обрабатывая FBL-отчеты, можно автоматически отписывать пользователей от рассылок, подчищая свою базу, формируя постоянную аудиторию заинтересованных подписчиков, снижая нагрузку на свои сервера и на сервера почтовых провайдеров. Кроме того, получая отчеты, можно проводить анализ содержимого рассылки, корректировать ее, чтобы снизить количество жалоб и тем самым избежать блокировок в будущем. 

После того, как внесены все изменения на почтовом сервере и в зонах DNS, после того как все изменения зон распространены, можно пройти простенькую проверку почтового сервера на сайте тестирования.