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

Содержание:

1. Верификация отправителя и проблема спама

2. Описание технологии SPF

    2.1 Общие принципы

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

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

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

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

        2.4.2 Механизм exists

        2.4.3 Проблемы SPF — краткое резюме

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

        2.5.1 Использование SPF как списка разрешенных

        2.5.2 Использование SPF как списка запрещенных

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

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

        2.6.1 Публикация SPF-записей

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

3. Опыт практической эксплуатации SPF

    3.1 Описание эксперимента

    3.2 SPF как фильтр спама

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

    3.4 Выводы из экспериментов

4. Заключение

1. Верификация отправителя и проблема спама

Говоря о проблеме спама («мусорной почты») необходимо прежде всего определить обсуждаемое явление. В данной статье под спамом понимаются «анонимные массовые рассылки электронной почты, как правило, имеющие рекламный характер». Данное определение удовлетворительно определяет спам как массовые рекламные рассылки, производимые профессионалами для зарабатывания денег. А ровно от этого бизнеса сейчас и страдают все пользователи Интернета. Прочая «нежелательная почта» (технические сообщения систем электронной почты, неанонимные рассылки с возможностью отписки, поздравительные открытки, посланные по ошибке письма) в данной статье как «спам» не рассматривается.

Анализ технических данных приходящего спама показывает такие особенности:

• Подавляющее количество спама приходит с захваченных спамерами (зараженных вирусами) пользовательских машин (преимущественно, подключенных к Интернету по высокоскоростному соединению — ADSL, Cable internet и так далее).
• Практически весь спам имеет поддельную техническую информацию, в частности:
  1. Поддельный отправитель — в качестве отправителя указан E-mail адрес, скорее всего, не имеющий никакого отношения к компьютеру отправителя.
  2. Поддельные заголовки — в которые вставлены, например, лишние строки Received, из которых следует, что письмо, якобы, было порождено не на том почтовом сервере, с которого на самом деле пришло.
  3. Достаточно часто выдается и поддельный параметр SMTP HELO — сообщаемое в нем имя машины не имеет никакого отношения к тому IP-адресу, с которого идет SMTP-соединение.
• Спам является распределенным явлением — источников спама в мире миллионы, множество рассылающих машин постоянно пополняется при помощи компьютерных вирусов, троянских программ и подобных средств. Ежедневно регистрируются десятки тысяч новых IP-адресов рассылающих машин.
• Часть источников спама постоянно меняет свои IP-адреса т.к. это пользовательские компьютеры, получающие адрес динамически у своего провайдера.

Таким образом, складывается неутешительная картина — фильтрация по спискам запрещенных (RBL) не дает достаточно хорошего результата (так как в большинство списков RBL адрес отправителя попадает уже постфактум — по факту рассылки), при этом количество ложных срабатываний (ложной классификации нормальных E-mail сообщений как спама) при использовании RBL составляет до единиц процентов. Подробнее см. статью автора «RBL-вред или польза»).

Раз фильтрация по IP-адресам работает плохо, то у разработчиков и администраторов антиспам-систем возникает понятное желание верифицировать другие параметры, передаваемые в SMTP-сессии: адрес отправителя и/или данных, предоставляемых в SMTP HELO. Для анализа этих данных не нужен доступ к тексту сообщения, «плохие» письма можно отвергать, не принимая их.

К несчастью, протокол SMTP не предполагает верификации отправителя. Такие средства нужно разработать, обсудить, протестировать, принять как стандарт и повсеместно внедрить. За последний год было предложено около десятка различных технологий верификации отправителя. На сегодняшний день наибольшую известность получила технология SPF («Sender Policy Framework», ранее она называлась «Sender Permitted From»).

Помимо известности, началось ее относительно массовое внедрение, в том числе и у крупнейших игроков интернет-рынка (AOL, Google, Altavista, Earthlink и т.д.). В последние месяцы отмечена и активная PR-компания, нацеленная на всех пользователей Интернета: крупные игроки рынка сообщают о разработке (или процессе разработки) или внедрении (или начинающемся внедрении) подобных механизмов. Таким образом, создается впечатление, что проблема спама если и не решена окончательно, то скоро будет решена (и именно тем или иным способом верификации отправителя).

Все предлагаемые технологии верификации отправителя на сегодня имеют статус «предварительное описание» (в виде «internet draft» или RFC); в качестве общепринятых стандартов будут приняты одна или две технологии. Наибольшие шансы стать общепринятыми имеют SPF (как получившая относительно широкое распространение) и SenderID (технология, поддерживаемая Microsoft).

