RMON-зонд своими руками

В прошлом номере СР вы могли прочитать первую часть из цикла материалов про технологию SPF – «Антиспам-технология SPF — за и против». Продолжает публикации на эту тему материал того же автора. Поскольку изначально эти статьи были частью одной, многие вещи и термины не разьясняются достаточно подробно в сегодняшнем материале, так что – если что непонятно – обращайтесь к предыдущей статье.
Кстати в этом же номере СР (рубрика «Мнение») вы можете найти и статью, опровергающую некоторые выводы из этой. Плюрализм, панимаишь!..

описание эксперимента

Автор провел практические исследования применимости SPF на практике в настоящее время. Для этого поддержка SPF была включена на личном почтовом сервере автора (домен lexa.ru) и на сервисе "Спамтест". Условия проведенного эксперимента необходимо описать более подробно.
Lexa.Ru– личный домен автора, зарегистрированный в 1996 году. С тех пор e-mail адрес автора не менялся и использовался практически повсеместно – в конференциях Usenet, при регистрациях на части сайтов, в форумах, публиковался на веб-сайтах.
В результате автор сейчас получает 600-1000 спам-сообщений в сутки. В эксперименте использовалась подборка спама за неделю (~3800 сообщений). Спам-сообщения в режиме реального времени отбирались антиспам-фильтром и были впоследствии специально просмотрены на предмет ложных срабатываний (которых не оказалось).
Сервис Спамтест – это бесплатный сервис разметки спама, пересылающий почту пользователям. Из опыта известно, что пользователи тоже, как правило, ставят пересылку на "Спамтест". Таким образом, проблемы с пересылкой должны были проявиться максимально широко. Анализировались приблизительно 165 тысяч писем, прошедших через Спамтест в реальном времени.
В обоих случаях поток почты анализировался в реальном времени, то есть состояние DNS было актуальным. Никаких решений на основе SPF-данных не принималось, SPF-статус сообщения просто записывался в лог-файл и заголовок сообщения.

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

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

Таким образом, на сегодняшний момент SPF способно обнаружить 1.7% спама при 0.18% явных пропусков и 7% сообщений, для которых указана нейтральная политика.
При этом не поддерживают SPF домены, трафик от которых составляет 91.5%. Если при увеличении популярности SPF эти соотношения сохранятся, то во всем спам-трафике будет ~80% "нейтральных" статусов, 18% обнаруженного спама и 2% явных пропусков.
Естественно, с ростом популярности SPF общая картина должна измениться, но маловероятно, что средняя SPF-политика будет ужесточаться – в настоящее время SPF внедряют технологические пионеры ('early adopters'), которые, во-первых, все делают более аккуратно, а во-вторых, более озабочены проблемой детектирования спама, чем возможными потерями нормальной почты. При массовом внедрении приоритеты будут другие, и мы увидим гораздо меньшую долю '-all', чем сейчас.
Отдельно хочется сказать о пропусках. Все зафиксированные нами пропуски использовали исходящий адрес в доменах с политикой '+all'.

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 поддерживают все отправители.

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

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

выводы об SPF

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

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