Проблемы и ошибки        27.05.2019   

Спам-фильтр: как не оказаться в чёрном списке белому отправителю. Откуда MRAS узнает о спам-рассылках? Емейлы должны быть краткими

Принципы и технические методы работы с незапрашиваемой корреспонденцией

Илья Сегалович ([email protected]), Дмитрий Тейблюм ([email protected]), Александр Дилевский ([email protected])

Введение

Опуская этическую и социальную проблематику, связанную со спамом, мы в данной статье сосредоточимся на способах его доставки, методах обнаружения и подавления. Затем мы обсудим ошибки, часто возникающие при описании этих методов и их возможностей. В заключительной части статьи будет рассказано о «супершингле Яндекса» – несложном техническом методе детектирования массовых рассылок, используемом в Яндекс.Почте.

Часть 1. Доставка спама. Эволюция

Чтобы спам попал в ваш ящик, его необходимо вам доставить. Поскольку мы не встречали внятной классификации спама по способу доставки (а остальные классификации сводятся к простой дихотомии: спам, модифицирующий, и спам, не модифицирующий текст заказчика) постараемся вкратце описать их здесь. Возможно этот текст покажется излишне подробным, однако, нам кажется интересным проследить, как разработчики спамерского ПО откликались на вызов, брошенный им антиспамом, и vice versa.

Спам молод. Как средство активного маркетинга он возник примерно в 1997 году. О дате его возникновения можно судить по моменту, когда Paul Vixie создал RBL. RBL – исторически первая серьезная попытка борьбы со спамом. См. http://www.wikipedia.org/wiki/DNSBL.

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

Первые виды спама были просто прямыми рассылками. Такой спам блокируется достаточно просто, и спамеры начали использовать открытые почтовые релеи, то есть обычные почтовые сервера, позволяющие произвольному пользователю воспользоваться сервисом отправки письма на другой сервер. Заметим, что иных релеев в ту пору просто не было, а само понятие «открытые релеи» возникло лишь после того, как появился спам и их вообще начали закрывать.

Такие открытые релеи достаточно легко детектировать, их стали активно искать и блокировать. После этого у прямых рассылок наступил ренессанс – спам стал рассылаться с «диалапов» и для его блокирования системным администраторам пришлось разузнавать и блокировать IP модемных пулов основных провайдеров.

Прокси-сервера. Socks и HTTP

Чуть более 2 лет назад появились как заметное явление более изощренные способы использования чужих, неаккуратно сконфигурированных серверов.

Socks-прокси серверы предназначены для сведения всего интернет-трафика небольших компаний к одной единственной машине, имеющей доступ в Интернет. Для работы они обычно используют порт 1080. Если машина допускает неавторизованное соединение с произвольного IP-адреса (типичная ситуация в эру до спама), ее могут использовать спамеры и для направления своего SMTP-трафика. Интересно отметить, что логи использования socks-серверов обычно не ведутся, поэтому отслеживание истинных источников рассылки даже самими администраторами socks-серверов чаще всего невозможно.

Почти сразу же обнаружилось, что и стандартные открытые HTTP-прокси (типичные порты 3128, 8080 и т.д.), поддерживающие метод CONNECT, легко использовать для того же самого, достаточно в команде CONNECT указать не только имя сервера, но и задать 25-й почтовый порт. Даже любимый всеми «народный» вебсервер Apache, собранный с модулем mod_proxy и неправильно настроенный, нередко используют как средство рассылки почтового спама.

Взломанные машины. Стандартное ПО. Модифицированое ПО. Смена портов и времени прослушивания. Троянские кони.

Исчерпав возможности по поиску нерадивых администраторов, спамеры примерно год назад или чуть больше начали взламывать любые доступные компьютеры и устанавливать на них одну из вышеперечисленных сервисных служб: SMTP-релей или прокси. Добавьте к этому взрывной рост кабельных подключений в США и какой-нибудь Бразилии, (Россия по сравнению с США и той же Бразилией – мелочь), при том что Windows не имеет включенного по умолчанию брандмауэра, администраторы местных кабельных и DSL-сетей никак не защищают своих пользователей в силу низкой квалификации, а сто «сравнительно честных» и хорошо документированных способов взлома незащищенных Windows-машин печатает журнал Хакер в каждом втором номере, и вы получите практически безграничное поле деятельности для взломщика. Последняя и самая мощная волна взломов исходит от P2P сетей типа Kazaa и e-mail-вирусов, таких как Sobig, несущих в своем коде «рабочий набор спамера».

Надо сказать, что плохая защищенность таких сетей далеко не всегда происходит от низкой квалификации администраторов. Иногда это происходит в силу «политических» причин: вполне квалифицированные администраторы провайдера считают, что они отвечают только за подключение, а все остальное – проблема клиента. Даже в России редко встретишь домашнюю сеть, защищенную брандмауэром и тем более практически невозможно увидеть в памятке клиенту такой сети напоминание о том, что в Windows надо установить брандмауэр.

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

Если рассылочный демон принимает обращения только от IP своего хозяина и/или засыпает и просыпается по хитрому алгоритму, и/или постоянно меняет порт, по которому принимаются команды и письма, то прямое обнаружение таких машин методом прозвона обычному администратору сильно затрудняется. Ведь чтобы прозвонить все 65536 TCP-портов потенциально взломанной машины, требуется время – примерно около получаса, за это время она может сменить порт, заснуть и т.д. и т.п.

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

Спамерский софт развивается. Относительно невинный софт для прямых рассылок (например Advanced Mail Sender), в котором спамер в обход сервера провайдера обращается к целевому MTA прямиком с домашнего модема, сменился продвинутыми сложными системами, вершиной которых являются троянские кони широкого спектра действия. Среди их возможностей есть даже апгрейд самих себя, автоматическое распространение, переезд на другие взломанные машины и т.д.

Например, функция такого троянского коня: сходить по HTTP на записанный в нем адрес в заданное время, взять оттуда списки адресов и писем, разослать почту, узнать время и место следующего захода. Иногда троянские программы прослушивают каналы IRC и получают команды оттуда. Это позволяет скрыть источник команд. В отличие от HTTP, где создание сайта или закачка новых файлов отслеживается довольно легко, сообщения на канал IRC могут передаваться через любой из серверов IRC-сети, и для отслеживания источника необходим оперативный доступ к логам всех серверов сразу. В общем, есть много способов скрыть троянскую программу: использовать нестандартные порты, управление, протоколы и т.д. и т.п.

Возможности по активному обнаружению взломанных машин

Теоретически (и практически) способ рассылки, при котором сама взломанная машина обращается по HTTP или IRC за письмами и никогда не находится в режиме прослушивания, труднее всего обнаружить. Практически нельзя понять, что они делают, каков их интерфейс со спамерами, так сказать. Например известно, что некий троян ставит стандартные прокси и SMTP на нестандартных портах. Обычно информация об этом трояне этим и исчерпывается. Зараженных пользователей и их провайдеров интересует только как убрать троян – а антивирусные программы делать это научаются быстро. Для более или менее серьезной борьбы со спамом интереснее знать, кто этот троян распространяет и как он это делает. Для подобных выяснений и полезны администраторы сетей, в которых есть зараженные машины. Например если троян ходит куда-то зачем-то по HTTP, то во-первых, надо засечь это обращение и его содержание, а также ответ той стороны, а во-вторых, отследить входящие соединения с ним, их источники и суть.

К счастью, у спамеров тоже существует разделение труда – категория «взломщиков» выделилась в отдельную профессию, а товаром и предметом купли-продажи служат списки IP-адресов. Покупателями являются «рассылочники». При этом стандартность установленного ПО играет большую роль. «Рассылочникам» намного удобней работать с использованием обычного списка, не заботясь об особенностях поведения того или иного хитрого трояна. Поэтому сложные и продвинутые троянские кони пока не получили слишком широкого распространения. Впрочем количество спама пока растет по экспоненте – так что может статься, что уже и получили, только мы этого еще не осознали.

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

Организационные усилия по борьбе со спамом

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

Сетевое сообщество не смогло до сих пор внедрить простейшие антиспамерские приемы, которые само же установило в качестве стандарта. Например, разделение портов SMTP-сервера на порт для MTA (25: прием почты от чужого сервера для сохранения своему пользователю; «общение между серверами») и MSA (587: прием письма от своего пользователя для отправки на чужой сервер; «общение между пользователем и сервером»). Эта идея, также как и SMTP-авторизация, появилась именно как реакция на появление спама.