На сегодняшний день вопрос о поддержке той или иной технологии в рамках отдельно взятой почтовой системы может быть сформулирован так:

• Что выбрать: какой из имеющихся механизмов верификации внедрять (если внедрять);
• Какова эффективность метода: приведет ли это к заметным улучшениям при решении основной задачи — фильтрации спама;
• Каковы риски: не будет ли при этом отфильтрована «нормальная» почта (входящая или исходящая);
• Какова трудоемкость внедрения: понадобится ли дополнительное ПО или изменение имеющегося.

Далее в статье вопрос, «какой механизм внедрять» не обсуждается, поскольку на сегодня поддержка в программном обеспечении реализована только для SPF. Ответу на остальные три вопроса (эффективность, риски, трудоемкость) и посвящена данная статья.

2. Описание технологии SPF

2.1. Общие принципы

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

Суть технологии заключается в следующем:

• Администратор (владелец) домена публикует данные, описывающие возможные источники электронной почты с адресами отправителя из этого домена.
• Почтовый сервер, принимающий E-mail с адресом отправителя из данного домена, может сопоставить реальный источник сообщения (IP-адрес стороны, посылающей почту) с данными, которые опубликовал владелец домена. Если IP-адрес посылающей стороны находится в списке рекомендованных, то E-mail сообщение рекомендовано принимать, в противном случае — не принимать.

Публикуемые владельцем домена данные далее будут называться SPF-записью или SPF-политикой (так как владелец домена фактически публикует рекомендуемую им политику обращения с E-mail в зависимости от IP-адреса посылающей сообщение стороны).

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

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

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

Данный пример означает:

1. Поддержан протокол SPF версии 1 (v=spf1);
2. Почта с From: someuser@domain.name может приходить (рекомендовано принимать) с:
3. 1. IP-адресов диапазона 192.168.0.0/16 (192.168.0.0-192.168.255.255)
   2. Сервера с именем www.another.domain.com
4. Почта с From: из данного домена не может приходить (не рекомендовано принимать) более ниоткуда (-all).

В терминах технологии SPF, ‘ip4’, ‘a’, ‘all’ — это «механизмы» (mechanism), а префиксы (+,-,?,~) перед названием механизма так и называются «префиксы» (prefix).

Поддерживаются такие механизмы (подробнее см. описание формата записей SPF):

• 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 серверов и клиентов не требуется.

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

Принимающая сторона по получении MAIL FROM: user@domain.name в SMTP-сессии делает DNS-запрос, получает SPF-запись и сравнивает IP-адрес посылающей стороны SMTP-сессии с SPF-политикой. Результатом является рекомендация по приему или отвержению письма. Нужно сказать, что имеющиеся на сегодня общедоступные реализации фильтрации спам-почты на базе технологии SPF на принимающей стороне воспринимают рекомендации буквально — отвергая сообщение, для которого сработал механизм с префиксом «-» и принимая в противном случае почту от отправителя.

Для поддержки SPF на этапе приема почты необходима модификация ПО почтового сервера. Необходимая функциональность реализована в библиотеке libspf2 (распространяется как OpenSource под лицензиями GNU и BSD — на выбор). Существуют также готовые наборы правок (патчей) и/или клиенты для большинства распространенных почтовых серверов (MTA).

Резюме

Поддержка SPF на стороне отправителя: публикация SPF-политики домена может быть (в простом случае) произведена очень быстро, это не требует каких-либо существенных затрат.

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

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

2.4. Проблемы технологии SPF

Помимо понятных достоинств, SPF и аналогичные технологии имеют весьма существенный недостаток: отправитель сообщения не знает его дальнейшего пути к получателю; если сообщение будет пересылаться (forward), то в процессе пересылки могут быть задействованы почтовые серверы, не указанные отправителем как разрешенные.

Другими словами и крупными буквами:

ПРИ БУКВАЛЬНОМ ИСПОЛНЕНИИ SPF-ПОЛИТИКИ МОЖЕТ БЫТЬ ОТВЕРГНУТА НОРМАЛЬНАЯ ПОЧТА (НЕ СПАМ).

Эта проблема является настолько серьезной, что требует отдельного внимательного рассмотрения ниже.

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

Сообщения электронной почты обычно пересылаются напрямую (end-to-end) от отправителя к получателю. Однако это не так в следующих случаях:

• Прием получателем почты через резервный почтовый сервер (backup MX);
• Пересылка почты на другой адрес (механизм forward).

Оба случая не являются редкими или экзотическими: резервные почтовые серверы предназначены для повышения надежности почтовых систем; пересылка почты с адреса на адрес является широко используемой, например, для сбора сообщений с нескольких адресов в один почтовый ящик.

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

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

