антиспам-технология SPF — за и против

Технология верификации отправителя «Sender Permitted From» была предложена в 2003-м году. Спецификации несколько раз изменялись, последний вариант опубликован 11 июля 2004 года. Вместе со спецификациями менялось и название, так что сейчас технология называется «Sender Policy Framework». В январе 2004 г. о тестировании SPF объявила компания AOL, эта инициатива была поддержана и другими крупными участниками рынка.
Суть технологии заключается в следующем.
Администратор (владелец) домена публикует данные, описывающие возможные источники электронной почты с адресами отправителя из этого домена.
Почтовый сервер, принимающий e-mail с адресом отправителя из данного домена, может сопоставить реальный источник сообщения (IP-адрес стороны, посылающей почту) с данными, которые опубликовал владелец домена. Если IP-адрес посылающей стороны находится в списке рекомендованных, то сообщение рекомендовано принимать, в противном случае – не принимать.
Публикуемые владельцем домена данные далее будут называться SPF- записью или SPF-политикой (так как владелец домена фактически публикует рекомендуемую им политику обращения с e-mail в зависимости от IP-адреса посылающей сообщение стороны).

публикация SPF-политики

Если какой-то домен (его владелец/администратор) хочет поддержать SPF для верификации сообщений, исходящих из данного домена, то для этого в DNS-записи домена добавляется строка приблизительно такого вида:

domain.name. IN TXT "v=spf1 ip4:192.168.0.0/16 +a:www.another.domain.com -all"

Данный пример означает, что:
- поддержан протокол SPF версии 1 (v=spf1);
- почта с From: someuser@domain.name может приходить (рекомендовано принимать) с a) IP-адресов диапазона 192.168.0.0/16 (192.168.0.0- 192.168.255.255), b) сервера с именем www.another.domain.com.
- почта с From: из данного домена не может приходить (не рекомендовано принимать) более ниоткуда (-all).
В терминах технологии SPF, ‘ip4’, ‘a’, ‘all’ – это «механизмы» (mechanism), а префиксы (+,-,?,~) перед названием механизма так и называются «префиксы» (prefix).
Поддерживаются следующие механизмы:
- all – описывает весь диапазон IP-адресов;
- ip4:addresslist – диапазон адресов IPv4 в формате aa.bb.cc.dd или aa.bb.cc.dd/masklen (например ip4:127.0.0.1 или или ip4:127.0.0.0/8);
- ip6:addresslist – диапазон адресов IPv6 (аналогично ip4);
- a:hostname – все IP-адреса машины hostname;
- mx – все IP-адреса MX-серверов данного домена;
- ptr:domain – IP-адреса, PTR-записи которых указывают на domain;
- include:domain – ссылка на SPF-политику домена domain;
- exists:macro – позволяет с помощью макроязыка сконструировать сложное доменное имя, затем проверить его существование в DNS. Например, запись вида «exists: %{l}._spf.domain.name» для адреса отправителя вида user@domain.name развернется в user._spf.domain.name. Если на запрос полученного доменного имени вернется положительный ответ, значит механизм «сработал» («match»). Подробнее механизм exists описан в отдельном разделе ниже.
При анализе SPF-записи все механизмы перебираются слева направо, и если какой-то из них описывает IP-адрес посылающей сообщение стороны, то механизм «сработал». Тогда следует выполнить действие, рекомендуемое владельцем домена. Действия определяются префиксами перед механизмами:
+ (или отсутствие префикса) положительный префикс, сообщение рекомендуется принять;
- (минус) запрещающий префикс, сообщение принимать не рекомендуется;
~ – «нейтрально-отрицательный» префикс, означающий «адрес посылающей стороны может быть не в разрешенном диапазоне). Сообщение рекомендуется «не отвергать, но возможно, подвергнуть дополнительным проверкам;
? – «нейтральный» префикс, указывает на принципиальную неполноту данных (то есть владелец домена не может указать все IP-адреса источников почты из своего домена).
Кроме механизмов, определены следующие модификаторы:
- redirect:domainname – "подменяет" проверяемое доменное имя с домена отправителя на domainname;
- exp:строка – определяет диагностическое сообщение, выдаваемое при неприеме почты.
Таким образом, для поддержки SPF на посылающей стороне достаточно перечислить в DNS-записи все адреса почтовых серверов, посылающих почту "наружу", после чего протокол будет поддержан. Конечно, реализация сложных случаев (макросы с exists) потребует специального ПО, но для простых случаев exists не нужен.
SPF-записи помещаются в стандартные для DNS записи типа TXT, следовательно, никакой модификации программного обеспечения DNS-серверов и клиентов не требуется.