Прошло уже немало времени, однако 587 порт так и не появился в популярных почтовых программах типа Outlook Express или The Bat! А ведь эта простейшая мера позволила бы провайдерам просто закрыть все исходящие соединения по 25 порту и полностью ликвидировала бы прямой спам «по карточкам» – спам с dialup-соединения. Как известно, Интернет-Карточка стоит 5 долларов, ее хватает на 10 ночных часов, за это время можно разослать десять тысяч писем и спокойно пойти покупать новую карточку, а старую (уже ненужную) заблокирует выведенный из себя провайдер.

Нет никаких технических препятствий так настроить почтовый сервер, чтобы он не принимал почту от «опасных незнакомцев» и блокировал как «спам по карточке», так и черные дыры. Достаточно, например, включить и настроить встроенный в любой SMTP-сервер протокол SSL, так чтобы он отклонял несертифицированные соединения. Сертификаты, идентифицирующие сервер, тоже давно существуют. За 50-100 долларов в год на почтовый сервер можно приобрести их в Thawte или Verisign. К сожалению, при такой настройке вы вообще перестанете получать почту, так как ни у кого, конечно, сертификатов нет.

Новый протокол придумать наверное можно. Но работать он будет только в том случае, если на него одновременно перейдут все почтовые системы. Иначе те, кто на него перейдет, окажутся изолированными от тех, кто не перешел. Иными словами, чтобы вы научились плавать в бассейне, кто-то должен сначала налить туда воду. Однако современный Интернет напоминает тот самый сумасшедший дом, в котором воду наливают, только после того как вы научитесь плавать.

Вывод : очевидно спам нельзя победить «хорошим» протоколом. Но спам можно побеждать совместными усилиями антиспамерского ПО, систем обратной связи, согласованных действий провайдеров и т.д. И об этом пойдет речь ниже.

Часть 2. Методы борьбы со спамом

Можно встретить разные описания (по сути классификации) средств борьбы со спамом. Поскольку программа это всегда «Алгоритм + Структура Данных», то и классификацию программ правильно основывать на видах используемых данных и используемых алгоритмах. Что мы и попытаемся проделать ниже.

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

Задача спам-фильтрации

Задача, которую решает детектор спама по содержанию: разделить входящий поток сообщений на спам и нормальную почту, Spam и Ham в английском жаргоне.

Исходные данные

Данные, которые используются для анализа – это все признаки пришедшего письма. Их можно разделить на четыре пространства, вычисление решений в которых можно производить независимо:

  • IP-адрес сервера отправителя
  • оформление и стиль писем, заголовки, форматирование, характерные обороты
  • статистика слов в письмах
  • контрольные суммы («сигнатуры») текстов писем

Естественно, что пространство признаков по каждому набору данных ограничивают только «интересными» признаками.

Конкретный антиспамовый модуль может использовать все эти пространства признаков или только 1-2 из них. Недостатки и преимущества каждого из пространств признаков мы обсудим ниже. Пока же обратим внимание на необходимое присутствие еще двух составляющих «задачи машинного обучения», классическим примером каковой является детектор спама, а именно: обучающей выборки и обратной связи.

Заметим, что в отличие от пространств слов или элементов оформления, при опознании спама по IP-адресу решение принимается по одному-единственному « признаку. Взвешивания по адресу обычно не производится, следовательно, настройка взвешивающего механизма на обучающей выборке не нужна. Однако без обратной связи (в случае с IP – без постоянно пополняемого списка черных дыр) удовлетворительно работающий механизм нельзя построить ни по одному из вышеперечисленных пространств.

Ошибки первого и второго рода

Чтобы любое машинное обучение работало, ему необходимо сообщать об ошибках. Ошибки бывают двух видов. Ошибка первого рода: пропуск спама, то есть пропуск спамового письма. Иными словами – недостаточная полнота метода. Ошибка второго рода – ложные срабатывания, когда не-спам ошибочно относят к спаму. Иными словами – точность метода.

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

Интегральный показатель качества

Процент детектированного спама есть мера полноты, процент ложных срабатываний – мера неточности. Несложно предложить интегральную оценку качества, назовем ее качеством фильтрации. Очевидно, что при точности, близкой к 100%, качество будет примерно равно полноте. Именно полноту фильтрации часто и называют, когда озвучивают те или иные цифры, подразумевая, что точность практически абсолютна.

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

Ложные срабатывания. Разные подходы

Довольно большое значение имеет то, что происходит при ошибках второго рода – от этого зависит величина ущерба, наносимого этими ошибками, и, следовательно, требования к их количеству.

