Hello,
Andrew V.Statsenko on 04.10.2007 18:07 wrote:
[...]
> Традиционно среднестатистические SMTP системы строятся по приблизительно
> следующей схеме:
>
> [приём письма]-->[постановка в очередь к антиспам-фильтру &
> антивирусу]-->[фильтрация]-->[постановка в очередь доставки на
> backend]-->[доставка в ящик пользователю].
>
> (до приема письма может существовать в очень разных формах RBL/PTR
> подрезка сессий)
>
> Схема классическая, проверенная временем и инсталляциями.
>
> Плюсы: она успешно работает.
>
> Минусы: такая схема имеет _радикально_ низкую производительность и в
> случае операторского сегмента требуется закупать _весьма_ дорогое и
> мощное оборудование и эксплуатировать его понимая, что бОльшая часть
> ресурсов уходит на паразитную нагрузку в виде спам-трафика.
Категорически не согласен - производительность у такой системы не хуже, чем у описанной вами ниже.
> Насколько это минус ? Допустим мы делаем небольшую почтовую системку, а
> именно покупаем за 100k$ пару midrange серверов + систему хранения. По
> моим (разумеется, IMHO) оценкам 75k$ мы выбросим на вете..^W спам .
> Решать "на сколько $" это минус - вам. Разумеется оценки могут быть
> разными и свое мнение экспертным я тут не считаю.
>
>
> Что же предлагается автором взамен ? Ничего принципиально нового в мире
> антиспама, но немного другая "эшелонированная система фильрации",
> которая оптимизированная на производительность и эффективность и
> построенная на следующих ключевых принципах:
>
> 1. прохождение SMTP трафика контролируется на каждом этапе.
> 2. блокировка/классификация спама на каждом этапе производится
> _минимально_ возможными ресурсами сервера.
>
>
> Вся система фильтрации разбивается на уровни. Чем "глубже" уровень в
> иерархии, тем более ресурсоёмкие алгоритмы применяются для анализа
> письма. Нижнее уровни иерархии имеют обратные связи с более верхними и
> "обучают" их. Приложены все усилия к тому, чтобы верхние уровни работали
> максимально эффективно и подрезали бОльшие объемы паразитного трафика,
> чем нижние экономя ресурсы системы.
Вот всё это ничто не мешает реализовать в "классической" системе в одной программе. Т.е. если письмо с проблемного IP - его незачем проверять Байесом и т.п.
> Рассмотрим схему прохождения одного письма.
>
>
> 1. Layer #0 - Dynamic firewall, блокирующий на N часов особенно
> проблемные (поедающие ресурсы системы) хосты BOTNET'a.
>
>
> 2. Layer #1 - SMTP pre-DATA time analyzer: множество проверок, которые
> можно выполнить после RCPT TO, а именно: helo/A/PTR/RBL/SPF check,
> sender verificator, transaction delay и пр. Итогом его работы является
> промежуточная резолюция: принять, не принять, не принять временно.
>
> Этот уровень особенно хорош в борьбе с массовиками-затейниками (см.
> классификацию спамеров).
>
> Повторюсь и особенный акцент хочу сделать на том, что система должна
> обеспечить на этом этапе:
>
> - максимально легкий пропуск легитимного трафика,
> - максимально осложненный пропуск спам-трафика,
>
> следовательно, требуется _очень_ продуманный подход к разработке
> анализатора.
>
>
> 3. Layer #2 - Signatures analyzer.
>
> Это уровень работает после SMTP DATA, но _до_ выдачи финального 250 OK и
> у нас уже есть все mail body.
>
>
> Приципы работы: из почти любого спам-письма можно вычленить 1..10
> коротких устойчивых сигнатур. Имея базу в ~500k таких сигнатур (текущая
> спам-погода в трафике) и делая 1 (!) lookup в эту базу мы весьма дешевым
> и быстрым способом детектируем спам.
>
> Осталось только озаботиться нарезкой подобных сигнатур автоматизированно
> и содержать эту базу в должном и актуальном трафику виде.
>
>
> 4. Layer #4 - Bayes analyzer.
>
> Это уровень тоже работает после SMTP DATA, но _до_ выдачи финального 250
> OK и у нас уже есть все mail body.
Это значит, что ваша система должна быть настолько быстрой, чтобы уложиться в time-out SMTP. При этом способной анализировать сотни писем одновременно, ведь SMTP сессий одновременно может быть много. При разговорах о многочасовых очередях на SpamAssassin в это как-то не верится.
Кстати, вставлю свою рекламу :-)
Cloudmark плагин <http://www.stalker.com/CGPCloudmark/> - очень быстрый
Из отчёта на Celeron 2.8 ГГц:
1061 messages rated
Scanning time:
Min: 0.002 sec. Avg: 0.008 sec. Max: 0.649 sec.
Resource usage:
User: 11.601 sec. 0.962%
System: 1.408 sec. 0.116%
> Можно долго спорить хорош или плох baeyes. Есть множество разных мнений,
> но я бы предложил оставить сейчас этот спор за рамками темы.
>
> Мы - используем. Относительно хороший и быстрый. С baeyes database per
> email account + подлючаемая common bayes database, если базе
> пользователя мало данных.
>
>
> Это тяжелая по CPU проверка и до этого уровня должно доходить не более
> 10-20% спам-трафика, чтобы оставаться в требуемых нам рамках
> производительности.
>
>
> 5. Layer #5 - Antivirus. Btw, простой способ отрезать фишеров.
Его можно поднять повыше, т.к. антивирусы, по моему опыту, быстрее спам-анализаторов, т.к. вирусов намного меньше, чем вариантов спама. Исключение - если надо распаковывать архивы.
>
> Как видите мы дошли до конца SMTP сессии, но до сих пор не сказали 250
> OK. Здесь у нас, в соответствии с политикой фильтрации, есть выбор:
> принять, не принять (прошу не бить RFC'ой по рукам) или отправить в
> "карантин", который размещается на значительно более дешевом storage'e и
> чистится по рассписанию.
>
>
> Также замечу, что мы до сих пор не нагрузили нашу систему по I/O -
> fsync(2) еще не сделан и сервер не загибается по I/O от 5k SMTP сессий,
> а вся работа по фильтрации уже выполнена.
>
>
> Осталось лишь принять решение, что делать с этим письмом.
>
>
>
>
> Не думаю, что открыл для подписчиков Америку, но скромно, надеюсь, что
> это эссе и наш опыт будет кому-нибудь интересен. Буду рад комментариям и
> критике.
>
>
>
> P.S.
> На подобных принципах построен наш Spamguard -
> http://www.naunet.ru/s/service/spamguard/ и мы будем рады
> сотрудничеству.
>
>
> P.P.S.
> Пожалуйста, не бейте за рекламу - не смог удержаться :-)
>
>
>
>
-- RomanПолучено Fri Oct 05 07:45:41 2007
Этот архив был сгенерирован hypermail 2.1.8 : Fri 24 Apr 2015 - 16:15:49 MSK