использование данных SPF при приеме почты

Принимающая сторона по получении MAIL FROM: user@domain.name в SMTP-сессии делает DNS-запрос, получает SPF-запись и сравнивает IP-адрес посылающей стороны SMTP-сессии с SPF-политикой. Результатом является рекомендация по приему или отвержению письма. Нужно сказать, что имеющиеся на сегодня общедоступные реализации фильтрации спама на базе технологии SPF на принимающей стороне воспринимают рекомендации буквально – отвергая сообщение, для которого сработал механизм с префиксом ‘-‘ и принимая в противном случае почту от отправителя.
Для поддержки SPF на этапе приема почты необходима модификация ПО почтового сервера. Необходимая функциональность реализована в библиотеке libspf2 (распространяется как OpenSource под лицензиями GNU и BSD – на выбор). Существуют также готовые наборы правок (патчей) и/или клиенты для большинства распространенных почтовых серверов (MTA).

проблемы технологии SPF

Помимо понятных достоинств, SPF и аналогичные технологии имеют весьма существенный недостаток: отправитель сообщения не знает его дальнейшего пути к получателю; если сообщение будет пересылаться (forward), то в процессе пересылки могут быть задействованы почтовые серверы, не указанные отправителем как разрешенные.
Другими словами и крупными буквами: ПРИ БУКВАЛЬНОМ ИСПОЛНЕНИИ SPF-ПОЛИТИКИ МОЖЕТ БЫТЬ ОТВЕРГНУТА НОРМАЛЬНАЯ ПОЧТА (НЕ СПАМ).
Эта проблема является настолько серьезной, что требует отдельного внимательного рассмотрения ниже.

верификация отправителя и пересылка почты

Сообщения электронной почты обычно пересылаются напрямую (end-to-end) от отправителя к получателю. Однако это не так в следующих случаях:
- прием получателем почты через резервный почтовый сервер (backup MX);
- пересылка почты на другой адрес (механизм forward).
Оба случая не являются редкими или экзотическими: резервные почтовые серверы предназначены для повышения надежности почтовых систем; пересылка почты с адреса на адрес является широко используемой, например, для сбора сообщений с нескольких адресов в один почтовый ящик.

резервные почтовые серверы

Резервные почтовые серверы используются для приема почты в случаях, когда основной почтовый сервер организации по каким-либо причинам недоступен. После восстановления доступности, резервный сервер доставляет почту на основной сервер. E-mail адрес отправителя при этом не изменяется.
Предположим, мы доставляем почту с user@sender.com на user@receiver.com через резервный сервер backup.receiver.com.
В момент приема на receiver.com будет проверяться SPF-политика домена отправителя (sender.com), а SMTP-сессия инициирована с backup.receiver.com. Но отправитель про резервные серверы получателя ничего не знает и адреса backup.receiver.com в своей политике не указал. В случае, когда для sender.com указана запретительная политика по умолчанию (-all), то receiver.com получает рекомендацию отвергнуть письмо.
Таким образом, для нормального приема почты с резервных серверов необходимо предпринять следующие действия:
1. Поддержка SPF должна быть включена не только на основном почтовом сервере, но и на всех резервных.
2. Основной почтовый сервер должен принимать почту с резервных серверов без SPF-проверки.
В случае штатной пересылки почты внутри организации (скажем, с входного почтового сервера под Unix в почтовую систему под Windows) проверка SPF должна быть включена только на входном сервере.
К сожалению, вышеперечисленные пожелания не всегда выполнимы. В частности, резервные почтовые сервера могут принадлежать другой организации (сервис-провайдеру или партнеру), которая не хочет реализовывать проверку SPF на них. В таких случаях, реализовать проверку SPF-политики для почты, приходящей через резервные серверы невозможно (на резервном сервере – отказываются, проверять во время получения почты с резервного сервера – не имеет смысла, так как отправитель про резервные серверы получателя ничего не знает).

