«DNS и BIND»

5. DNS и электронная почта

DNS и идентификация отправителей электронной почты

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

Структура сети отправителя (Sender Policy Framework)

Рассмотрим технологию SPF (Sender Policy Framework, структура сети отправителя), во-первых, потому, что она представляет наиболее популярный механизм идентификации, а во-вторых, потому, что она достаточно проста в описании. SPF позволяет почтовому администратору - возможно, при содействии его приятеля, администратора DNS, - указывать, каким почтовым серверам разрешено посылать почтовые сообщения из доменов организации. В каком-то смысле функция SPF противоположна назначению MX-записей: MX-запись сообщает почтовой программе, что почту, адресованную определенному домену, следует посылать на определенные почтовые серверы, в то время как SPF сообщает почтовой программе, какие почтовые серверы могут посылать почту из определенного домена.[1]

Приведем простой пример. Допустим, почтовый администратор компании O'Reilly Media знает, что все нормальные электронные сообщения из домена oreilly.com отправляются через один из двух SMTP-серверов, smtp1.oreilly.com и smtp2.oreilly.com. Он может сообщить об этом факте посредством DNS, создав TXT-запись для доменного имени oreilly. com (или попросив администратора зоны oreilly.com сделать это). Вот так может выглядеть соответствующая TXT-запись:

oreilly.com. IN TXT "v=spf1 +a:smtp1.oreilly.com +a:smtp2.oreilly.com -all"

Выражение v=spf1 в начале данных этой записи указывает, что данная TXT-запись является записью SPF. Необходимость явно указывать назначение записи возникает потому, что записи типа TXT могут применяться для многих целей, включая и передачу комментариев для чтения людьми, а мы не хотим, чтобы почтовые серверы сети Интернет попытались интерпретировать наши комментарии как инструкции SPF. Если технология SPF получит широкое распространение, ей в конечном итоге будет назначен собственный тип записей, SPF, и выражение v=spfl станет ненужным.

Следующие два поля указывают, что почта, исходящая от oreilly.com, может поступать лишь с IP-адресов, относящихся к узлам сети smtp1.oreilly.com и smtp2.oreilly.com. Знак « + » здесь обозначает, что почту разрешено принимать c IP-адресов этих узлов. Символов, управляющих политикой передачи, четыре:

+ Разрешить. Отправитель, соответствующий записи, является допустимым.
-  Отказать. Отправитель, соответствующий записи, не является допустимым.
~ Мягкий отказ. Отправитель, вероятно, не является допустимым, поэтому сообщение следует подвергнуть пристальному рассмотрению.
? Нейтральная реакция. Не выполнять специальных действий.

По умолчанию принимается режим « + » (разрешить), так что в данном примере знак « + » можно было бы опустить. Последнее поле, содержащее ключ -all, предписывает почтовым программам отказывать любым другим отправителям электронной почты из домена oreilly.com. Существуют другие способы указать узлы, которым разрешено отправлять почту с домена. Поскольку в MX-записях oreilly.com уже указаны серверы smtp1.oreilly.com и smtp2.oreilly.com, почтовый администратор может применить более короткую TXT-запись:

oreilly.com. IN TXT "v=spf1 +mx -all"

Без двоеточия и аргумента в виде доменного имени «механизмы», такие как a и mx, используют доменное имя из поля владельца. Таким образом, просто +mx имеет тот же эффект, что +mx:oreilly.com для данной записи.

Вот перечень распространенных механизмов, применяемых в записях SPF TXT:

mx
Указывает доменное имя, почтовым маршрутизаторам которого разрешается посылать почту, исходящую от домена-владельца.

ip6
Указывает №у6-адреса почтового сервера, которому разрешено отправлять почту, исходящую от домена-владельца. Также позволяет указывать сети IPv6 в нотации RFC 3513.

Кроме того, записи SPF поддерживают модификатор redirect, который позволяет распространять набор инструкций SPF на несколько доменных имен. Допустим, администратор oreilly.com хочет, чтобы для доменных имен ca.oreilly.com и ma.oreilly.com применялись те же правила, что и для oreilly.com. Чтобы обойтись без дублирования TXT-записи для oreilly.com, он может добавить такие TXT-записи:

ca.oreilly.com. IN TXT "v=spf1 redirect=oreilly.com"
ma.oreilly.com. IN TXT "v=spf1 redirect=oreilly.com"

Эти записи сообщают почтовым программам, что определить допустимых отправителей почты для доменов ca.oreilly.com и ma.oreilly.com можно, обратившись к SPF-записям для oreilly.com. Теперь, если администратору потребуется изменить инструкции SPF, достаточно внести изменения лишь в одну TXT-запись.

Механизм include действует схожим образом, позволяя администраторам ссылаться на созданные другими администраторами инструкции SPF. К примеру, если администратору oreilly.com требуется разрешить всем допустимым отправителям электронной почты из isp.net отправлять также и почту из oreilly.com, он может модифицировать TXT-запись для oreilly.com следующим образом:

oreilly.com. IN TXT "v=spf1 +mx include:isp.net -all"

Обратите внимание, что разделителем между ключевым словом include и его аргументом служит двоеточие, тогда как разделителем для ключевого слова redirect и его аргумента является знак равенства.

Пара советов по теме. Разумно использовать конструкцию ?all или ~all в начале записей SPF, поскольку задача перечисления всех допустимых отправителей почты из вашего домена может оказаться на удивление сложной. В вашей компании могут быть работающие удаленно сотрудники, у которых собственные почтовые серверы, мобильные сотрудники, отправляющие сообщения с КПК, и многое другое. Нехорошо будет лишать этих людей возможности отправлять почту.

Если ваши записи SPF очень длинные и сложные, они могут превысить максимально допустимую длину данных для записи TXT, которая составляет 255 байт. В этом случае вы можете разбить запись на несколько записей TXT, каждая из которых начинается с конструкции v=spf1. Записи будут объединены перед применением.

Пара предупреждений напоследок. Помните, что только почтовые серверы, поддерживающие SPF, будут обращать внимание на опубликованные вами инструкции SPF. На данный момент это очень небольшой процент почтовых программ сети Интернет. (Тем не менее вреда от опубликования SPF-записей никакого нет, так что почему бы и нет?) И помните, что технология SPF может измениться, может так и не стать стандартом или ей на смену могут прийти другие механизмы.

[1] Более того, SPF произошла от проекта с названием «Reverse MX» (обратные MX) за авторством Гадмута Даниша (Hadmut Danisch).