Перейти к содержимому


Фотография
- - - - -

Почтовая кухня: DNS (DMARC+SPF+DKIM+A+MX+PTR)


  • Авторизуйтесь для ответа в теме
В этой теме нет ответов

#1 Demonik

Demonik

    Учусь Linux

  • Администраторы
  • 41 сообщений

Отправлено 22 Декабрь 2015 - 10:54

 Установка подписи DKIM описана в этой статье.

Думаю, многим будет интересно наконец-то узнать, как работает почта. В нескольких статьях я попытаюсь максимально простым языком расписать все основные вопросы, связанные с работой электронной почты вообще и нужными настройками — в частности.

Для простоты и сокращения количества букв мы рассмотрим простейшую (и наиболее распространенную) ситуацию:

1 доменное имя (example.com).
1 почтовый домен (* example.com).
1 почтовый сервер (mail.example.com).
1 IP-адрес (127.127.127.127).

Касательно почты, в DNS нас интересует четыре типа записей.

  • A
  • MX
  • PTR
  • SPF
  • DMARC
  • DKIM (описан в этой статье)

Второй — обязательный, без него почта в 99% случаев не будет ходить вообще. Без остальных, в принципе, можно обойтись, но шансы, что ваше письмо будет отвергнуто как спам возрастают в разы — тот же mail.ru отбрасывает практически всю почту, чьи IP-адреса не имеют PTR, либо PTR относится к dial-up провайдерам. И это правильно.

A-запись

A (Address) — запись, указывающая IP-адрес нужного нам доменного имени. Для корректной работы почты требуется A-запись сервера почты (mail.example.com). Выглядеть, в нашем случае, она будет так:

mail IN A 127.127.127.127

Где:
mail — домен.
IN A — тип записи.
127.127.127.127 — IP нашего почтового сервера.

MX-записи.

MX (Mail eXchange) — основная DNS-запись для электопочты. Она указывает, какими серверами обрабатывается почта для нашего домена.

У нас есть один почтовый домен — example.com. И один почтовый сервер — mail.example.com. Соответственно, запись будет выглядеть так:

example.com. IN MX 10 mail.example.com 

Где:
example.com — домен, для которого обробатывается почта.
IN MX — тип записи.
10 — приоритет записи (Подробнее — ниже).
mail.example.com — A-имя почтового сервера.

MX-запись должна указывать именно на A-запись почтового сервера. Ставить MX указателем на IP или CNAME — не правильно.

Приоритет MX-записи нужен тогда, когда существует больше одного почтового сервера для одного домена (например у Google Mail их шесть). Он указывает, к какому серверу идет обращение в первую очередь, во вторую и так далее (если первый (второй, десятый) сервер недоступен или перегружен или по другим причинам не может принять письмо). Логика простая — приоритетнее тот, цифра которого меньше. Порядок цифр — не ограничен, хоть 10-20-30, хоть 1000-2000-3000.

Если у домена нет ни одной MX-записи, либо ни один из MX-серверов не доступен, сервер отправителя попытается доставить почту на IP, указанный в A-записи домена. Это назвается А-доставкой, но в принципе не кошерно и не используется многими серверами — нужно указывать MX, даже если он всего один.

PTR-запись.

PTR (PoinTeR) — так называемая «обратная запись». Она позволяет обратное разрешение (reverse resolving) IP-адреса в FQDN-хост.

Наш IP в виде reverse будет выглядеть так: 127.127.127.127.in-addr.arpa. В данном примере видно плохо, но адрес инвертируется в обратной зоне. Т.е. IP 192.168.0.1 будет выглядеть как 1.0.168.192.in-addr.arpa.

Для корректного распознования хоста, запись IP-адреса, с которого отправляется должна соответсовать hostname почтового сервера, отправляемому в HELO\EHLO.

PTR-запись в нашем случае, соответственно:

127.127.127.127.in-addr.arpa IN PTR mail.example.com.

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

TXT-запись и SPF.