Возможны следующие реакции фильтра на обнаруженный спам:

  • письмо отвергается почтовым сервером; при этом, если оно на самом деле было «законным» письмом, отправитель получит сообщение об этом;
  • письмо помещается в специальную папку; пользователь имеет шанс заглянуть в эту папку и увидеть там ошибочно отфильтрованное письмо;
  • письмо «удаляется», как будто его и не было; никто ни о чем не знает.
  • Сценарий (3) – самый опасный; к счастью, администраторы почтовых серверов его почти никогда не используют. Однако из популярных текстов, о которых мы будем говорить ниже, зачастую создается впечатление, что используется именно он.

    Сценарий (2) с одной стороны имеет тенденцию вырождаться в (3), если качество фильтра хорошее. С другой стороны, регулярный просмотр пользователем папки со спамом снижает пользу фильтрации, хотя это и делается существенно реже, поверхностным просмотром и т.д. В таком сценарии, однако, ущерб от ошибок второго рода минимален, а обратная связь максимальна.

    Сценарий (1) – традиционный вариант для «классической» фильтрации по IP адресам. В отличие от (2), он не вырождается в (3), однако при этом нагрузка на сервер существенно возрастает, если в фильтре используется содержимое письма.

    Промежуточная зона – «полуспам»

    Очень важная, часто недопонимаемая проблема состоит в том, что спам и не-спам пересекаются в очень большой степени.

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

    Объем этой зоны очень и очень значительный.

    Перед началом очередного этапа работ по антиспамовой фильтрации Яндекс провел исследование. Был проведен ручной анализ достаточно репрезентативной выборки из 5151 писем, пришедших на 300 адресов. Так вот, ситуации, когда проверяющий посторонний человек, используя для принятия решения всю мощь своего естественного интеллекта, отнес письмо к такой «промежуточной зоне» составляли до 40 процентов! При этом правило для такого отнесения было достаточно осторожным:

    … «Полуспамовое» письмо – это письмо от известного проверяющему реально работающего магазина или онлайн-сервиса, в котором пользователь скорее всего регистрировался. …

    Какой из этого можно сделать вывод? Даже с учетом статистических смещений, характерных для публичной веб-почты, можно попытаться предсказать максимальный теоретический предел качества неперсонализированной спамовой фильтрации. Ведь задача неперсонализированной программы – моделировать поведение максимально объективного незнакомого наблюдателя, не знающего ни про ваши пристрастия, ни про ваши подписки!

    Второй вывод таков. Старайтесь не верить заявлениям создателей неперсонализированных антиспамовых продуктов, уверяющих что качество их фильтрации 95 или 98 процентов. В неперсонализированной антиспам-системе, которой известны предпочтения только усредненного пользователя, этот показатель по-видимому теоретически недостижим.

    Обратная связь

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

    Реализация обратной связи

    В интерфейсе большинства современных публичных веб-почт (Hotmail, Yandex, Yahoo, Oddpost) есть специальная папка, служащая для накопления «полуспама» и не очень достоверно определяемого спама, а также кнопка для «реабилитации», сообщающая системе о ложном срабатывании.

    В настольных почтовых клиентах, созданных в последнее время, тоже обязательно присутствует обратная связь как первого, так и второго рода. Обычно в виде кнопки «это спам» / «это не спам».

    К сожалению, несколько популярных клиентских почтовых программ все еще не поддерживают полноценную обратную связь. Например, все почтовые программы Микрософт, чей интерфейс и набор возможностей не менялся последние 5 лет, (впрочем для них написаны многочисленные плагины, способные, пусть и неудобным способом, но восполнить этот недостаток), или некоторые публичные почтовые службы, в которых не реализована обратная связь с пользователем.

    Технические приемы на уровне протокола

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

  • Незнакомым отправителям посылается письмо типа «Извините, мы с Вами не переписывались, подтвердите пожалуйста что Вы не спамер». По приходу подтверждения программа добавляет адрес отправителя в белый список. Есть и известные реализации этой довольно старой идеи: TMDA и WinAntiSPAM.
  • Довольно свежая идея – graylisting («серые» списки). Суть ее состоит в том, что на некоторые письма сервер отвечает не «OK» или «rejected», как обычно, а «временная ошибка». Это само по себе работает (пока) очень хорошо, потому что «хорошие» почтовые сервера через некоторое время повторяют попытку доставить письмо (они обязаны это делать), а рассыльщики спама (пока) этого не делают. Причем можно надеяться, что если спамеры будут пытаться повторять попытки доставки, как нормальные сервера, то за это время они успеют попасть в черные списки. Время повторного соединения обычно полчаса, и это, в общем, некритично, тем более что оно относится только к первой корреспонденции между двумя незнакомыми сторонами, так как ранее проверенные адреса не проверяются, а запросы на проверку кэшируются и вновь не посылаются.
  • Проверка корректности адреса отправителя (envelope-from). Проверку существования домена в большинство серверов вставили очень давно, и до сих пор она изредка срабатывает, хотя эффективность ее ныне невелика. Сейчас многие стали вставлять проверку адреса целиком. Хотя это довольно накладно по ресурсам – для этого надо связываться с сервером, на котором расположен адрес, и осмысленный ответ при этом не гарантирован, однако, по крайней мере пока, это неплохо работает.
  • Алгоритмы

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

    Проверка IP. DNS-зона. Имя черного списка как интегральный признак

    Простейшая в реализации, и безусловно именно поэтому самая популярная – фильтрация по пространству IP адресов. Для каждого письма проверить надо 1 (редко больше) IP адрес, делается это сейчас при помощи специальной DNS-зоны для каждого из черных списков. Поиск в DNS, в сущности – простая хеш-функция. Часть из списков разрешено скачивать, и для эффективности такие зоны разумно создать на локальном DNS-сервере.

    Что еще характерно для данного пространства признаков? Во-первых, отлично отработанная обратная связь.

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

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

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

    Байесовская фильтрация по словам

    Очень простым, интуитивно понятным методом «машинного обучения с учителем» (то есть при наличии Spam&Ham выборки) является наивная байесовская классификация. «Наивной» она называется, потому что исходит из предположения о взаимной независимости признаков, и как ни странно, этого часто оказывается вполне достаточно. Использование формулы Байеса для фильтрации спама предложено совсем недавно, примерно год назад.

    Автор, Paul Graham, предназначал его для персональной фильтрации. Для работы требуется, чтобы у классифицируемого объекта было достаточно признаков. Этому требованию идеально удовлетворяют все слова (или токены) писем данного пользователя, исключая разве что очень редко встречающихся и совсем короткие. Вторым требованием является постоянное переобучение и пополнение коллекции Spam+Ham. Все такие условия идеально работают в локальных почтовых клиентах, поддерживающих этот алгоритм.

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

    Генетические алгоритмы и ручное выставление весов

    В результате больших усилий многих людей было выявлено огромное количество различных эвристик, связанных с особенностями заголовков спамерских писем, их оформления, характерных стилистических оборотов, типичных фраз. Суммарное количество подобных признаков у известного фильтра SpamAssassin, например, приближается к тысяче. К сожалению, несмотря на то, что практически каждое спамовое письмо содержит хотя бы несколько таких признаков, над пространством таких признаков невозможно построить устойчивый Байесовский автомат. Причин здесь две:

  • слишком мало число признаков, типично встречающихся в одном письме
  • отсутствует балансировка, то есть нет достаточного количества признаков не-спама.
  • В этих условиях применяют другие алгоритмы. Например, SpamAssassin применяет генетический алгоритм. В нем подбор начинают со случайной простановки весов для каждого признака (создание «хромосом»), а затем «скрещивают» и «мутируют» хромосомы в поисках оптимальных значений весов для данной тестовой выборки. Оптимум (в теории) может оказаться не глобальным, а локальным, но этого обычно более чем достаточно.

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

    Обнаружение повторов и признак массовости

    Если антиспамовая система имеет дело с большим потоком писем, она может и должна пытаться находить повторы писем. Во-первых, так можно вылавливать письма, уже известные (помеченные ранее) как спам. Во-вторых, массовость письма сама по себе является неотъемлемым признаком спама. Из утверждения, что письмо есть спам, неизбежно следует, что оно массовое. Таким образом, признак массовости есть необходимое, хотя и не достаточное условие спама.

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

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

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

    Интегрирующие системы

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

    Пионером здесь является SpamAssassin, который позволяет применить как генетический алгоритм, так и ручное взвешивание поверх не только собственного или «настроенного» набора флагов, но и с учетом байесовского текстового подобия, и с учетом взаимодействия с DCC-модулем детектирования рассылок.

    Отдельным вопросом является то, какой алгоритм должен работать в точке окончательного принятия решения.

    Точки применения фильтра

    Кроме различия в исходных данных, алгоритмах и видах обратной связи, антиспамовые средства надо различать по месту их применения. Таких мест можно выделить два: почтовый сервер и клиентский компьютер.

    Фильтрация на сервере: царство IP-метода

    Сервер характеризует большим поток писем, на нем можно обеспечить гарантированную производительность, на нем есть постоянная связь с другими серверами. При превышении потоком писем некоторого уровня можно начать детектировать рассылки. На серверах, по-видимому, неприменим в чистом виде байесовский алгоритм по тексту письма (см выше).

    Однако наиболее стандартным, легко реализуемым и относительно эффективным методом является фильтрация по IP, и с учетом этих обстоятельств этот метод в настоящий момент доминирует. Можно ожидать появление средств фильтрации и по другим признакам.

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

    Фильтрация на клиенте: царство Байеса

    У клиента совершенно другая картина. Здесь малый поток данных, неизвестная производительность компьютера, отсутствие постоянной связи с Интернетом – то есть невозможно или слишком дорого постоянно «закачивать» массивы контрольных суммы писем или IP черных дыр. Зато очень точно можно отличить чужие письма, они всегда не похожи на ваши просто по тексту; «вкусы» одного пользователя выяснить легко. По всем этим причинам клиентские антиспамовые программы представляют из себя царство Байеса.

    Часть 3. Осторожно, маркетинг

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

    Антиспамовые методы на стороне провайдеров

    Из рекламных статей прежде всего нельзя понять, что происходит при отфильтровывании письма по IP-адресу. Читателям по сути внушается апокалиптическая картина, что письма проваливаются в никуда; многомиллионные контракты срываются и т.д. и т.п.

    Однако провайдеров, которые ведут себя по таком сценарию (сценарий (3) – см. выше), на практике не существует (мы не знаем НИ ОДНОГО такого провайдера). Все известные нам почтовые сервера отвечают внятной диагностикой (возвращаемой отсылающим сервером автору письма) на попытку соединиться с IP-адреса из черного списка. Например (в худшем случае):

    Your message to cmail.yandex.ru was rejected.
    I said:
    RCPT To: [email protected]
    And cmail.yandex.ru responded with
    550 5.7.1 [email protected] Spam source.

    Если же список черных дыр официально публикуется и поддерживается, то в диагностическом сообщении SMTP-сервера принято указывать еще и URL страницы, на которой можно получить подробное объяснение, почему данный IP-адрес попал в черный список. Более того, все известные нам скандалы в Рунете, связанные с блокированием, возникали именно тогда, когда «официальные спамеры» получали такую квитанцию и начинали чувствовать себя ущемленными.

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

    На самом деле никаких «тайных» списков конечно же нет.

    У провайдеров действительно есть свои собственные списки, которые они не публикуют, главным образом потому что публикация – это дорогостоящий шаг, требующий регулярного обновления, поддержки, в общем некоторого ресурса. Кроме того, в нашей стране не очень принято публиковать нелицеприятные заявления о каких-то компаниях (чем по сути является публичный «черный список»). На это надо отдельно решиться.

    Кое-что делалось в этом направлении – была такая инициатива DRBL. Однако то, что получалось, видимо, было слишком сырым, чтобы это использовать массово. Тем не менее, любому пользователю, отправившему письмо с заблокированного адреса, придет серверная квитанция в случае недоставки, с четким указанием причины отказа в сервисе – «ошибка 550, отказ в соединении, источник спама» – см. выше. Правда, это сообщение обязано быть на английском языке.

    Таким образом, эти данные никоим образом не скрываются. Такое поведение требуется по стандарту протокола SMTP.

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

    Это не совсем так или даже далеко не так.

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

    Сегодня спамом уже никого не удивишь. Каждый хоть раз в жизни получал нежелательные электронные сообщения, SMS и звонки.

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

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

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

    Ниже рассмотрим процедуру настройки спам-обороны на смартфонах под управлением Windows и Android.

    Как использовать спам-фильтр на смартфонах Windows phone 10 и Nokia

    В настоящий момент под управлением операционной системы Windows phone смартфоны уже не выпускаются. С приходом универсальной платформы Windows 10, мобильная операционная система получила название Windows 10 Mobile.

    Поэтому описанные ниже процедуры по настройке фильтрации спама могут отличаться от действующих на текущий момент (не стоит исключать фактор развития универсальной платформы, в которую с каждым новым релизом вносятся изменения, а также дополнительные надстройки интерфейса, интегрируемые различными производителями смартфонов).

    Фильтр спама в телефоне на Windows phone

    Для того, чтобы активировать доступ к возможности блокировки выделенных номеров в телефонной книге, в первую очередь необходимо пройти в меню настроек телефона и найти пункт «Спам-фильтр», активировать блокировку нежелательных номеров – флажок «Блокировать вызовы+SMS» (в смартфонах других производителей пункт настроек «Спам-фильтр» может иметь другое название, например, «Блокировка вызовов»).

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

    Заблокировать можно только те номера телефонов, которые имеются в телефонной книге или в журнале вызовов.

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

    При попадании номера в такой «черный список» будут блокироваться и звонки и SMS-сообщения.

    Просмотреть и отредактировать список уже заблокированных номеров можно через меню настроек «Спам-фильтр» — кнопка «заблокированные номера».

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

    Если пункт «Спам-фильтр» исчез из настроек или его там не было (функционал не предусмотрен производителем), можно воспользоваться оригинальным приложением «callSMSfilter», которое можно найти и установить из официального магазина приложений Microsoft (доступно в том числе и для скачивания с платформы Windows 10 Mobile).

    Фильтр спама на Windows 10 Mobile

    На современной операционной системе Windows Mobile от стороннего функционала разработчики отказались, и потому оригинальная спам-защита от Nokia была заменена на встроенное системное приложение — «Блокировка и фильтрация». Добавить в черный список абонента можно, как и раньше (в системе Windows phone), через контекстное меню при долгом тапе.

    Спам фильтр на Андроид – обзор

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

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

    Расширенные настройки блокировки можно найти в настройках приложения (пункт «Фильтр спама»):

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

    Стоит сразу отметить, что пометить сообщения, отправленные с буквенных имен, как спам не получится.

    Для блокировки нежелательных звонков придется установить стороннее приложение из магазина «Play Маркет».

    Владельцам альтернативной прошивки CM (CyanogenMod) ничего устанавливать не нужно. В настройках смартфона имеется все необходимое. В меню «Конфиденциальность» можно наполнить свой «черный список». Будут фильтроваться и сообщения, и звонки. Есть возможность задать регулярные выражения, отфильтровать в спам скрытые, а также неизвестные номера.

    Сторонних приложений, обеспечивающих требуемую защиту от спама в официальном магазине приложений от Google, очень много. Остановимся на нескольких самых ярких представителях.

    2GIS Dialer Звонки и контакты

    Заменяет стандартное приложение для совершения звонков. Умеет не только определять номера входящих на основе собственных данных, хранящихся на серверах компании 2ГИС (огромная база компаний с адресами и телефонами), но и блокировать звонки на основе «черного списка». Есть возможность обмениваться новыми спам-номерами среди пользователей программы (последние проставляют специальные пометки). Приложение не работает с SMS-сообщениями.

    Тихий СМС СПАМ

    Интересное приложение от российского разработчика, которое умеет работать с короткими и текстовыми номерами отправителей. Не выводит никаких уведомлений и не издает никаких звуков при получении спама. Можно строить условия помещения в спам не только на основе черных (запрещенных), но и на основе белых списков (разрешенных контактов). Очень тонко настраивается, но давно не обновлялась (с 2014 года), хотя работает и на современных смартфонах.

    SMSCop

    Можно скачать спам фильтр на основе собственной базы программы, тонко настроить фильтры и составить свой список блокировок. Прямо из приложения можно пожаловаться на отправителя в ФАС (необходим ввод паспортных данных).

    Собственный антиспам в Mail.Ru существует уже много лет. Желание разработать собственный продукт вполне объяснимо, т.к. на определенном этапе развития проекта требования к качеству и масштабируемости механизма борьбы со спамом стали слишком велики, чтобы их могли удовлетворить даже очень сильно кастомизированные «чужие» продукты. Конечно, какие-то сервисы и компоненты независимых поставщиков мы используем по-прежнему (например, для проверки писем на вирусную составляющую), но их роль сейчас уже не является определяющей.

    Требования к нашему собственному антиспаму были очень понятными и логичными - максимальная скорость и точность срабатывания. Конечно, предела совершенству нет, отношения спамеров с их противниками представляют собой вечную борьбу щита и меча. Но сейчас мы уже с уверенностью можем говорить, что серьезно продвинулись к заветной цели и продолжаем наращивать «обороты».

    Итак, как он выглядит и работает - современный(2011) антиспам Почты@Mail.Ru?

    Прежде всего, еще на «подходе» к почтовым серверам все отправители проверяются по базе IP-адресов, замеченных в спам-рассылках. База динамически обновляется в режиме реального времени: одни IP «обеляются», другие попадают в «черный список». Соответственно, письма с IP-адресов с «подмоченной» репутацией не принимаются - таким образом нам удается отсечь большинство ботнетов.

    Если IP отправителя нет в черном списке, то письмо принимается сервером и проходит проверку двумя системами антиспама: Kaspersky Anti-Spam (или коротко KAS) и разработанной в Mail.Ru системой фильтрации спама - MRAS (Mail.Ru Anti-Spam). Эти две системы всегда работают параллельно.

    Название MRAS фигурирует, в частности, в служебных заголовках практически каждого письма, проходящего через почту Mail.Ru. Например, заголовок «X-Mras: Ok» говорит о том, что в данном письме не обнаружены спам-сигнатуры.

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

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

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

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

    Откуда MRAS узнает о спам-рассылках?

    Существует несколько источников образцов спама для MRAS. Основным источником являются жалобы пользователей, нажимающих в веб-интерфейсе почты кнопку «Это спам». Они группируются, проходят автоматическую фильтрацию и затем поступают в систему принятия решений.

    Еще одним из важнейших источников являются ящики-ловушки - специально зарегистрированные и «засвеченные» в Интернете ящики, куда попадает только спам. Внешне они выглядят как ящики обычных пользователей - это могут быть аккаунты в Моем Мире и других социальных сетях, сообщения на форумах и в гостевых книгах и т.п. Недобросовестные рассыльщики, собирающие базу адресов по Интернету, с высокой долей вероятности зацепят несколько «ловушек» - и когда на них придет письмо, оно наверняка послужит основной для спам-сигнатуры.

    Наконец, на третьем этапе находится группа аналитиков Почты@Mail.Ru, которые в режиме 24×7 в реальном времени анализируют полученные от пользователей жалобы на письма, возможно являющиеся спамом, контент ящиков-«ловушек» и т.д.

    1. письмо не спам
    2. письмо, возможно, является спамом
    3. письмо точно спам.

    Такие же оценки выдает KAS. Если обе антиспам-системы считают письмо хорошим - письмо отправляется в папку «Входящие», если одна или обе системы пометили письмо как возможный спам - то в папку «Спам». Если хотя бы одна из систем уверена, что письмо - спам, то такое письмо не попадает к пользователю, а отправителю уходит сообщение о недоставке (bounce message).

    Важно отметить, что эта же система обрабатывает и исходящие письма с серверов Mail.Ru. Так что если пользователь пытается отослать спам-письмо, ему приходит извещение о том, что послание не может быть отправлено.

    Интересно отметить, что MRAS проверяет письмо не только на входе, но и через некоторое время после того, как оно попало в пользовательский ящик - это связано с тем, что новые данные о спам-рассылках могли изменить ситуацию и, соответственно, мнение системы. Поэтому если в тот момент, когда письмо обрабатывалось MRAS, оно не определялось как спам-рассылка, а через несколько минут - уже определилось, MRAS перекладывает письмо из «Входящих» в папку «Спам». Естественно, это происходит строго до того, как пользователь зашел в папку «Входящие» и увидел письма.

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

    Что нового(2011)?

    Не секрет, что с массовым распространением социальных сетей, онлайн-игр, интернет-магазинов и прочих сервисов, активно общающихся со своей аудиторией посредством электронной почты, в ящиках пользователей начали скапливаться горы различных уведомлений. И проведенные нами исследования показывают, что для современных пользователей спам - уже далеко не только массовая рассылка про «печать визиток», «гринкарты» или «увеличение самизнаетечего». Спамом люди считают любое нежелательное письмо, будь то надоевшая рассылка с непрозрачной отпиской или давно неинтересный интернет-сервис, который с завидной регулярностью попадает во «Входящие».

    Согласно внутренней статистике Mail.Ru, пользователи ежедневно получают по несколько десятков разнообразных рассылок от социальных сетей, магазинов и интернет-сервисов. Продвинутый пользователь легко избегает скопления рассылок во «Входящих» с помощью фильтров или черных списков. Для того чтобы облегчить жизнь всем остальным пользователям, мы внедрили персональный антиспам.

    Теперь любой пользователь может в один клик раз и навсегда избавиться от надоевшей рассылки интернет сервиса, соц.сети или магазина - т.е. вполне легитимных сервисов. Достаточно выделить одно ненужное письмо и нажать кнопку «Это спам», после чего все письма от этого отправителя будут приходить уже в папку «Спам». И конечно, это не повлияет на доставку писем другим пользователям, речь в данном случае идет о сугубо индивидуальной настройке антиспам-механизма «под себя».

    Кстати, у кнопки «Это спам» есть антипод, без которого механизм персонального антиспама был бы не полным. Кнопка «Это не спам», доступная для писем из папки «Спам», позволяет переместить во Входящие письмо, попавшее в Спам по ошибке и «обелить» адрес отправителя. В дальнейшем все письма от этого отправителя будут поступать во Входящие.

    Разумеется, в реальности все несколько сложнее. При формировании индивидуальных черных и белых списков мы учитываем не только адрес отправителя, но и другие параметры письма. В противном случае, мы бы сделали слишком приятно отправителям спама, подделывающим заголовок From 😉

    И конечно, кроме пополнения индивидуальных спам-фильтров, нажатия кнопок «Это спам» и «Это не спам» используется и для обучения общего антиспама. Так что, нажимая эти кнопки, пользователь делает лучше не только себе, но и всем остальным пользователям.

    Кстати, как и следовало ожидать, кнопку «Это не спам» пользователи нажимают в 10-20 раз реже, чем «Это спам».

    И наконец… как отправлять почту 😉

    Многие из вас имеют прямое отношения к веб-разработке и, так или иначе, отправляют письма своим пользователям. Чтобы ваши письма доставлялись надежно, мы сформулировали рекомендации для отправителей. Их выполнение, конечно, не строго обязательно, однако делает мир лучше 😉 Рекомендации общего характера лежат по адресу http://help.mail.ru/mail-help/rules/general , а более конкретные технические требования - по адресу http://help.mail.ru/mail-help/rules/technical .

    Главная задача почты - доставлять письма своим пользователям. Поэтому мы старательно боремся с ложными срабатываниями антиспама, когда они возникают. Если ваши письма не доходят до пользователей - пишите на [email protected]. Для того чтобы разобраться в проблеме, нужно приложить полную копию письма, которое вы отправляли (со всеми служебными заголовками), а также ответ о недоставке (тоже полностью).

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

    По сути, если все честные отправители будут использовать эти подходы - мировая ситуация со спамом радикально улучшится. Поэтому призываем вас скорее внедрить эти технологии, тем более что настроить это достаточно просто (вот например, документация для настройки DKIM в exim или одна из реализаций DKIM для postfix).

    Сергей Мартынов,
    Руководитель Почты@Mail.Ru

    В этой статье я хочу рассказать о системе антиспама в Почте Mail.Ru и опыте работы с Tarantool в рамках этого проекта: в каких задачах мы используем эту СУБД, с какими трудностями и особенностями ее интеграции столкнулись, на какие грабли наступали, как набивали шишки и в итоге познали дзен.

    Сначала краткая история антиспама. Внедрять антиспам Почта начала более десяти лет назад. Первым решением, которое использовалось для фильтрации, стал Антиспам Касперского в паре с RBL (Real-time blackhole list - список реального времени, содержащий IP-адреса, тем или иным образом связанные с рассылкой спама). В результате количество нежелательных писем снизилось, но из-за особенностей работы системы (инертности) такой подход не удовлетворял поставленным требованиям: быстро (в режиме реального времени) подавлять спам-рассылки. Немаловажным условием было быстродействие системы - пользователь должен получать проверенные письма с минимальной задержкой. Интегрированное решение не успевало за спамерами. Спам-рассыльщики очень динамично меняют (видоизменяют) контент и модель своего поведения, когда видят, что их письма не доставляются до адресата, поэтому мириться с инертностью мы не могли. И начали разрабатывать свою собственную систему фильтрации спама.

    Следующим этапом в Почте Mail.Ru появился MRASD - Mail.Ru Anti-Spam Daemon. По сути он представлял собой очень простую систему. Письмо от клиента попадало на почтовый сервер Exim , проходило первичную фильтрацию c помощью RBL, после чего отправлялось в MRASD, где и совершалась вся «магия». Антиспам-демон разбирал сообщения на части: заголовки, тело письма. Дальше над каждой из них проводились простейшие нормализации текста: приведение к одному регистру, схожих по написанию символов к определенному виду (например, русская буква о и английская буква о превращались в один символ) и т. п. После того как нормализация выполнялась, извлекались так называемые сущности, или сигнатуры письма. Анализируя различные части почтовых сообщений, службы фильтрации спама блокируют на основании какого-либо содержания. Например, можно создать сигнатуру на слово «виагра» , и все сообщения, которые содержат это слово, будут блокироваться. Другими примерами сущности служат URL’ы, картинки, вложения. Также во время проверки письма формируется его уникальный признак (fingerprint) - c помощью определенного алгоритма высчитывается множество хеш-функций для письма. По каждому хешу и сущности велась статистика (счетчики): сколько раз встречалась, сколько раз на нее жаловались, флаг сущности - SPAM/HAM (ham в терминологии антиспама - антоним термину spam, означающий, что проверяемое письмо не содержит spam-контента). На основе этой статистики принималось решение при фильтрации писем: когда хеш или сущность достигнут определенной частотности, сервер может заблокировать конкретную рассылку.

    Ядро системы было написано на С++, а значимая часть бизнес-логики унесена в интерпретируемый язык Lua. Как я упоминал выше, спамеры - народ динамичный и быстро меняют свое поведение. На каждое изменение нужно уметь сразу же реагировать, именно поэтому для хранения бизнес-логики решили использовать интерпретируемый язык (не нужно каждый раз перекомпилировать систему и раскладывать на серверы). Другим требованием к системе было быстродействие - у Lua хороший показатель по скорости работы, вдобавок ко всему он легко интегрируется в C++.

    На рисунке выше проиллюстрирована упрощенная схема передачи письма: от отправителя оно попадает на сервер, проходит первичные проверки (1), если успешно, то передается на проверку MRASD (2). MRASD возвращает результат проверки на сервер (3), и на его основе письмо либо кладется в папку «Спам», либо отправляется пользователю во входящие.

    Внедрение MRASD в десять раз снизило количество спам-сообщений, доставляемых пользователю. Время шло, система совершенствовалась, появлялись новые подсистемы, компоненты, внедрялись новые технологические инструменты. Система расширялась и становилась более сложной, задачи, решаемые командой антиспама, также становились все более разнообразными . Изменения не могли не сказаться на технологическом стеке, о котором я и расскажу.

    Эволюция технологического стека

    В начале развития почтовых сервисов поток писем, да и их контент был намного более скудным, нежели чем в настоящий момент, но и выбор инструментов, и вычислительные способности были, мягко говоря, другими. Из описанной выше «родительской» модели MRASD видно, что для функционирования системы требовалось сохранять разного рода статистическую информацию. При этом процент «горячих» (т. е. часто используемых) данных был высок, что, несомненно, накладывало определенные требования на хранилище данных. В итоге для хранения «холодных» (редко обновляемых) данных выбор остановился на MySQL. Оставался вопрос: какое решение выбрать для хранения горячей (выпечки) статистики? Проанализировав доступные варианты (их производительность и функциональные возможности для хранения горячих, но не критически важных данных), выбор остановили на Memcached - на тот момент это было уже достаточно стабильное решение. Но оставалась проблема с хранением горячих важных данных: у Memcached, как у любого кеша, есть свои недостатки, один из которых - отсутствие репликации, а также проблема с прогреванием кеша, когда он падает (очищается). В результате поисков пристанища для наших важных и горячих данных выбор пал на нереляционную key-value БД Kyoto Cabinet .

    Шло время, нагрузки на почту, а как следствие - на антиспам росли. Появлялись новые сервисы, требовалось хранить все больше данных (Hadoop, Hypertable). К слову, в настоящий момент на пике количество обрабатываемых писем в минуту достигает значения в 550 тысяч (если усреднить этот показатель за сутки, то в среднем за минуту проверяется порядка 350 тысяч сообщений), объем анализируемых логов - более 10 Тб в день. Но вернемся в прошлое: несмотря на растущие нагрузки, требование к быстрой работе с данными (загрузка, сохранение) оставалось актуальным. И в какой-то момент Kyoto перестала справляться с необходимыми нам объемами. Кроме того, нам хотелось иметь более функционально богатый инструмент для хранения важных горячих данных. Словом, нужно было начинать крутить головой для поиска достойных альтернатив, которые были бы гибкими и легкими в использовании, производительными и отказоустойчивыми. В то время в нашей компании набирала популярность NoSQL БД Tarantool, которая была разработана в родных стенах и отвечала поставленным нами «хотелкам». К слову сказать, недавно, делая ревизию наших сервисов, я почувствовал себя археологом: наткнулся на одну из самых ранних версий - Tarantool/Silverbox . Попробовать эту базу данных мы решили потому, что заявленные benchmark’и покрывали наши объемы (точных данных о нагрузках на этот период нет), а также хранилище удовлетворяло наши запросы по отказоустойчивости. Немаловажный фактор - проект находился «под боком», и можно было быстро подкидывать свои задачи с помощью JIRA. Мы были в числе новичков, которые решили испытать у себя в проекте Tarantool, и думаю, что успешный опыт первопроходцев тоже нас подтолкнул к такому выбору.

    Тогда началась наша «эра Тарантула». Он активно внедрялся и до сих пор внедряется в архитектуру антиспама. В настоящее время у нас можно найти очереди, реализованные на базе Tarantool, высоконагруженные сервисы по хранению всевозможной статистики: репутации пользователей (user reputation), репутации отправителей по IP (IP reputation), доверительной статистики по пользователю (karma) и т. д. Сейчас ведется работа по интеграции модернизированной системы хранения и работы со статистикой сущностей. Предугадывая вопросы о том, почему мы в нашем проекте зациклились на одном решении и не переходим на другие хранилища, скажу, что это не совсем так. Мы изучаем и анализируем конкурирующие системы, но в настоящий момент Tarantool успешно справляется с отведенными ему задачами и нагрузками в рамках нашего проекта. Внедрение новой (незнакомой, не используемой ранее) системы всегда чревато осложнениями, требует много времени и ресурсов. Tarantool же в нашем (да и не только) проекте хорошо изучен. Программисты и системные администраторы уже на нем собаку съели и знают тонкости работы и настройки системы, чтобы она была максимально эффективна. Плюс также и в том, что команда разработчиков постоянно совершенствует свой продукт и обеспечивает поддержку (да и близко сидит, что тоже очень удобно:)). Так, при внедрении нового решения, основанного на хранении данных в Tarantool, я очень быстро получал от ребят ответы на интересующие меня вопросы и необходимую помощь (об этом я расскажу чуть позже).

    Краткий экскурс в системы, где используется Tarantool

    Карма - это числовая характеристика, которая отражает степень доверия к пользователю. Задумывалась прежде всего как основа общей системы «кнута и пряника» для пользователя, построенной, не прибегая к сложным зависимым системам. Карма выступает в роли агрегатора данных, полученных от других репутационных систем. Идея системы проста: у каждого пользователя есть своя карма - чем она выше, тем больше мы доверяем пользователю, чем ниже, тем более жестко мы принимаем решения при проверке писем. Так, если отправитель посылает письмо с подозрительным контентом и имеет высокий рейтинг, письмо будет доставлено получателю. Низкая карма учитывается при принятии решения о спамности письма как пессимизирующий фактор. Эта система мне напоминает школьный журнал на экзамене. Отличнику зададут два-три дополнительных вопроса и отпустят на каникулы, а двоечнику придется попотеть, чтобы получить положительную оценку.

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

    RepIP/RepUser

    RepIP и RepUser (reputation IP и reputation user) - высоконагруженный сервис, предназначенный для учета статистики об активности и действиях отправителей (пользователей) с конкретным IP, a также пользователя при работе с почтой за определенный временной интервал. С помощью данной системы мы можем сказать, сколько писем отправил пользователь, сколько из них было прочитано, а сколько помечено как спам. Особенность системы заключается в том, что при анализе поведения мы видим не мгновенную картину (snapshot) активности, а развернутую во временном интервале. Почему это важно? Представьте, что вы переехали в другую страну, где нет средств связи, а ваши друзья остались на родине. И вот спустя несколько лет к вам в хижину протягивают интернет. Вы залезаете в социальную сеть и видите фотографию своего друга - он очень сильно изменился. Как много информации вы можете извлечь из снимка? Думаю, не очень. А теперь представьте, если бы вам показали видео, в котором видно, как ваш друг меняется, женится и т. п., - этакая видеобиография. Думаю, во втором случае вы получите гораздо более полное представление о его жизни. Аналогично и с анализом данных: чем больше информации мы имеем, тем более точно мы можем оценивать поведение пользователя. Можно увидеть закономерность в интенсивности рассылки, понять «привычки» рассыльщиков. На основе такой статистики каждому пользователю и IP-адресу ставится мера доверия к нему, а также устанавливается специальный флаг. Именно этот флаг используется при первичной фильтрации, которая отсеивает до 70% нежелательных сообщений еще к моменту подлета письма на сервер. Данная цифра показывает, насколько значим сервис, поэтому от него и требуется максимальная производительность и отказоустойчивость. И для хранения такой статистики мы также используем Tarantool.

    Статистика хранится на двух серверах по четыре инстанса Tarantool на каждом. Ниже приведен график с количеством выполняемых запросов на RepIP, усредненных за одну минуту.

    При реализации этого сервиса нам пришлось столкнуться с рядом задач, которые были связаны с настройкой Tarantool. От описанных ранее систем данную отличает то, что размер пакета со статистикой, который хранится в RepIP/RepUser, значительно больше: средний размер пакета - 471,97 байта (максимальный размер пакета - 16 Кб). Пакет можно разбить на две логические составляющие: маленькая «базовая» часть пакета (флаги, агрегированная статистика) и объемная статистическая часть (детальная статистика по действиям). Работа с целым пакетом приводит к тому, что возрастает утилизация сети и время загрузки с сохранения записи выше. Ряду систем нужна только базовая часть пакета, но как ее вытащить из тапла (tuple - так именуется запись в Tarantool)? На помощь нам приходят хранимые процедуры. Для этого нужно в файл init.lua дописать необходимую нам функцию и вызвать ее из клиента (начиная с версии 1.6 можно писать хранимые процедуры на С).

    function get_first_five_fields_from_tuple (space, index, key) local tuple = box.select (space, index, key) -- Если запись не найдена - выходим if tuple == nil then return end -- Формируем нужный нам tuple local response = {} for i = 0 , 4 do -- Индексация идет с нуля, а не с 1 table .insert(response, tuple[i]) end return response end

    Проблемы версий до 1.5.20

    Не обошлось и без приключений. После планового рестарта Tarantool клиенты (их было 500+) начинали стучаться на сервер и не могли подключиться (отваливались по тайм-ауту). Надо отметить, что не помогали и прогрессивные тайм-ауты - в случае неудачной попытки подключения время следующей попытки откладывается на некоторую увеличивающуюся величину. Проблема оказалась в том, что Tarantool за один цикл event-loop’а делал accept одному соединению (хотя в него долбились сотни). Проблему можно решить двумя способами: установкой новой версии 1.5.20 и выше или настройкой конфигурационного файла (нужно выключить опцию io_collect_interval, и тогда все будет хорошо). Команда разработчиков пофиксила эту проблему в кратчайшие сроки. В версии 1.6 она отсутствует.

    RepEntity - репутация сущностей

    В настоящий момент ведется интеграция нового компонента по хранению статистики для сущностей (URL, image, attach etc.) - RepEntity . Идея RepEntity похожа на описанную ранее RepIP/RepUser - она также позволяет иметь развернутую информацию о поведении сущностей, на основе которой принимается решение при фильтрации спама. Благодаря статистике RepEntity мы можем отлавливать рассылки спама, ориентируясь на сущности письма. Например, если рассылка включает «плохой» URL (содержащий спам-контент, ссылку на фишинговый сайт и т. п.), мы сможем быстрее заметить и подавить рассылку подобных писем. Почему? Потому что мы видим динамику рассылки этого URL’а и можем детектировать изменение его поведения, в отличие от «плоских» счетчиков.

    Основным отличием (особенностью) RepEntity от системы репутации IP, помимо измененного формата пакета, является существенный рост нагрузки на сервис (увеличивается объем обрабатываемых и хранимых данных и количество запросов). Например, в письме может быть до сотни сущностей (в то время как IP не более десяти), на большую часть из которых нужно загрузить и сохранить полный пакет со статистикой. Отмечу, что за сохранение пакета отвечает специальный агрегатор, который предварительно накапливает статистику. Таким образом, в рамках этой задачи существенно возрастает нагрузка на СУБД, что требует аккуратной работы при проектировании и внедрении системы. Хочу особо обратить внимание, что при внедрении данного компонента используется Tarantool версии 1.5 (это вызвано особенностями проекта), и дальше речь будет идти об этой версии.

    Первое, что было сделано, - оценка необходимого объема памяти для хранения всей этой статистики. Про важность данного пункта могут сказать цифры: на ожидаемой нагрузке увеличение размера пакета на один байт приводит к росту суммарно хранимой информации на один гигабайт. Таким образом, перед нами стояла задача максимально компактно хранить данные в tuple (как я упоминал выше, мы не можем хранить весь пакет в одной ячейке тапла, поскольку существуют запросы на извлечение части данных из пакета). При расчете объема хранимых данных в Tarantool следует помнить, что есть:

    • затраты на хранение индекса;
    • затраты на хранение размера хранимых данных в ячейке тапла (1 байт);
    • ограничение на размер тапла - 1 Мб (в версии 1.6).

    Большое количество всевозможных запросов (чтений, вставок, удалений) приводило к тому, что Tarantool начинал тайм-аутить. Как выяснилось в ходе исследования, причина заключалась в том, что при частой вставке и удалении пакетов вызывалась сложная перебалансировка дерева (в качестве всех индексов использовался древовидный ключ - TREE). В этой БД какое-то свое хитрое самобалансирующееся дерево. При этом балансировка происходит не сразу, а при достижении какого-то условия «разбалансированности». Таким образом, когда дерево было «достаточно разбалансировано», запускалась балансировка, которая подтормаживала работу. В логах можно было увидеть сообщения типа Resource temporarily unavailable (errno: 11) , которые исчезали через несколько секунд. Но во время этих ошибок клиент не мог получить интересующие его данные. Коллеги из Tarantool подсказали решение: использовать другой тип «деревянного» ключа - AVLTREE, который при каждой вставке/удалении/изменении производит перебалансировку. Да, число перебалансировок возросло, но их общая стоимость оказалась ниже. После того как новая схема была заправлена и был произведен рестарт БД, ошибка больше не проявлялась.

    Другой трудностью, с которой нам пришлось столкнуться, была очистка устаревших записей. К сожалению, в Tarantool (насколько мне известно, в версии 1.6 так же) не получится выставить TTL (time to live) для указанной записи и забыть про ее существование, переложив заботы об ее удалении на хранилище данных. Но при этом есть возможность написать вычищающий процесс самому на Lua на основе box.fiber . С другой стороны, такой подход дает большую свободу действий: можно писать сложные условия удаления (не только по времени). Но, чтобы написать чистящий процесс правильно, тоже нужно знать и учитывать некоторые тонкости. Первый вытесняющий процесс (cleaning fiber), который я написал, люто тормозил систему. Дело в том, что количество данных, которые мы можем удалить, значительно меньше общего числа записей. Для того чтобы уменьшить число записей - кандидатов на удаление, я ввел вторичный индекс по интересующему меня полю. После чего написал файбер, который обходил всех кандидатов (у которых время изменения меньше заданного), проверял дополнительные условия для удаления (например, что флаг записи не выставлен) и, в случае если оба условия выполнялись, удалял запись. Когда я тестировал без нагрузки, все прекрасно работало. С низкой нагрузкой тоже все шло как по маслу. Но как только я приблизился к половинной от ожидаемой нагрузки - возникли проблемы. У меня начали тайм-аутить запросы. Я понял, что где-то дал маху. Стал разбираться и осознал, что мое представление о том, как работает файбер, было неправильным. В моем мире файбер был отдельным потоком, который никаким образом (кроме переключения контекста) не должен был влиять на прием и обработку запросов от клиентов. Но позже я выяснил, что файбер использует тот же event-loop, что и тред по обработке запросов. Таким образом, итерируясь в цикле по большому числу записей, без операции удаления я просто «блокировал» event-loop, и запросы от пользователей не обрабатывались. Почему я упомянул операцию delete? Потому что каждый раз, когда выполнялся delete, происходил yield - операция, которая «разблокирует» event-loop и позволяет обработать следующее событие. Отсюда я сделал вывод, что в случае, если n операций (где n нужно искать эмпирически - я взял 100) выполнялось без yield, необходимо делать форсированный yield (например, wrap.sleep(0)). Также следует учесть, что при удалении записи может происходить перестроение индекса и, итерируясь по записям, можно пропустить часть данных для удаления. Поэтому есть еще один вариант удаления. Можно в цикле делать select небольшого количества элементов (до 1000) и итерироваться по этой 1000 элементов, удаляя ненужные и запоминая последний неудаленный. А после этого на очередной итерации выбрать следующую 1000, начиная с последнего неудаленного.

    local index = 0 -- Номер индекса, по которому будут выбираться ключи local start_scan_key = nil -- Первый индекс, с которого будем выбирать local select_range = 1000 -- Количество записей, которое будем выбирать в select_range local total_processd = 0 -- Количество обработанных записей (tuple) local space = 0 -- Номер спейса local yield_threshold = 100 -- Разрешенное количество запросов, которые не вызывают yield local total_records = box.space:len() -- Общее число записей в спейсе while total_processed < total_records do local no_yield = 0 local tuples = { box.space:select_range(index, select_range, start_scan_key) } for _, tuple in ipairs (tuples) do -- Итерируемся по tuples local key = box.unpack ("i" , tuple) if delete_condition then box.delete(space, key) -- delete делает yield no_yield = 0 else no_yield = no_yield + 1 if no_yield > yield_threshold then box.fiber.sleep(0 ) -- Насильно делаем yield end start_scan_key = key -- Обновляем последний неудаленный ключ end total_processed = total_processed + 1 done

    Также в рамках данной работы была попытка внедрить решение, которое помогло бы безболезненно производить решардинг в будущем, но опыт оказался неудачным, реализованный механизм нес в себе большой overhead, и в итоге от механизма решардинга отказались. Ждем появление решардинга в новой версии Tarantool.

    Best practice:

    Можно добиться еще большей производительности, если отключить xlog’и. Но стоит учесть, что начиная с этого момента Tarantool будет выполнять роль кеша, со всеми вытекающими последствиями (я говорю об отсутствии репликации и прогревании данных после рестарта). Не стоит забывать и о том, что остается возможность делать периодически snapshot и при необходимости восстановить данные из него.

    В случае если несколько Tarantool работают на одной машине, то для увеличения производительности стоит «прибивать» каждый из них к ядрам. Например, если у вас 12 физических ядер, то не стоит поднимать 12 инстансов (нужно помнить о том, что у каждого Tarantool, помимо исполняющего треда, есть еще VAL-тред).

    Чего не хватает:

    • Шардинга.
    • Кластерного подхода с возможностью динамической конфигурации кластера, например в случае добавления узлов или выхода узла из строя, аналогичного для MongoDB(mongos), Redis (redis sentinel).
    • Возможности задания TTL (time to live) для записей.

    Подводя итоги

    Tarantool играет важную роль в системе антиспама, на нем завязано множество ключевых высоконагруженных сервисов. Готовые коннекторы позволяют легко использовать его в разных компонентах, написанных на разных языках. Tarantool хорошо зарекомендовал себя: за время использования БД в проекте не возникало серьезных проблем, связанных с ее работой и стабильностью при решении поставленных задач. Напомню, что есть ряд тонкостей, которые нужно учитывать при настройке БД (особенности для версии 1.5) для ее эффективной работы.

    Немного о планах на будущее:

    • Увеличение числа сервисов в проекте, работающих с Tarantool.
    • Миграция на Tarantool 1.6.
    • Также планируем использовать Sophia , в том числе и для задачи repentity, поскольку количество действительно горячих данных не так велико.

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

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

    В самом начале нужно настроить imap php для близкой работы с почтой. Потом написать некоторые алгоритмы, которые в этой статье будут не оптимальные , т.к. каждому нужен свой фильтр (например, некоторые ждут спама от порнографических сайтов).

    Тут будут только идеи и информация для ума. И для тех кто хочет поставить свой фильтр, уже будет фундамент.

    Начинаем...
    Про то как настроить imap php есть куча статей, их можно поискать. У меня Ubuntu, я этот вопрос решил за пару минут и немного изменение в настройках.

    Когда вы уже настроили imap можно его подключать.
    //настройки для подключениея к почте
    $imapaddress = "{imap.gmail.com:993/imap/ssl}";
    $imapmainbox = "INBOX";
    $maxmessagecount = 10;
    $user="имя почты на gmail без @gmail.com";
    $password="длинный и сложный пароль";

    //наша функция, которая удаляет спам
    spam_delete($imapaddress, $imapmainbox, $user, $password, $maxmessagecount);

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

    Вероятность=количество слов всего в письме / слова, которые не прошли фильтр

    Вот как это всё в коде:
    function spam_delete($imapaddress, $imapmainbox, $imapuser, $imappassword, $maxmessagecount)
    {
    $imapaddressandbox = $imapaddress . $imapmainbox;

    //открываем соединение с почтой
    $connection = imap_open ($imapaddressandbox, $imapuser, $imappassword)
    or die("Can"t connect to "" . $imapaddress .
    "" as user "" . $imapuser .
    "" with password "" . $imappassword .
    "": " . imap_last_error());

    Echo "Gmail information for " . $imapuser ."";

    Echo "Inbox headers\n";
    $headers = imap_headers($connection)
    or die("can"t get headers: " . imap_last_error());

    //считаем кол-во почты на сайте, максимум мы 10 можем вывести
    $totalmessagecount = sizeof($headers);

    Echo $totalmessagecount . " messages";

    If ($totalmessagecount<$maxmessagecount)
    $displaycount = $totalmessagecount;
    else
    $displaycount = $maxmessagecount;

    Echo "Message bodies\n";
    //заходим в письмо берем содержание и проверяем на спам
    for ($count=1; $count<=$displaycount; $count+=1)
    {
    $body=imap_fetchbody($connection,$count,"2");
    //разбиваем всё письмо на слова
    $text=explode(" ",$body);
    $spam=0;
    //подсчитываем кол-во слов
    $n=count($text);
    for ($i=0;$i<$n;$i++) {
    $spam+=test_spam($text[$i])==1:1?0;
    }
    //смотрим какая вероятность, что это спам
    // мы кол-во слов делим, на возможные слова,
    //которые подтверждают, что это спам
    $result=$n/$spam;
    //если 50% что это спам, то удаляем
    if ($result>0.5) {
    imap_delete($connection,$count);
    imap_expunge($connection);
    }
    }
    //закрываем imap
    imap_close($connection);
    }

    Алгоритм проверки на спам очень простой, он написан для примера. Если вы хотите написать более сильный и умный алгоритм советую почитать некоторые главы про спам в книге «Программируем коллективный разум», на Хабре про неё тоже писали .

    Алгоритм выполняет два действия:
    1. Определяет слова, которые чаще всего встречаются в спаме
    2. Проверяет на регистр, если всё в в верхнем, то это скорее всего спам.

    Сам код:
    //функция проверки на спам
    function test_spam ($string) {
    //этапы фильтра
    //проверяем по ключевым словам
    $array=array("порно" => 1, "знакомства" => 1, "казино" => 1, "купить" => 1);
    if ($array[$string]==1) {return 1;}
    //не находится ли он в верхнем регистре
    if (strtolower($string)!==$string) {
    return 1;
    }
    return 0;
    }
    ?>

    Протестировал на двух примерах, то вроде работает...

    P.S. Будет очень рад услышать как вы боритесь с мусором. Если вы найдете ошибке в коде сильно не ругайтесь это только пример и фундамент для разработки чего-то большего.

    Спам-фильтр - это программа, которая настроена на обработку и фильтрацию поступающей почты на сервер по определенным параметрам: IP адрес, стоп - слова в тексте письма и регулярные выражения, особенности технических заголовков и т.д.
    Каждый крупный почтовый сервис (Рамблер, Яндекс-почта, Майл.ру...) фильтрует письма на предмет спама, но все же достаточно большое количество нежелательных писем проходят сквозь спам фильтры незамеченными. Почему это происходит, и как правильно настроить свой почтовый ящик, чтобы этого избежать вы узнаете в этой статье.

    Что такое спам
    Спам (spam) - это нежелательная реклама, рассылаемая против воли получателя. Началом бума спама в Рунете можно считать начало 2000-х годов, когда начал очень активно развиваться отечественный сегмент сети Интернет. У спама очень много разновидностей - почтовые спам-рассылки, флуд гостевых книг, форумов и досок объявлений, ICQ спам и пр. В каждом конкретном случае, применяют свои способы защиты от нежелательных сообщений.
    В этой статье будут рассмотрены все основные аспекты почтового (e-mail) спама и защиты от него.

    Спам-фильтр – это защита от рекламы ?
    Действительно в настоящее время на любой почтовой службе применяются те, или иные спам-фильтры. Кроме того, существует множество антиспам-плагинов к популярным почтовым программам The Bat, Outlook Express и другим. Но в тоже время спам, все с новой и новой силой летит в наши ящики. Но самое плохое, на мой взгляд, в другом. Дело в том, что в результате беспощадной борьбы со спамерами иногда теряются многие нормальные письма, которые иногда могут быть очень важны. Именно проблема с доставкой важной почтовой корреспонденции побудила меня на написание данной статьи, и надеюсь, поможет уменьшить поток на ваш ящик всякого мусора, и соответственно уменьшит количество потерянных важных писем.

    Как работает спам-фильтр .
    Антиспам фильтры работают по различным алгоритмам, но главное у всех одно – это анализ письма при его получении по определенным признакам. Все рекламные письма от спамеров написаны по шаблону. Ведь не будет же спамер писать каждое письмо вручную, когда у него база e-mail на 1 млн., или более адресов. И стоит ему запустить рассылку (мгновенно такой объем писем не пошлешь), а первым получателям его писем пожаловаться на спам, то данная рассылка будет сразу занесена в блек-лист, и все последующие письма будут отсечены антиспам фильтрами, использующими эту систему. Это так называемые системы раннего оповещения, которые позволяют блокировать спамера на ранней стадии рассылки.
    Другой способ основан на более детальном изучении письма, и выявлении в нем признаков спам-рассылки. Если письмо изобилует словами: Реклама, уникальное предложение, купить, скидки, распродажа... и т.д. То данное письмо будет однозначно помечено как подозрительное. Письмо может содержать несуществующий адрес отправителя, что легко проверить, или адрес может быть в черном списке. Вместо текста может быть картинка с размещенной рекламой. Нормальные письма, как правило, содержат не большой размер текста. А письма от создателей разного рода пирамид содержат большой размер информации, где указано что, где, как и для чего вам нужно купить часть от некой чудо-программы, и так далее в этом духе.

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

    Мораль – решение о принадлежности письма к спаму принимает программа, а не человек. А программе не свойственно одно качество – искусственный интеллект, а поэтому все спам фильтры при желании можно легко обойти, или говоря проще, обмануть.

    Как обойти спам-фильтр? Легко!
    И тем не менее обойти антиспам системы не просто, а очень просто. В подтверждение тому тот факт, что проблема спама по-прежнему актуальна. Принять 100% верное решение о том нужно это письмо, или нет, может только один человек! И этот человек получатель письма. Действительно, а вдруг человек подписан на рекламную рассылку от какой-нибудь компании. Но это все полемика, а теперь факты. Раз письмо фильтруется антиспам системами по тому, или иному признаку, то спамеру достаточно составить «безобидное» письмо, т.е. письмо максимально похожее на обычное (нужное получателю). Выражение: «Краткость – сестра таланта» здесь очень уместно. Чем короче будет письмо, тем труднее в нем выделить детали, характерные для спама.
    Надо максимально минимизировать содержание рекламных слов в письме, а оставшиеся видоизменить. Слово «Реклама» можно написать так:
    Р е к л а м а (пробелы между буквами), Р-е-к-л-а-м-а (буквы через тире), Рeклaмa (здесь русские буквы «е» и «а» заменены на аналогичные латинские). Как видите вариантов много, для человека любое слово будет иметь смысл «Реклама», а вот многие антиспам системы этого не поймут.
    Что касается обхода аниспам систем работающих по принципу раннего обнаружения спамерской рассылки, то сдесь достаточно заранее составить пару десятков разных шаблонов, и после каждой рассылки 100 тыс. писем менять шаблон письма, домен и e-mail отправителя. Этот подход широко используется в спам-бот сетях (сеть из зараженных пользовательских компьютеров).