E-mail адрес отправителя при этом не изменяется.

Предположим, мы доставляем почту с user@sender.com на user@receiver.com через резервный сервер backup.receiver.com:

Sender.com -> backup.receiver.com -> 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).

Рассмотрим такую простую схему:

(From)user@sender.com -> (To)user@mailbox.com (Forward) -> user@receiver.com

(пользователь user@sender.com шлет почту на user@mailbox.com, это сообщение пересылается «настоящему получателю» user@receiver.com).

Если домен sender.com опубликовал SPF-политику (например — «вся почта идет только с mail.sender.com»), а почтовый сервис на receiver.com ее проверяет, то данное письмо будет отвергнуто, так как политика отправителя (sender.com) не предполагает, что письмо может перепосылаться (с mailbox.com).

Эта проблема является ключевой при внедрении практически любой технологии верификации отправителя.

Естественно, ее нужно каким-то образом решать, и на сегодня предлагаются такие решения:

• Использование SPF-механизма exists. Например, отправитель может указать SPF-политику вида «+exists %{l}._spf.domain.name» и на все DNS-запросы для адресов username._spf.domain.name отвечать положительно (возвращать какой-то адрес). Механизм сработает, принимающая сторона получит рекомендацию принять почту.
• Изменение адреса отправителя при пересылке (например, SRS — Sender Rewriting Scheme). То есть пересылаемое в нашем примере письмо должно уйти на receiver.com как «что-то@mailbox.com».
• Передача дополнительных данных о реальном отправителе в SMTP-сессии (см., например, документ MARID SMTP Service Extension for Indicating the Responsible Submitter of an E-mail Message).
• Добавление дополнительных данных в заголовки письма при пересылке и извлечение их оттуда при приеме (описано, например, в спецификациях CallerID).

Достоинства и недостатки схемы с exists описаны в отдельном разделе ниже, а все остальные решения обладают очевидными недостатками:

1. Требуется модификация ПО на пересыльщике почты. Таким образом, идея плавного введения SPF в действие перестает работать: кроме поддержки SPF на отправителе и получателе, требуется обязательная модификация ПО на всех почтовых серверах, где может происходить пересылка почты от отправителя (опубликовавшего SPF-политику) к получателю (анализирующему SPF-политику).
2. Пересыльщик становится ответственным за пересланный спам. Другими словами, если на user@forwarder.com (см. пример) придет спам-сообщение, его отправитель будет подменен на что-то@mailbox.com. Во многих случаях такая подмена identity — неприемлема, ибо с точки зрения обычного пользователя mailbox.com становится «спамером».

Помимо общих недостатков, есть и специфические для каждого из вариантов решения проблемы пересылок почты:

А. Использование подмены отправителя приводит к таким дополнительным проблемам:

• Необходимо модифицировать ПО на серверах, пересылающих почту.
• Сообщения о недоставке (bounce messages) будут проходить по пути к исходному отправителю через всю цепочку пересылок, что увеличивает вероятность их утери и создает дополнительную нагрузку на сервер-пересыльщик.

Б. Передача дополнительных данных в SMTP-cессии приводит к тому, что необходимо модифицировать ПО почтовых серверов (причем, готовых решений на сегодня нет, есть только предварительные спецификации). Эта модификация должна быть произведена на всех пересылающих серверах и на всех принимающих серверах.

В. Извлечение данных о пересыльщике из заголовков писем приведет к таким усложнениям:

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

2.4.2. Механизм 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).

2.4.3. Проблемы SPF — резюме

На сегодняшний день SPF является несовместимой с пересылками почты, так как оба варианта решения «проблемы пересылок» неудовлетворительны:

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

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

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

Рассмотрим подробнее, так ли это.

2.5.1. Использование SPF как списка разрешенных

Как следует из схемы работы SPF, E-mail сообщение рекомендовано принимать, если в 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.

2.5.2. Использование SPF как списка запрещенных

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

В то же время, потери пересылаемой почты в данной схеме — возможны и обязательно будут (как показывают эксперименты, см. ниже). Другими словами, жесткие SPF-политики («-all») можно использовать, только если есть абсолютная уверенность в отсутствии пересылок почты или в том, что все транзитные системы поддерживают SPF в том или ином виде (подмена отправителя, расширения SMTP-протокола). Подробнее об этом сказано выше.

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

Каждая проверка 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-политике, что потребует дополнительного оборудования на крупных почтовых системах и в больших корпорациях.

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

2.6.1. Публикация SPF-записей

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

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

2.6.2. Использование SPF при приеме почты

