SPF – Sender Policy Framework

Автор: spions on 16 августа 2016

SPF-Diagram_thumb1

SPF – Sender Policy Framework (инфраструктура политики отправителя).

Расширение протокола SMTP SPF представляет из себя текстовую запись в TXT-записи DNS домена, благодаря которой можно проверить, не подделан ли домен отправителя. Владелец домена может указать для домена специальным образом сформированную TXT строку, указывающую список серверов, имеющих право отправлять почту от имени этого домена и механизм обработки писем, отправленных от других серверов. SPF определен в RFC 7208.

Рассмотрим простой пример 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-запись не наследуется на поддомены. Для каждого домена третьего (и ниже) уровней необходима своя запись;
  • SPF проверяет только HELO и MAIL FROM поля.

Более сложный пример:

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:example.org/24 -all"
example.org. IN TXT "v=spf1 ptr:example.org exist:example.org -all"

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

  • «mx/24» — в список разрешенных отправителей входят все IP-адреса, находящихся в тех же сетях класса С, что и MX сервера домена;
  • «a:example.org/24» — в список разрешенных отправителей входят все IP-адреса, находящихся в тех же сетях класса С, что и А-записи домена example.org;
  • «-all» — всех остальных отправителей — блокируем;
  • «ptr» — проверяет PTR-запись IP-адреса отправителя. Если она сходится с указанным доменом, то механизм проверки выдает положительный результат. То есть, разрешено отправлять всем IP-адресам, PTR-запись которых направлены на указанный домен.
  • «exists» — выполняется проверка, резолвится ли домен на какой-либо IP-адрес.

Опции: redirect и exp.

  • «redirect» — указывает получателю, что нужно проверять SPF-запись указного домена, вместо текущего домена.
example.org. IN TXT "v=spf1 redirect:example.com ~all"

В данном примере будет проводится проверка SPF-записи домена «example.com», а не «example.org».

  • «exp» — использование данной опции позволяет задать сообщение о ошибке, которое будет передано отправителю при возникновении таковой. Размещается в конце SPF-записи.

Допустим, что у домена 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-записи необходимо прописать все сервера, отправляющие письма в интернет, в том числе web-сервера и внешние системы. Если этого не сделать можно потерять часть писем;
  • Необходимо правильно выбирать механизм обработки писем (Pass, Fail, SoftFail, Neutral). При безусловной переадресации вашего письма из одной почтовой системы в другую может возникнуть проблема, так как SPF проверяет только последний «хоп»;
  • Рекомендуется создавать SPF-записи для всех доменов второго уровня, которые принадлежат вам или вашей компании, даже если вы не отправляете от их имени письма. Для таких доменов желательно использовать простую запись «v=spf1 -all», которая говорит, что никто не можем отправлять письма от этих доменов;
  • Домены третьего уровня защитить можно с помощью wildcard-записи типа «*.example.com. IN TXT «v=spf1 -all»». Но, обратите внимание на то, что wildcard работает только для несуществующих поддоменов. Например, если у вас есть поддомен moscow.example.com с MX-записями, запись «*.example.com. IN TXT «v=spf1 -all»» не будет на нее распространяться. Подробнее описано в статье на Wikipedia и RFC 1034.

    Moreover, the wildcard is matched only when a domain does not exist, not just when there are no matching records of the type that has been queried for. Even the definition of «does not exist» as defined in the search algorithm of RFC 1034 section 4.3.2 can result in the wild card not matching cases that one might expect with other types of wildcards.

  • SPF-записи рекомендуется создавать не только для доменов, но и для почтовых серверов, которые занимаются отправкой писем в интернет. Это необходимо, чтобы пройти HELO/EHLO Test принимающего сервера. Стандартная запись: «mx.example.com. IN TXT «v=spf1 a -all»»;
  • Если у вас много доменов, которые обслуживаются несколькими основными MX-серверами, то советую использовать механизм «redirect». Например, основной домен «example.com» имеет SPF-запись «v=spf1 +a +mx -all», то остальным доменам (example1.com, example2.com и т.д.), для упрощения обслуживания, можно прописать запись «v=spf1 redirect=example.com»;
  • Если у вас много доменов и много почтовых серверов отправителей, распределенных географически и организационно, то можно использовать механизм «include» и отдельную зону «_spf.example.com». Как пример можно посмотреть запись для домена gmail.com – «v=spf1 redirect=_spf.google.com»;
  • Кроме защиты своих доменов рекомендуется защитить свою почтовую систему и пользователей, включив проверку SPF/DKIM/DMARC записей на ваших внешних почтовых серверах.

Полезные ссылки:
Тестирование SPF-записи
Анализ письма анти-спам фильтром SpamAssassin
Много полезных тестов (MX, SPF, Blacklist, DKIM Lookup и т.д.)

Источники:
https://habrahabr.ru/post/270159/
http://muff.kiev.ua/content/spf-zapis-proveryaem-validnost-otpravitelya

Категория: Администрирование
«
»
Вы можете оставить комментарий ниже.