|
||||||||||
|
||||||||||
|
||||||||||
|
| |||||||||
|
||||||||||
|
|
 |
| |
|
| |
| |
|
|
|
|
|
|
|
СТАТЬИ :: Антиспам-технологии |
Технология SPF - за и против© 2004 Алексей Тутубалин
Содержание
1. Верификация отправителя и проблема спамаГоворя о проблеме спама ("мусорной почты") необходимо прежде всего определить обсуждаемое явление. В данной статье под спамом понимаются "анонимные массовые рассылки электронной почты, как правило, имеющие рекламный характер". Данное определение удовлетворительно определяет спам как массовые рекламные рассылки, производимые профессионалами для зарабатывания денег. А ровно от этого бизнеса сейчас и страдают все пользователи Интернета. Прочая "нежелательная почта" (технические сообщения систем электронной почты, неанонимные рассылки с возможностью отписки, поздравительные открытки, посланные по ошибке письма) в данной статье как "спам" не рассматривается. Анализ технических данных приходящего спама показывает такие особенности:
Таким образом, складывается неутешительная картина - фильтрация по черным спискам (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. Описание технологии SPF2.1. Общие принципыТехнология верификации отправителя "Sender Permitted From" была предложена в 2003 году. Спецификации несколько раз изменялись, последний вариант опубликован 11 июля 2004 года. Вместе со спецификациями менялось и название, так что сейчас технология называется "Sender Policy Framework". В январе 2004 г. о тестировании SPF объявила компания AOL, эта инициатива была поддержана и другими крупными участниками рынка. Суть технологии заключается в следующем:
Публикуемые владельцем домена данные далее будут называться 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". Данный пример означает:
В терминах технологии SPF, 'ip4', 'a', 'all' - это "механизмы" (mechanism), а префиксы (+,-,?,~) перед названием механизма так и называются "префиксы" (prefix). Поддерживаются такие механизмы (подробнее см. описание формата записей SPF):
При анализе SPF-записи все механизмы перебираются слева направо, и если какой-то из них описывает IP-адрес посылающей сообщение стороны, то механизм "сработал". Тогда следует выполнить действие, рекомендуемое владельцем домена. Действия определяются префиксами перед механизмами:
Кроме механизмов, определены следующие модификаторы:
Таким образом, для поддержки 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) от отправителя к получателю. Однако это не так в следующих случаях:
Оба случая не являются редкими или экзотическими: резервные почтовые серверы предназначены для повышения надежности почтовых систем; пересылка почты с адреса на адрес является широко используемой, например, для сбора сообщений с нескольких адресов в один почтовый ящик. Резервные почтовые серверыРезервные почтовые серверы используются для приема почты в случаях, когда основной почтовый сервер организации по каким-либо причинам недоступен. После восстановления доступности резервный сервер доставляет почту на основной сервер. 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 получает рекомендацию отвергнуть письмо. Таким образом, для нормального приема почты с резервных серверов необходимо предпринять следующие действия:
В случае штатной пересылки почты внутри организации (скажем, с входного почтового сервера под 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). Эта проблема является ключевой при внедрении практически любой технологии верификации отправителя. Естественно, ее нужно каким-то образом решать, и на сегодня предлагаются такие решения:
Достоинства и недостатки схемы с exists описаны в отдельном разделе ниже, а все остальные решения обладают очевидными недостатками:
Помимо общих недостатков, есть и специфические для каждого из вариантов решения проблемы пересылок почты: А. Использование подмены отправителя приводит к таким дополнительным проблемам:
Б. Передача дополнительных данных в SMTP-cессии приводит к тому, что необходимо модифицировать ПО почтовых серверов (причем, готовых решений на сегодня нет, есть только предварительные спецификации). Эта модификация должна быть произведена на всех пересылающих серверах и на всех принимающих серверах. В. Извлечение данных о пересыльщике из заголовков писем приведет к таким усложнениям:
2.4.2. Механизм existsМеханизм exists предназначен для "тонкого" (fine-grained) управления SPF-политикой отправителя. Суть механизма заключается в следующем:
Например, если в 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) всех писем для существующих пользователей и запретить - для несуществующих. При реализации такого подхода придется смириться со следующими трудностями:
К сожалению, использование механизма exists создает и серьезные проблемы безопасности, как для отправителей, так и для получателей:
2.4.3. Проблемы SPF - резюмеНа сегодняшний день SPF является несовместимой с пересылками почты, так как оба варианта решения "проблемы пересылок" неудовлетворительны:
2.5. Использование SPF для фильтрации спамаМеханизм SPF разрабатывался, в первую очередь, как средство борьбы со спамом. Предполагается, что прямое следование объявленной SPF-политике домена поможет, по меньшей мере, не принимать письма с подделанным адресом доменов, поддержавших SPF, как почтовых служб, так и других организаций. Рассмотрим подробнее, так ли это. 2.5.1. Использование SPF как "белого списка"Как следует из схемы работы SPF, E-mail сообщение рекомендовано принимать, если в SPF-политике указано, что с данного IP возможна посылка сообщения с данным адресом отправителя. По всей видимости, для таких сообщений должны быть ослаблены или выключены антиспам-фильтры (а в чем иначе может заключаться использование разрешительных SPF-политик?). Если же такая схема будет кем-либо реализована, то возможны следующие приемы ее недобросовестного использования:
Таким образом, принимать на веру чужую разрешительную 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-политики с учетом следующих соображений:
2.6.2. Использование SPF при приеме почтыБуквальное следование чужим SPF-политикам может привести как к потерям почты, так и к пропускам спама. Таким образом, может быть рекомендовано использование SPF-данных как дополнительной информации для антиспам-фильтров, но окончательное решение о пропуске или отвержении сообщения только на основании SPF принимать не следует. 3. Опыт практической эксплуатации SPF3.1. Описание экспериментаПрежде чем написать данную статью, автор провел практические исследования применимости SPF на практике в настоящее время. Для этого поддержка SPF была включена на личном почтовом сервере автора (домен lexa.ru) и на сервисе Спамтест. Условия проведенного эксперимента необходимо описать более подробно: lexa.ru - личный домен автора, зарегистрированный в 1996 году. С тех пор E-mail адрес автора не менялся и использовался практически повсеместно - в конференциях Usenet, при регистрациях на части сайтов, в форумах, публиковался на WWW-сайтах. В результате автор сейчас получает 600-1000 спам-сообщений в сутки. В эксперименте использовалась подборка спама за неделю (~3800 сообщений). Спам-сообщения в режиме реального времени отбирались антиспам-фильтром и были впоследствии специально просмотрены на предмет ложных срабатываний (которых не оказалось). Сервис Спамтест - это бесплатный сервис разметки спама, пересылающий почту пользователям. Из опыта известно, что пользователи тоже, как правило, ставят пересылку на Спамтест. Таким образом, проблемы с пересылкой должны были проявиться максимально широко. Анализировались приблизительно 165 тысяч писем, прошедших через Спамтест в реальном времени. В обоих случаях поток почты анализировался в реальном времени, то есть состояние DNS было актуальным. Никаких решений на основе SPF-данных не принималось, SPF-статус сообщения просто записывался в лог-файл и заголовок сообщения. 3.2. SPF как фильтр спамаРезультаты потенциального использования SPF как спам-фильтра (для домена lexa.ru) приведены в таблице: Таким образом, на сегодняшний момент 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-данным не растет и составляет 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 можно сделать такие выводы:
| |||||||||||||||||||||||||