Как всем известно, протокол отправки электронной почты SMTP, подразумевает, что в качестве отправителя можно указать любой почтовый ящик. Таким образом можно послать письмо, подставив в поле "From" вымышленное значение. Процесс такого почтового обмана называется Спуфинг (e-mail spoofing). Чтобы бороться с этим явлением, был разработан и введен в действие стандарт SPF – Sender Policy Framework (структура политики отправителя).

SPF позволяет владельцу домена указать в TXT-записи домена специальным образом сформированную строку, указывающую список серверов, имеющих право отправлять email-сообщения с обратными адресами в этом домене.
Рассмотрим простой пример SPF-записи.

example.org. IN TXT "v=spf1 +a +mx -all"

Теперь более детально о допустимых опциях. Рассмотрим варианты поведения получателя, в зависимости от используемых опций:

  • "v=spf1" - используемая версия SPF.
  • "+" - принимать корреспонденцию (Pass). Этот параметр установлен по умолчанию. Тоесть, если никаких параметров не установлено, то это "Pass";
  • "-" - Отклонить (Fail);
  • "~" - "мягкое" отклонение (SoftFail). Письмо будет принято, но будет помечено как СПАМ;
  • "?" - нейтральное отношение;
  • "mx" - включает в себя все адреса серверов, указанные в MX-записях домена;
  • "ip4" - опция позволяет указать конкретный IP-адрес или сеть адресов;
  • "a" - указываем поведение в случае получения письма от конкретного домена;
  • "include" - включает в себя хосты, разрешенные SPF-записью указанного домена;
  • "all" - все остальные сервера, не перечисленные в SPF-записи.

Итак, попробуем разобраться, что же значит SPF-запись, указанная выше.

  • "+a" - разрешает прием писем от узла, IP-адрес которого совпадает с IP-адресом в A-записи для example.org;
  • "+mx" -  разрешает прием писем, если отправляющий хост указан в одной из MX-записей для example.org;
  • "-all" - все сообщения, не прошедшие верификацию с использованием перечисленных механизмов, следует отвергать.

Для лучшего понимания того, как работает SPF, рассмотрим еще один, более сложный пример.

example.org. IN TXT "v=spf1 mx ip4:195.3.159.250 +a:smtp.mail.ru include:gmail.com ~all"

Теперь более подробно о используемых опциях...

  • "mx" - принимать письма от серверов, указанных в MX-записях;
  • "ip4:195.3.159.250" - принимать письма, отправленные с IP-адреса 195.3.159.250;
  • "+a:smtp.mail.ru" - то же, что и a:smtp.mail.ru. Принимать от smtp.mail.ru;
  • "include:gmail.com" - принимать письма с серверов, разрешенных SPF-записями gmail.com;
  • "~all" - принимать письма со всех остальных серверов, но помечать их как СПАМ

А теперь рассмотрим еще более "экзотичный" пример. В описании возможных опций указывалось, что возможно указание сетей ip-адресов. Стоит отметить, что это применимо и к записям "a" и "mx". Рассмотрим следующий пример.

example.org. IN TXT "v=spf1 mx/24 a:muff.kiev.ua/24 -all"
  • "mx/24" - в список разрешенных отправителей входят все IP-адреса, находящихся в тех же сетях класса С, что и MX-ы домена;
  • "a:muff.kiev.ua/24" - в список разрешенных отправителей входят все IP-адреса, находящихся в тех же сетях класса С, что и А-записи домена muff.kiev.ua;
  • "-all" - всех остальных отправителей - блокируем.

Иногда можно встретить следующие записи (очень редко):

  • "ptr" - проверяет PTR-запись IP-адреса отправителя. Если она сходится с указаным доменом, то механизм проверки выдает положительный результат. Тоесть, разрешено отправлять всем IP-адресам, PTR-запись которых направлены на указанный домен. Серьезным недостатком даного метода есть то, что генерируется очень большое количество DNS-запросов;
  • "exists" - выполняется проверка, резолвится ли домен на какой-либо IP-адрес. Тоесть, по существу, выполняется проверка работоспособности доменного имени. Кстати, не имеет значения, на какой IP-адрес резолвится домен, даже если это "серые" сети (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) или loopback (127.0.0.1).