Буквальное следование чужим SPF-политикам может привести как к потерям почты, так и к пропускам спама. Таким образом, может быть рекомендовано использование SPF-данных как дополнительной информации для антиспам-фильтров, но окончательное решение о пропуске или отвержении сообщения только на основании SPF принимать не следует.

3. Опыт практической эксплуатации SPF

3.1. Описание эксперимента

Прежде чем написать данную статью, автор провел практические исследования применимости SPF на практике в настоящее время. Для этого поддержка SPF была включена на личном почтовом сервере автора (домен lexa.ru) и на сервисе Спамтест. Условия проведенного эксперимента необходимо описать более подробно:

lexa.ru — личный домен автора, зарегистрированный в 1996&nbspгоду. С тех пор E-mail адрес автора не менялся и использовался практически повсеместно — в конференциях Usenet, при регистрациях на части сайтов, в форумах, публиковался на WWW-сайтах.

В результате автор сейчас получает 600-1000 спам-сообщений в сутки. В эксперименте использовалась подборка спама за неделю (~3800 сообщений). Спам-сообщения в режиме реального времени отбирались антиспам-фильтром и были впоследствии специально просмотрены на предмет ложных срабатываний (которых не оказалось).

Сервис Спамтест — это бесплатный сервис разметки спама, пересылающий почту пользователям. Из опыта известно, что пользователи тоже, как правило, ставят пересылку на Спамтест. Таким образом, проблемы с пересылкой должны были проявиться максимально широко. Анализировались приблизительно 165 тысяч писем, прошедших через Спамтест в реальном времени.

В обоих случаях поток почты анализировался в реальном времени, то есть состояние DNS было актуальным. Никаких решений на основе SPF-данных не принималось, SPF-статус сообщения просто записывался в лог-файл и заголовок сообщения.

3.2. SPF как фильтр спама

Результаты потенциального использования SPF как спам-фильтра (для домена lexa.ru) приведены в таблице:

	Доля писем	Расшифровка статуса
none	91.5%	Домен отправителя не имеет SPF-записей
softfail	7.02%	Домен указал «точно не знаю, но скорее нет» (префикс ~) — т.е. письмо должно быть принято обычным образом.
fail	1.69%	Была нарушена SPF-политика — т.е., письмо рекомендовано отвергнуть. Это и есть обнаруженный SPF спам.
unknown	1.30%	Ошибка при работе с DNS (таймаут и т.п.).
neutral	0.94%	Домен не может даже приблизительно указать свои исходящие адреса (?all).
pass	0.18%	Согласно SPF-политике, сообщение должно быть принято. Однако анализировался поток «чистого» спама, т.е. это — пропуск спама.
error	0.05%	Ошибка при работе с DNS (нет домена и т.п.).

Таким образом, на сегодняшний момент SPF способно обнаружить 1.7% спама при 0.18% явных пропусков и 7% сообщений, для которых указана нейтральная политика.

При этом не поддерживают SPF домены, трафик от которых составляет 91.5%. Если при увеличении популярности SPF эти соотношения сохранятся, то во всем спам-трафике будет ~80% «нейтральных» статусов, 18% обнаруженного спама и 2% явных пропусков.

Естественно, с ростом популярности SPF общая картина должна измениться, но маловероятно, что средняя SPF-политика будет ужесточаться — в настоящее время SPF внедряют технологические пионеры (‘early adopters’), которые, во-первых, все делают более аккуратно, а во-вторых, более озабочены проблемой детектирования спама, чем возможными потерями нормальной почты. При массовом внедрении приоритеты будут другие, и мы увидим гораздо меньшую долю ‘-all’, чем сейчас.

Отдельно хочется сказать о пропусках. Все зафиксированные нами пропуски использовали исходящий адрес в доменах с политикой ‘+all’.

3.3. SPF и проблема пересылок

Чтобы не загромождать текст техническими деталями, результаты тестирования SPF на сервисе Спамтест суммированы в 4 группы: pass (SPF рекомендует принять письмо), fail (рекомендация «отвергнуть письмо»), not supported (SPF-статуса нет или ошибка DNS) и neutral (суммированы neutral и softfail). Статусы Spamtest — SPAM, Probable Spam, Not Detected — отвечают результатам классификации сообщений по содержанию и заголовкам (RBL при классификации не использовались).

Результаты приведены в таблице:

	Статус по SPF
Статус Spamtest	pass	fail	not supported	neutral
SPAM	3.4%	1.5%	85%	10%
Probable SPAM	0.9%	1.0%	88.5%	9.6%
Not detected	1.5%	0.3%	95.2%	3%

