Интересное ограничение существует в RFC 7208 относительно протокола SPF и заключается оно в выполнении максимум 10 DNS-запросов для одной записи. Иными словами, если внутри SPF-записи присутствует много DNS-зависимых директив, по которым проверяющий сервер должен делать дополнительные запросы, то после достижения 10 запросов вы получите ошибку.
В статье ниже проверим как это ограничение работает на практике.
Если вам интересна тематика почтовых серверов, рекомендую обратиться к соответствующей рубрике на моем блоге — Mail Servers.
10 DNS-запросов для одной SPF-записи
SPF-запись защищает нас от подделки адреса отправителя, позволяя авторизовать отправляющий сервер. То есть, определить разрешено ли данному серверу отправлять почту для домена, указанного в заголовке MAIL FROM или в приветствии HELO/EHLO. С точки зрения оценки спам-рейтинга сообщения функционал очень полезный, хоть он и не рассчитан на принятие однозначного решения о блокировке по результатам проверки.
Прочитать подробнее о SPF вы можете в основной статье — SPF-запись для почтового сервера. Также рекомендую к изучению:
А я перехожу к небольшой порции теории.
Теория
После получения SPF-записи для домена необходимо извлечь из неё список ip-адресов, с которых разрешена рассылка почты. Если вся запись состоит из директив ip4/ip6, то процесс на этом и заканчивается (ведь они уже содержат адреса/подсети в чистом виде). Если же внутри записи присутствуют DNS-зависимые директивы (include, a, mx, ptr, exists), то необходимо выполнить дополнительные запросы к сервису DNS.
Все бы ничего, но протокол явно ограничивает максимально допустимое количество DNS-запросов для одной записи SPF 1:
SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS.
Разумеется это сделано во благо, но для администраторов почтовых сервисов (в особенности распределенных, со сложной топологией) это ограничение заставляет с умом подходить к процессу создания и поддержки SPF-записи.
Рекомендации
Исходя из ограничений протокола, большинство рекомендаций вполне очевидны, но есть и некоторые нюансы, которые заставляют быть более внимательными.
- Первая и главная рекомендация — поддерживайте SPF-запись настолько короткой, насколько это возможно.
- Располагайте директивы ip4/ip6 в начале записи, а остальное — в конце.
- И последняя — если включаете в запись директиву mx, то примите во внимание, что А-записи, на которые указывает MX, тоже входят в лимит 10 запросов DNS на одну SPF.
Если говорить о лимитах, то не лишним будет напомнить, что для создания TXT-записей существует ограничение в 255 символов, в которое вы можете упереться раньше, чем в 10 DNS-зависимых директив. Тем не менее, оно легко обходится 2 путем создания составной записи.
Проверка
Лично мне захотелось проверить последнее ограничение на практике и я создал MX-запись, которая указывает на кучу А-записей.
MX выглядит вот так:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
# dig -t MX bq-srv.ru @8.8.8.8 +short 10 a3.bq-srv.ru. 20 mail.bq-srv.ru. 10 a5.bq-srv.ru. 10 a7.bq-srv.ru. 10 a13.bq-srv.ru. 10 a14.bq-srv.ru. 10 a15.bq-srv.ru. 10 a9.bq-srv.ru. 10 a12.bq-srv.ru. 10 a1.bq-srv.ru. 10 a10.bq-srv.ru. 10 a6.bq-srv.ru. 10 a8.bq-srv.ru. 10 a4.bq-srv.ru. 10 a2.bq-srv.ru. 10 a11.bq-srv.ru. |
Из всех записей только mail.bq-srv.ru указывает на реальный сервер, а остальные вообще не существуют, но это неважно.
А это SPF:
|
1 2 |
# dig -t TXT bq-srv.ru @8.8.8.8 +short "v=spf1 mx ~all" |
Если попробовать отправить почту с этого сервера, то она будет успешно доставлена. Возможно попадет в спам, но принимающий сервер вероятнее всего её пропустит. Попробуем:
|
1 2 3 |
Authentication-Results: mxs.mail.ru; spf=pass (mx175.mail.ru: domain of bq-srv.ru designates x.x.x.x as permitted sender) smtp.mailfrom=e.vasilev@bq-srv.ru smtp.helo=mail.bq-srv.ru; dkim=pass header.d=bq-srv.ru Received-SPF: pass (mx175.mail.ru: domain of bq-srv.ru designates x.x.x.x as permitted sender) client-ip=x.x.x.x; envelope-from=e.vasilev@bq-srv.ru; helo=mail.bq-srv.ru; |
Почему spf=pass?!
Важно помнить, что DNS-сервер будет выдавать записи в разном порядке и именно в таком виде их будет обрабатывать проверяющий SPF-запись сервер. Если mail.bq-srv.ru окажется выше десятой позиции, то spf=pass, если ниже, то spf=fail. Повторим попытку и будем надеяться, что в этот раз «повезет»:
|
1 2 3 |
Authentication-Results: mxs.mail.ru; spf=permerror (mx179.mail.ru: error in processing during lookup of domain of bq-srv.ru: Mechanisms used too many DNS lookups) smtp.mailfrom=e.vasilev@bq-srv.ru smtp.helo=mail.bq-srv.ru; dkim=pass header.d=bq-srv.ru Received-SPF: permerror (mx179.mail.ru: error in processing during lookup of domain of bq-srv.ru: Mechanisms used too many DNS lookups) client-ip=x.x.x.x; envelope-from=e.vasilev@bq-srv.ru; helo=mail.bq-srv.ru; |
Вот теперь получили что ожидали — spf=permerror, как и написано в RFC:
SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return «permerror».
Если перед записью MX внутри SPF у вас будут любые другие DNS-зависимые директивы, то на лимит в 10 записей вы нарветесь быстрее. В любом случае, если вдруг будете попадать на spf=permerror, вспомните об этом ограничении (а если попросите у принимающей стороны логи, то увидите ошибку — Mechanisms used too many DNS lookups). Успехов!
comments powered by HyperComments