Re: фильтрация спама в промышленных масштабах и наших измышлениях.

От: Roman Prokhorov <CGatePro_at_mx_ru>
Дата: Sat 06 Oct 2007 - 06:25:08 MSD

Hello,
  Michael Kulakov on 05.10.2007 12:20 wrote:

>>> Традиционно среднестатистические SMTP системы строятся по приблизительно
>>> следующей схеме: [приём письма]-->[постановка в очередь к
>>> антиспам-фильтру & антивирусу]-->[фильтрация]-->[постановка в очередь

>>> доставки на backend]-->[доставка в ящик пользователю]. (до приема письма

>>> может существовать в очень разных формах RBL/PTR подрезка сессий) Схема
>>> классическая, проверенная временем и инсталляциями.  Плюсы: она успешно
>>> работает. Минусы: такая схема имеет _радикально_ низкую
>>> производительность и в случае операторского сегмента требуется закупать
>>> _весьма_ дорогое и мощное оборудование и эксплуатировать его понимая, что
>>> бОльшая часть ресурсов уходит на паразитную нагрузку в виде спам-трафика.
>> Категорически не согласен - производительность у такой системы не хуже,
>> чем у описанной вами ниже.
> 
> :) то есть запись на диск уже ничего не стоит ?

Практически ничего. Только не смешивайте запись в очередь, где файлы мелкие, а средний размер спам-письма не превышает 8К, с записью в экаунты, где файлы мегабайтные. A для очереди (и логов) можно и отдельный диск поставить, одного U320SCSI 15000rpm за $200 должно быть более чем достаточно.

>> Вот всё это ничто не мешает реализовать в "классической" 
>> системе в одной программе. Т.е. если письмо с проблемного IP - его 
>> незачем проверять Байесом и т.п.
> 
> нет проверки байесом проблемного ip. оно или будет обработано на предыдущих
> уровнях или это уже "не проблемый ip", а скорее достаточно валидное письмо.
> но на cgp сейчас так удобно делать не получается.

На CGPro давно есть проверки IP по RBL и SPF. Первый из них бывает так что отсеивает 90% спама без всяких фильтров.

>> сотни писем одновременно, ведь 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%
>> --------------------------
>> Основан на анализе сигнатур как в Layer #3. И достаточно точный. 
>> Так что рекомендую.
> 
> то есть все начальные dynamics layers - пропущены ? с ними - быстрее, чем
> без них :)

Нет - проверка по RBL всегда есть, только не в плагине а на самом сервере. А насчёт быстрее - это как получится: бывает бытрее принять письмо, чем ждать ответов от DNS при проверке всех адресов.

-- 
Roman

Получено Sat Oct 06 02:25:13 2007