Как видно из таблицы, при использовании пересылок (а на сервис Спамтест в основном пересылают почту) качество детектирования спама по SPF-данным не растет и составляет 1-1.5%. Если SPF поддержат все (а не 5-15% отправителей), то доля детектированных сообщений вырастет в 6-20 раз, т.е. до 6-30%.

При этом рекомендация «пропустить спам» встречается вдвое чаще, чем «отвергнуть спам» — что происходит из-за того, что часть крупных почтовых сервисов (gmx.de, mail.ru) при пересылке подменяют адрес отправителя на свой (таким образом, упомянутые почтовые сервисы являются SPF-совместимыми).

С точки зрения пропусков нормальной почты (статус Spamtest Not Detected), SPF ведет себя довольно плохо, отношение pass/fail 5:1 означает примерно 16% ложных срабатываний при гипотетическом условии, что SPF поддерживают все отправители

3.4. Выводы из экспериментов

По результатам экспериментального использования SPF можно сделать такие выводы:

1. Общее количество доменов с поддержкой SPF невелико: всего не более 10% (взвешенное на объем почтового трафика), это при том, что многие крупные игроки (AOL, Gmx.de, Yandex.ru, Mail.ru, Rambler.ru данное нововведение поддержали).
2. «Средняя» SPF-политика на сегодня является достаточно либеральной и включает или «?all», или «~all» — достаточно либеральные политики, что не позволяет на сегодня говорить об уверенной детекции спама. Доля обнаруженного спама не превышает 1-2%, что крайне мало.
3. SPF уже обходится спамерами. Пусть недобросовестное использование SPF сейчас обнаруживается в небольшом количестве, но и распространенность технологии на сегодня невелика.
4. Доля потенциальных ложных срабатываний на пересылках будет достаточно заметной. При повсеместном введении SPF — до единиц процентов.
   

   4. Заключение

   В начале данной статьи были сформулированы вопросы, возникающие при внедрении дополнительных технологий электронной почты. В конце статьи сформулируем ответы на них:

   1. Эффективность SPF как механизма фильтрации спама на сегодня крайне невелика. В настоящий момент доля распознаваемого спама составляет 1-2%; в случае повсеместного внедрения SPF качество распознавания может повыситься до 10-30%. При этом в механизме SPF имеются потенциальные проблемы, которые могут быть использованы спамерами для обхода SPF-фильтрации.
   2. Трудоемкость внедрения:
      1. Публикация SPF-политики домена (для исходящей почты) в простом случае не является трудоемкой, не требует дополнительного программного обеспечения, не требует большой последующей поддержки. В сложных случаях (крупные корпорации, провайдеры интернет-доступа, крупные почтовые сервисы с высокой нагрузкой) может потребоваться дополнительное программное обеспечение и работы по его внедрению.
      2. Внедрение поддержки SPF при приеме почты требует модификации программного обеспечения почтовых серверов. Для большинства распространенных серверов такая поддержка уже существует.
   3. Риски от внедрения SPF:
      1. Публикация SPF-политики для домена не несет дополнительных рисков, если эта политика только «разрешающая». SPF-политика, запрещающая прием почты с каких-либо адресов, может приводить к потерям исходящей почты при ее пересылке.
      2. Учет рекомендаций SPF-политики отправителя при приеме почты в настоящее время чреват потерями почты, либо пропусками спама.
   4. Прочие проблемы:
      1. Технология SPF несовместима c пересылкой (forward) почты в ее сегодняшнем виде. На всех серверах, пересылающих почту, необходима замена программного обеспечения, что представляется малореальным в ближайшей перспективе.
      2. Технология SPF содержит проблемный механизм exists, его использование может создать проблемы безопасности как для отправителей почты, публикующих политику с exists, так и для получателей, анализирующих ‘exists’ отправителя, а также рост нагрузки на почтовые системы.

   Кроме ответов на поставленные вопросы, можно сформулировать еще два дополнительных вывода:

   5. Доверять SPF-политике произвольного домена не следует. Она может быть слишком мягкой — и тогда появится много спама с отправителем из этого домена. Она может быть излишне жесткой — и тогда будет теряться много почты при пересылках. Ясно, что над SPF должна появиться дополнительная инфраструктура в виде списков «доменов с правильной политикой», или репутационных сервисов, или чего-то в этом духе.
   6. SPF не может использоваться изолированно. Использование SPF-данных как указание «принимать» или «не принимать» данное сообщение без дополнительного анализа приведет к пропускам спама или потере почты. Следовательно, данные SPF должны использоваться как дополнительная информация для спам-фильтров, дополняя другие технологии фильтрации спама.