SPF

В SPF записи мы указываем какие сервера имеют право отправлять почту
с вашего домена. В самом простом случае эта запись выглядит
следующим образом:

mydomain.ru. IN TXT «v=spf1 a mx ~all»
или/и (если NS позволяет создавать SPF записи)
mydomain.ru. IN SPF «v=spf1 a mx ~all»

Т.е. отправлять почту имеют право сервер с DNS записью в секции «a»
и почтовый сервер в секции «mx».

Составить свой вариант записи SPF поможет этот сервис — openspf.org
Опять проверяем результат через сервис centralops.net.

Подробно об SPF

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

Технические детали

Для размещения данных используется поле TXT в DNS. Так IANA
назначила DNS поле с кодом 99 для SPF. Формат SPF поля идентичен
TXT. Вообще, использование поля TXT не является оптимальным, но
проблема в том, что не всякий DNS сервер и клиент понимает новый SPF
тип записи. Поэтому совместное использование TXT и SPF считается
хорошим подходом, обеспечивающим совместимость и будущее развитие.
Стандарт рекомендует доменам, удовлетворяющим требованиям SPF, иметь
записи обоих типов. Вместе с тем, как минимум одна запись должна
присутствовать обязательно. В случае наличия двух записей они должны
быть идентичны. Например:
example.com. IN TXT «v=spf1 +mx a:colo.example.com/28
-all»
example.com. IN SPF «v=spf1 +mx a:colo.example.com/28 -all»
Если установлена запись SPF, то TXT записи должны быть
проигнорированы.

Механизм взаимодействия

Почтовый обмен с использованием SPF происходит по следующему
алгоритму.
Почтовый сервер mx.example.com отправляет письмо на адрес
user@example.net. В DNS записи example.com содержатся такие строки:
mx.example.com. IN A 208.77.188.166
example.com. IN MX 10 mx.example.com.
example.com. IN TXT «v=spf1 +mx -all»

Итак, mx.example.com устанавливает соединение с SMTP example.net и
получает от него, нечто вроде
>> 220 example.net ESMTP Service (Mailer v1.0)
ready at 30.07.2009 12:28:21 UTC
затем mx.example.com представляется через HELO/EHLO.
<< HELO mx.example.com
В зависимости от настроек принимающей стороны, после данного
представления уже может быть проверка на соответствие
представленного имени правилам SPF, но в данном месте это не
обязательно
>> 250 example.net Hello mx.example.com., pleased
to meet you
<< MAIL From:<user@example.com>
А вот в этом месте, после выдачи отправителем MAIL FROM должна
последовать обязательная проверка, интерпретация результата и
реакция на него.
В данный момент модуль, отвечающий за проверку SPF делает следующие
вещи. Осуществляется запрос к DNS. Запрашиваются SPF и TXT поля.
Если в полученном ответе присутствует правило SPF, то оно
разбирается и происходит анализ на соответствие. В нашем примере это
правило «v=spf1 +mx -all». Согласно правила проверяются MX записи, и
проводится сверка указанных в записях IP-адресов, полученного из
представления DNS-имени и IP-адреса подключившегося отправителя. В
данном случае все совпадает, управление возвращается почтовику, и он
начинает прием сообщения.

Если бы, вдруг, фактический IP подключившегося отправителя был иным,
то анализатор сообщил бы почтовику, что входящее сообщение не
валидно, и лучше бы его вообще не принимать, ну или на крайний
случай отмаркировать отдельно.
Формат записи
Запись SPF выглядит примерно так:
example.com. IN SPF «v=spf1 +mx a:colo.example.com/28
-all»

Эта запись содержит следующую информацию:
версия SPF — 1 (кстати, пока единственная используемая)
письмо может иметь отправителя с IP-адресом, соответствующим записям
в MX для домена example.com
письмо может иметь отправителя с IP-адресом, соответствующим одному
из адресов в подсети colo.example.com/28
Во всех остальных случаях, когда адрес не соответствует
перечисленным условиям, считать отправителя недостоверным.
Вообще, в условии есть 2 части — определитель и механизм.
Определители могут быть: «+» Pass, «-» Fail, «~» SoftFail, «?»
Neutral
Механизмы: all, include, A, MX, PTR, IP4, IP6, exists
Результатами проверки условий могут являться следующие определенные
результаты:

* None — означает, что либо в домене нет записей, либо
вообще не удается проверить домен. В общем никакого внятного
ответа не получено.

* Neutral — возникает в ситуации, когда хозяин домена не хочет
или не может сообщить разрешен ли IP. Этот результат должен
обрабатываться так же, как и None.

* Pass — означает, что все ОК и получатель может принять
письмо.

* Fail — явно указывает на то, что письмо принимать не
следует. Проверяющая сторона может отмаркировать письмо либо
отбросить.

* SoftFail — находится где-то между Fail и Neutral.
Принимающая сторона не должна отбрасывать письмо на основании
только этого результата.

* TempError — результат, возникающий, если клиент в момент
проверки получает временную ошибку. Сообщение можно принять
или временно отвергнуть.

* PermError — ошибка, возникающая при невозможности корректной
интерпретации DNS записей отправителя.
Возьмем, для примера, какой-нибудь реальный домен. Допустим
Google.com. Запрос TXT возвращает
«v=spf1 include:_netblocks.google.com ~all»

тут говорится, что нужно включить правила из записи
_netblocks.google.com. Интересно, что у _netblocks.google.com
отсутствует A-запись, а есть только TXT-запись. Вот она:
«v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19
ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17
ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20
ip4:207.126.144.0/20 ?all»

Тут перечислены подсети, в которых могут находится почтовые сервера
Google. Последний механизм all c определителем Neutral сообщает
анализатору о том, что адрес отправителя может быть не из
разрешенного диапазона. Письма из чужих адресных пространств
рекомендуется проверять дополнительно, а не отвергать безусловно.
Для такой масштабной структуры, как Google — это верное решение, ибо
в процессе работы адреса могут изменятся, например, при временном
отказе и переключении на резерв. И к тому же, адрес может меняться
пересылками.
Более хитрая SPF запись у Рамблера:
«v=spf1 ip4:81.19.66.0/23 ip4:81.19.88.0/24
-exists:%{ir}.spf.rambler.ru -exists:%{l}.u.spf.rambler.ru ~all»

тут указаны 2 подсети, из которых разрешено принимать почту, и 2
набора источников, почта с которых будет иметь результат проверки
Fail.

Проблема пересылки

Представьте себе следующую схему — пользователь отправляет письмо с
адреса vasily@xyz.com на pupkin@mylo.ru, а там стоит автоматический
форвардинг на pupkin@gmail.com. А у домена xyz.com прописано SPF
«v=spf1 +mx -all». В итоге, конечный получатель gmail.com сделает
проверку, и получит несовпадение адреса фактического отправителя с
указанным, и по правилам SPF не примет письмо. Для решения данной
проблемы существует SRS: Sender Rewriting Scheme. В двух словах —
происходит переписывание форвардером заголовка return-path.
Вообще, я считаю, что данный момент очень спорный. Использование
промежуточного ящика для перенаправления трафика на другой ящик
весьма напоминает спам-атаку. Вот, например, я регистрирую ящик,
свечу его везде, где только можно, подписываюсь на миллион рассылок,
и ставлю редирект на некий ящик, который я хочу завалить спамом. В
случае наличия у отправителей SPF и отсутствии SRS на пересылающем
почтовике — цель отвергнет эти потоки как спам, а вот при работающем
SRS он получит вполне «легитимные» потоки почты.

Заключение

SPF является простым и достаточно эффективным способом оценить
легитимность передаваемой почты. Администраторам почтовых серверов
стоит минимальных телодвижений добавление SPF записей в DNS.
Простота внедрения и поддержка основными популярными MTA делают
распространение SPF все шире и шире, что несет всем пользователям
электронной почты пользу, почтовым серверам снижение трафика и в
целом делает мир лучше 🙂

Оригинал статьи здесь https://geektimes.ru/post/63768/