пересылка почты

Пересылка (forward) почты используется в Интернете достаточно широко. Есть форвард-сервисы (обеспечивающие, например, "вечный" почтовый адрес), большинство бесплатных почт поддерживает пересылку, достаточно часто пересылку настраивают в частном порядке. Как правило, при пересылке сохраняется исходный адрес отправителя – это необходимо, в частности, для корректной доставки квитанций о недоставке письма (bounce messages).
Рассмотрим такую простую схему: пользователь user@sender.com шлет почту на user@mailbox.com, это сообщение пересылается "настоящему получателю" user@receiver.com).
Если домен sender.com опубликовал SPF-политику (например – "вся почта идет только с mail.sender.com"), а почтовый сервис на receiver.com ее проверяет, то данное письмо будет отвергнуто, так как политика отправителя (sender.com) не предполагает, что письмо может перепосылаться (с mailbox.com).
Эта проблема является ключевой при внедрении практически любой технологии верификации отправителя.
Естественно, ее нужно каким-то образом решать, и на сегодня предлагаются такие решения:
1. Использование SPF-механизма exists. Например, отправитель может указать SPF-политику вида “+exists %{l}._spf.domain.name” и на все DNS-запросы для адресов username._spf.domain.name отвечать положительно (возвращать какой-то адрес). Механизм сработает, принимающая сторона получит рекомендацию принять почту.
2. Изменение адреса отправителя при пересылке (например, SRS (Sender Rewriting Scheme). То есть пересылаемое в нашем примере письмо должно уйти на receiver.com как "что-то@mailbox.com".
3. Передача дополнительных данных о реальном отправителе в SMTP-сессии (см., например, документ MARID SMTP Service Extension for Indicating the Responsible Submitter of an E-mail Message).
4. Добавление дополнительных данных в заголовки письма при пересылке и извлечение их оттуда при приеме (описано, например, в спецификациях CallerID).
Достоинства и недостатки схемы с exists описаны в отдельном разделе ниже, а все остальные решения обладают очевидными недостатками:
1. Требуется модификация ПО на пересыльщике почты. Таким образом, идея плавного введения SPF в действие перестает работать: кроме поддержки SPF на отправителе и получателе, требуется обязательная модификация ПО на всех почтовых серверах, где может происходить пересылка почты от отправителя (опубликовавшего SPF-политику) к получателю (анализирующему SPF-политику).
2. Пересыльщик становится ответственным за пересланный спам. Другими словами, если на user@forwarder.com (см. пример) придет спам-сообщение, его отправитель будет подменен на что-то@mailbox.com. Во многих случаях такая подмена identity неприемлема, ибо с точки зрения обычного пользователя mailbox.com становится "спамером".

механизм exists

Механизм exists предназначен для «тонкого» (fine-grained) управления SPF-политикой отправителя. Суть механизма заключается в следующем:
1. Из домена отправителя, левой части адреса отправителя, IP-адреса посылающего сервера (и ряда других данных) получатель составляет доменное имя. Правила составления описываются в SPF-политике с помощью специального макроязыка.
2. Полученное доменное имя проверяется на существование в DNS.
3. Если имя существует, то механизм сработал; если не существует – не сработал.
Например, если в SPF-политике домена example.com присутствует строка ‘+exists:%{l}.%{i}._spf.example.com’, то для отправителя user@example.com и письма, посылаемого с адреса 127.0.0.1, будет составлено имя user.127.0.0.1._spf.example.com. Если на DNS-запрос для такого имени будет получен ответ, то письмо рекомендовано к получению.
Таким образом, отправитель может сформировать DNS-записи для всех существующих пользователей своего домена в поддомене _spf.example.com, опубликовать политику ‘+exists:%{l}._spf.example.com’ и таким образом разрешить пересылку (forward) всех писем для существующих пользователей и запретить – для несуществующих. При реализации такого подхода придется смириться со следующими трудностями:
- требуется либо поддерживать вручную в DNS-зонах списки возможных отправителей почты из домена, либо реализовать специализированное ПО для этой цели;
- если отправитель рассылает много почты (сервис бесплатной почты, например), либо спамеры рассылают много почты от его имени, то использование exists совместно с макросами (включающими IP или имя пользователя) создаст большую дополнительную нагрузку на DNS-серверы отправителя.
К сожалению, использование механизма exists создает и серьезные проблемы безопасности, как для отправителей, так и для получателей:
1. Возможность верификации списков адресов. Если реализация exists дает возможность удаленно отличить существующий адрес отправителя от несуществующего, то это дает спамерам возможность верификации баз данных адресов.
2. Возможность рассылки спама. Если реализация SPF-политики с механизмом exists разрешает пересылку почты, то эта же политика будет разрешать и спам – пусть и с валидными обратными адресами, так как верифицировать адреса можно через ту же политику. Ведь пересылку почты от user@domain невозможно отличить от посылки спама с поддельным отправителем user@domain.
3. Возможность отправителю следить за путем почты в системе получателя. Если недобросовестный отправитель создал SPF-политику с использованием exists и макросами %{l},%{i}, то при каждой проверке SPF-политики он будет получать данные:
- откуда пересылается письмо (расширение макроса %{i});
- куда пересылается письмо (по адресу, с которого пришел DNS- запрос);
- от какого пользователя пересылается письмо (по макросу l).

проблемы SPF – резюме

На сегодняшний день SPF является несовместимой с пересылками почты, так как оба варианта решения "проблемы пересылок" неудовлетворительны.
Протокол трудно ввести быстро и повсеместно. Мгновенное введение поддержки необходимых механизмов (подмены отправителя или расширений протокола SMTP) на всех (потенциальных) транзитных почтовых серверах представляется совершенно невероятным событием, а без такой поддержки будет либо теряться почта, либо будут появляться «дырки» для спама. Если же посылающие системы будут поддерживать либеральную политику ("?all"), то исчезает стимул к модификации пересылающих систем, так как почта при пересылках будет доставляться, а не отвергаться.
Использование SPF-механизма exists открывает очевидные дыры в безопасности (верификация наличия пользователей в домене, возможности слежения за путем письма), которые не могут считаться приемлемыми.

использование SPF для фильтрации спама

Механизм SPF разрабатывался, в первую очередь, как средство борьбы со спамом. Предполагается, что прямое следование объявленной SPF-политике домена поможет, по меньшей мере, не принимать письма с подделанным адресом доменов, поддержавших SPF, как почтовых служб, так и других организаций.
Рассмотрим подробнее, так ли это.

использование SPF как "белого списка"

Как следует из схемы работы SPF, сообщение рекомендовано принимать, если в SPF-политике указано, что с данного IP возможна посылка сообщения с данным адресом отправителя. По всей видимости, для таких сообщений должны быть ослаблены или выключены антиспам-фильтры (а в чем иначе может заключаться использование разрешительных SPF-политик?).
Если же такая схема будет кем-либо реализована, то возможны следующие приемы ее недобросовестного использования:
- регистрация большого числа доменов с корректными SPF-записями вида +all или +ip:большой-диапазон-адресов и рассылка спама с From: из этих доменов. При текущих расценках на спам-рассылки, данная схема экономически оправдана даже при относительно небольших объемах рассылки – несколько миллионов сообщений на новый домен (домен стоит $10-15, рассылка – порядка $100 за миллион сообщений). Кроме платных доменов 2-го уровня могут быть также использованы бесплатные (3-го и более уровней);
- использование спамерами для фальсификации адреса отправителя существующих чужих доменов с либеральной SPF-политикой, в которой указано +all.
Таким образом, принимать на веру чужую разрешительную SPF-политику никак нельзя (особенно, если в ней записано +all, +ptr или указан широкий диапазон адресов).
С другой стороны, наличие объявленной SPF-политики у крупных игроков рынка (таких как AOL и Hotmail) может сильно помочь отличить "настоящую" почту этих систем от "поддельной". Следовательно, чужие SPF-политики придется использовать выборочно (AOL используем, а super- puper-spamer.da.ru – не используем).
Итак, возникает задача отбора «хороших» SPF-политик, ведения списка «хороших доменов» (вручную или через репутационные сервисы) и построения прочей необходимой инфраструктуры работы с SPF.

использование SPF как "черного списка"

Использование запрещающих SPF-политик (использование модификатора «-») ведет к уменьшению количества принимаемой почты (иначе, в чем тогда состоит запрещение?). Среди непринятой почты обязательно будет спам, а значит – количество дошедшего до получателей спама – уменьшится.
В то же время, потери пересылаемой почты в данной схеме – возможны и обязательно будут. Другими словами, жесткие SPF-политики ("-all") можно использовать, только если есть абсолютная уверенность в отсутствии пересылок почты или в том, что все транзитные системы поддерживают SPF в том или ином виде (подмена отправителя, расширения SMTP-протокола).

проблемы производительности

Каждая проверка SPF-записи – это как минимум одно обращение к системе DNS, а при использовании механизмов "a", "ptr", "include","exists" возникают дополнительные обращения. Спецификация SPF явно указывает, что предельное количество обращений при проверке одного сообщения не должно превышать 20.
Как известно по опыту эксплуатации RBL (которые тоже реализованы поверх механизма DNS), в условиях высокой загрузки почтовой системы добавление каждого нового RBL-сервиса (т.е. дополнительного DNS-запроса на каждое сообщение) заметно ухудшает ситуацию. Крупные почтовые системы вынуждены эксплуатировать локальные копии баз данных RBL, ибо дополнительные DNS-обращения становятся неприемлемыми с точки зрения нагрузки. А если какой-то DNS-сервер не отвечает, то это может означать остановку прохождения почты (DNS-таймаут может составлять 75-90 секунд, такое ожидание при потоке почты в сотни сообщений в секунду абсолютно неприемлемо).
Заметим, что самостоятельное создание системными администраторами всего мира локальных копий SPF-записей для всех имеющихся доменов представляется абсолютно нереальным. Конечно, очень большая доля почты приходит с крупных почтовых сервисов и из крупных компаний, поэтому DNS-запросы к SPF будут повторяться, а значит, ситуация несколько облегчится за счет кэширования ответов DNS.
В то же время, при использовании механизма exists, каждое новое письмо может порождать уникальное имя домена и соответственно – запрос, который не был сохранен в DNS-cache ранее.
По мере распространения SPF в мире проблема количества DNS-запросов будет усугубляться, в пределе – каждое принимаемое и отправляемое сообщение будет вызывать DNS-запросы к SPF-политике, что потребует дополнительного оборудования на крупных почтовых системах и в больших корпорациях.

выводы и рекомендации

Очевидно, что публикация SPF-записей не может ухудшить ситуацию со спамом. В то же время, слишком жесткая политика может приводить к потерям исходящей из вашей системы почты в процессе транзитной пересылки. Таким образом, можно рекомендовать публикацию SPF- политики с учетом следующих соображений:
1. Политика должна завершаться на "?all", таким образом для пересылаемых писем ситуация не ухудшается, ибо ?all отвечает положению дел «без SPF».
2. Политика должна описывать все используемые исходящие адреса, если забыть какой-то исходящий сервер, то почта с него может необоснованно посчитаться спамом.
3. Механизм exists должен использоваться только при крайней необходимости, так как он порождает массу дополнительных проблем.
Буквальное следование чужим SPF-политикам может привести как к потерям почты, так и к пропускам спама. Таким образом, может быть рекомендовано использование SPF-данных как дополнительной информации для антиспам-фильтров, но окончательное решение о пропуске или отвержении сообщения только на основании SPF принимать не следует.

редакционное послесловие

Вниманию тех, кого заинтересовала тема данной статьи. В следующем номере будет опубликовано продолжение темы: практический опыт использования SPF, а также дискуссионный материал «Для чего нужен SPF», опровергающий некоторые тезисы, представленные в сегодняшнем материале.

Алексей Тутубалин, ЗАО «Ашманов и Партнеры». Впервые опубликовано наwww.webplanet.ru.