Пример использования:
example.org. IN TXT "v=spf1 ptr:example.org exist:example.org -all"
Также не будет излишним ознакомиться со следующими опциями: redirect и exp.
"redirect" - указывает получателю, что нужно проверять SPF-запись указаного домена, вместо текущего домена. Пример:

example.org. IN TXT "v=spf1 redirect:example.com ~all"

 В даном примере будет проводится проверка SPF-записи домена example.com, а не example.org.
"exp" - использование даной опции позволяет задать сообщение о ошибке, которое будет передано отправителю при возникновении таковой. Размещается в конце SPF-записи, даже после опции all. Рассмотрим более детально механизм работы опции exp.
Допустим, что у домена example.org следущая SPF-запись:

example.org. IN TXT "v=spf1 +a +mx -all exp=spf.example.org"

Теперь содаем TXT-запись для домена spf.example.org:

spf.example.org. IN TXT "You host not allowed e-mail to me"

В результате этих шаманских действий SPF-запись будет контролировать, чтобы почта доставлялась только от валидных хостов, а всем остальным будет отправляться сообщение о ошибке, прописанное в TXT-записи домена spf.example.org.
На этой позитивной ноте, пожалуй, статью можно закончить. Азы использования SPF-записи описаны, а механизм работы можно изучить более детально при практическом использовании.


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

Настройка DMARC 
Чтобы настроить DMARC, необходимо в записи DNS домена добавить правила в виде TXT-записей. Название созданной записи должно быть «_dmarc.nazvanie_domena.ru», где «nazvanie_domena.ru» — это имя вашего домена.
 
В TXT-записи можно использовать следующие теги:

  • "v" - Версия протокола v=DMARC1 ОБЯЗАТЕЛЬНЫЙ параметр.
  • "p" - Правила для домена p= (none - не принимать никаких действий, quarantine - отправлять сообщения в спам, reject - не принимать сообщения) ОБЯЗАТЕЛЬНЫЙ параметр.
  • "aspf" - Режим проверки соответствия для SPF-записей aspf= (r (relaxed) - разрешать частичные совпадения, например субдоменов данного домена, s (strict) - разрешать только полные совпадения)
  • "adkim" - Режим проверки соответствия для DKIM-записей adkim= (r (relaxed) - разрешать частичные совпадения, например субдоменов данного домена, s (strict) - разрешать только полные совпадения)
  • "pct" - Уровень фильтрации сообщений в % (пример: pct=40%)
  • "sp" - Правила для субдоменов sp= (none - не принимать никаких действий, quarantine - отправлять сообщения в спам, reject - не принимать сообщения)
  • "rua" - Адреса для сводных отчетов (пример: rua=mailto:admin@test.ru)

(Если вы хотите получать отчеты (rua) на домен, который отличается от домена DMARC, необходимо разместить TXT запись для почтового домена специального вида. Например, если домен с DMARC — example.com, а получать отчеты вы хотите на домен test.ru, необходимо в DNS домена test.ru добавить следующую TXT-запись:
example.com._report._dmarc.test.ru со значением "v=DMARC1")

 

Примеры:

1. Отклонять все сообщения, не прошедшие проверку DMARC

"v=DMARC1; p=reject" 

2. Отклонять все сообщения, не прошедшие проверку DMARC, и отправлять все отчеты на ящик admin@test.ru

"v=DMARC1; p=reject; rua=mailto:admin@test.ru"

3. 30% сообщений, которые приходят от вашего домена, но не проходят проверки DMARC, помещаются в карантин

"v=DMARC1; p=quarantine; pct=30"


Есть вопросы или пожелания? demonik.0789@gmail.com

Сайт: https://asteriskperm.ru/

Группа ВК: ССЫЛКА (Заходим и вступаем! ;D)