STOP SPAM. PTR, SPF, DKIM, DMARC

Хочу немного рассказать, по каким тестам почтовые сервера распознают спам, и как настроить свой почтовый сервер так, что бы вероятность попадания в черные списки была минимальной.

Протокол SMTP разработан довольно давно, и его авторы, по всей видимости, не подозревали, какие объёмы паразитного трафика будут гулять в дебрях этого протокола.

Сам по себе протокол не проверяет валидность отправителя, заголовок легко подделать.

Вы можете проверить это сами. Подключаемся к любому почтовому серверу по SMTP, например: telnet mxs.mail.ru 25

Устанавливаем сессию, первым делом представляемся: helo <Ваш IP или имя хоста>

Затем говорим, от какого имени хотим отправить письмо: mail from: mail@mail.ru

Кому хотим отправить: rcpt to: mail2@mail.ru

Передаём данные: DATA <данные> ENTER . ENTER

Как мы видим, имя отправителя не проверяется, проверки идут дальше, и если они не совпадают, то доставка отменяется.

Screenshot_8

А теперь собственно о проверках. Первая проверка это PTR (pointer) — обратная DNS запись. Прописывает её Ваш провайдер, нужно обращаться к нему. Как мы знаем, обычно DNS разрешает имя хоста в IP. PTR запись производит обратную операцию, IP разрешает в доменное имя.

Зачем это нужно? Представим, что у Вас есть почтовый сервер 1.1.1.1 и домен superpochta.com. При отправке, наша суперпочта представляется серверу получателю (helo). Сервер получатель сверяет helo, и PTR запись IP, с которого была отправлена почта, важно что бы они совпадали. Если нет — вы получите сколько то баллов, которые Вам присвоит антиспам сервера, если их будет по итогам проверок больше определенно лимита — письмо либо попадёт в спам, либо вообще не будет принято. Проверить можно здесь, вводить нужно IP адрес почтового сервера.

Следующая проверка это SPF — sender policy framework. Данная проверка позволяет указать, с каких адресов разрешена отправка почты для нашего домена, и что делать с письмом, если проверка не пройдена. Добавляется данная TXT запись в DNS хостинг провайдера.

Например запись: «v=spf1 mx -all» говорит о том, что почту нужно принимать только с тех серверов, которые прописаны в mx записях DNS нашего домена, а остальную почту не принимать. Если же вместо -all будет ~all (с тильдой) то этот вариант называется «soft fail» и позволяет принимать почту, не соответствующую политике,  но помечать её как подозрительную. Политика позволяет делать очень гибкие записи, с разрешениями и запретами. Дабы не переписывать то, что уже есть, синтаксис можно посмотреть тут. А проверить SPF можно здесь.

Дальше идёт проверка DKIM. Если Вы знакомы с понятием цифровой подписи — то это она и есть. На сервере у нас хранится закрытый ключ, а в DNS TXT записи — открытый. Как мы знаем, то что зашифровано закрытым ключом, может быть расшифровано только открытым, и соответственно наоборот. Это и есть ассиметричное шифрование.  Наш почтовый сервер может вычислить хэш отправляемого письма, зашифровать его закрытым ключом, и добавить эти данные в заголовки письма при отправке, а также имя нашего домена. Принимающий сервер при получении, также высчитает хэш письма, расшифрует заголовки открытым ключом, и сверит данные. Если они совпадают — значит это гарантия того, что письмо в пути не изменилось, и отправлено с доверенного домена.

DNS запись выглядит следующий образом:

Имя: mail._domainkey.mydomain.ru

Запись: «v=DKIM1; k=rsa; p=MIGfMA0;olnnoesrvwenuOUROV NEJFOPNUfocnEUFcn()UE()RCB&E()R&#)Yd5j9nn6MeGw3FlYb8r2GthsnMHj05/d0JTPiofY3Ym1EB9ME5a4CES7FoRGgM0zhfNmgPwj6UvYCwIDAQAB»

В exchange server нету встроенной поддержки DKIM, но есть сторонний транспортный агент, поддерживающий exchange c 2007 по 2016. Скачать его можно здесь. Установку можно произвести через power shell, либо, что удобнее, через GUI. Потребует framework 4.5.

Настройка сводится к указанию домена, и генерированию ключа из программы. Можно сгенерировать лиюл 1024 или 2048бит. Информация для DNS появляется в программе сразу. Suggested dns name это имя TXT записи, DNS record соответсвенно сама запись. Остальные настройки можно не трогать. Имейте ввиду, при сохранение настроек (save domain внизу) и при установке агента, перезапускается служба транспорта exchange. Также после установки агента, проверьте что бы он был последний в очереди обработки. Посмотреть можно из самой программы, в разделе information — configure. Документация по DKIM здесь.

Screenshot_99

И последним настроим DMARC. Эта политика позволяет говорить  принимающим серверам, что делать с почтой, не прошедшей проверки SPF и DKIM. А также оправлять нам отчёты о таких письмах.

Эта политика также прописывается в TXT DNS записи. Имя должно быть формата _dmarc.mydomain.ru а в теле записи примерно такого вида: v=DMARC1; p=none; fo=1; rua=mailto:admin@mydomain.ru; ruf=mailto:admin@mydomain.ru

«p» может иметь параметры none, quarantin или rejected. В первом случае никаких действий не предпринимается, во втором случае почта не прошедшая проверки SPF и DKIM помечается как спам, а втретьем просто не принимается.

«fo» в отчёт будут попадать события сбоя проверки или SPF или DKIM, при значении 0 и SPF и DKIM.

RUA это адрес для сводного отчета, который будет приходить раз в сутки.

RUF — уведомления об ошибках тестов SPF и DKIM, должен приходить сразу.

Документацию можно почитать здесь а проверить — тут.

После настройки этих действий, можно посмотреть заголовки писем. Например, у gmail это называется «показать оригинал»

Screenshot_111

И там мы увидим:

Authentication-Results: mx.google.com;
dkim=pass header.i=@mydomain.ru
spf=pass (google.com: domain of user@mydomain.ru designates 192.1.10.10 as permitted sender) smtp.mailfrom=user@mydomain.ru;
dmarc=pass (p=NONE dis=NONE) header.from=mydomain.ru

Протестировать ресурс на все проверки разом можно здесь.

Если у Вас есть вопросы, задавайте их на форуме, или ниже в комментариях.

2 комментариев

  1. 11.09.2016    

    Очень полезная информация! Спасибо

    • Иван Иван
      11.09.2016    

      Рад был помочь.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Реклама

Реклама

Tags