[Карта]                [Начало]                [Sendmail-ссылки]                [Синтаксис]                [Типовые задачки]                  [Задачки по маршрутизации]                  [Задачки по маcкарадингу]                  [SendmailACL]                  [Spamooborona]                  [VadeRetro]                  [Regex]                  [Тонкости]                  [Недок.особен.]                  [Несущ.юзеры]                  [Прячемся!]                  [RFC1893.Цитаты]                  [ТП.Эмоции]                  [Антиспам&Разум]                  [Экзерсисы]                 


Антиспам VadeRetro в сравнении со Спамообороной.
VadeRetro - возвращайся ??? Va - одна из форм глагола vai - идти; de - артикль ; retro - обратно, назад
Спасибо за участие А.Карачанскому, который, основываясь на лат. изречении "Vade retro, Satanas!", предложил перевести это слово как "отойди".
В общем, VADERETRO <=> ИЗЫДИ, СПАМ!!!


  • I. Сезон 2008-2009.
  • II. Сезон 2010-2011.
  • III. Сезон 2011-2016.
  • IV. Обсуждения антиспам-систем.
  • V. Важное, очень полезное.
  • VI. ...
  • X. Обратная связь.


    • Дано: P4/XEON, 2,66GHz, 256Mb ОЗУ, 512Mb swap; SUSE10.0; sendmail 8.13.6, с апреля 2008г VadeRetro вот в такой связке:
    drwebd (drweb-демон, общий и для антивируса, и для антиспама) +
    drweb-maild-sendmail (модуль, соединяющий демон, sendmail и фильтры) +
    drweb-maild-plugin-vaderetro (антиспам-фильтр)
    С 29.05.2008 2Gb ОЗУ.

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

    1. Сравнение плюсов

    1. Я пока в процессе наблюдения за качеством отлова спама. Инфу об этом выложу позже, как накоплю материал.
    VadeRetro (демо-версия) ( связка drweb-4.44.0 + drweb-maild-sendmail-4.44.1 + drweb-maild-plugin-vaderetro-4.44.1 скачана из раздела Dr.Web для Unix-систем / Защита почтовых серверов Unix / Антиспам / ) установлен на mx c бОльшим весом.
    Спамооборона - на mx с минимальным весом (на основной mx).
    Mx c VadeRetro исключен из списка непроверяемых адресов на основном mx-e, поэтому на основном mx-е возможно подсчитытать количество спам-писем, нераспознанных VadeRetro и оказавшихся спамом по версии Спамообороны.
    К сожалению, в отличие от СО в текущей версии VR невозможно указать в теме спам-письма набранный вес, но ТП обещает добавить такую возможность в след. версии.

    С 9 июля 2008 лицензионная связка drweb-4.44.0 + drweb-maild-sendmail-4.44.2 + drweb-maild-plugin-drweb-4.44.2 + drweb-maild-plugin-vaderetro-4.44.2 скачана из раздела Dr.Web для Unix-систем / Защита почтовых серверов Unix / Антивирус + Антиспам / и установлена на основной почтовик, и пока могу сказать, что есть незначительное увеличение непомеченного спама. И так же, как и в случае со Спамообороной, большинство пропущенных спам-писем приходит с mail.ru. VadeRetro тоже ему особо доверяет.

    2. Пункт второй из плюсов СО для VR не актуален, потому что VR в выбранной мною связке не ведет файл обслуживаемых адресов, а, стало быть, VR не скажет "этот получатель прописан в mailboxes, поэтому я его проверю, а этот - нет, поэтому письмо пройдет со статусом SKIP."

    3. Пункт третий "Если спам-вес письма превышает определенное значение, которое можно изменять, то такое письмо можно либо отвергнуть, либо тихо уничтожить" справедлив и для VadeRetro.
    Но!!! Невозможно установить индивидуальные пороги отказа. Для меня это большой минус. Хотя ребята из ТП обещают в след. версии добавить такую возможность.
    Конечно, существует возможность производить анализ порогов отказа и затем удалять письма, набравшие большой вес, самостоятельно с/п procmail. Но было бы логичнее, если бы это делал сам VR.
    02.02.2009. Ну вот как раз на днях один юзер попросил индивидуальный порог отказа. Решаем задачку с.п. procmail.
    Необходимо удалять всю его почту, набравшую больше 100 баллов. Я подумала-подумала и решила все-таки не удалять, а складывать в отдельный файл: знаю я эти приколы "где мое письмо от 31 июня 2000 года ???"
    Итак, 1) в домашнем дире юзера создаем файл .procmailrc, владельцем указываем этого юзера.
    LOGFILE=/var/log/spamlog/terrapin
    :0
    * ^X-Drweb-SpamScore: [1-9][0-9].+
    /var/spool/mail/spam/spam-terrapin
    или
    /dev/null
    2. Создаем лог-файл /var/log/spamlog/terrapin, владелец файла - юзер
    3. Создаем спам-файл /var/spool/mail/spam/spam-terrapin, владелец файла - юзер. Обычно эти файлы logrotate'ом обрабатываются с периодом в неделю.

    4. Прилагается белый список, черный список. Но!!! Невозможно пока оказаться от проверки письма, если оно идет из локальной сети (белый список по ip-адресам) .
    Поэтому приходится использовать вот такую опцию в разделе [Users] в конфиге maild_sendmail.conf, чтобы отказаться от проверки почты с отправителем - моим доменом.
    sender:@anrb\.ru=all:-vaderetro
    Но ее минус в том, что обратный адрес легко подделывается, и таким образом мы открываем доступ спамерам. Хотя сейчас эта лазейка прикрыта.
    Плюс в том, что эта опция может использоваться как безусловный белый список, чего нет у Спамообороны.

    5. VR не пишет получателей вовсе. Это плохо. Для составления отчета пользователям мне теперь приходится добавлять через syslog получателя самостоятельно.

    5. VR тоже умеет пропускать почту без проверки и отлупов при сбоях.
    # ProcessingErrors ={action}
    # This parameter defines what action should be applied to messages which
    # generate errors at scanning.
    # Possible main actions: tempfail, pass, discard, reject.
    # Possible optional actions: quarantine, redirect, notify.
    ProcessingErrors = pass


    2. Сравнение минусов.

    2.1-2.2.
    В силу п. 1.2 у VR нет ограничений по проверяемым адресам, алиасам, спискам рассылок. Проверено будет все!

    2.3. Белый список email-адресов также является условным: письмо будет проверено и в этом случае, но из веса будет вычтено определенное значение. Но! В отличие от Спамообороны есть другая опция , которая позоволяет отказать в проверке письму, пришедшему с определенного электронного адреса(адресов).

    2.4. Привязка к почтовому домену есть только в связке drwebd + proxy + VadeRetro.Но она есть.

    2.5. Тех.поддержка невероятно и традиционно оперативная. Эта самая быстрая ТП (среди ТП коммерческих продуктов), которую я за свою жизнь видела. Время отклика от 10 минут до суток, но чаще всего отвечают в течение получаса-часа.
    И кроме того, ТП чрезвычайно доброжелательная. В этом для меня самая большая загадка :)
    Ни разу на мои многочисленные вопросы и пожелания мне не ответили в духе "с трудом представляю, зачем и кому это может быть нужно".
    Стиль работы и общения техподдержки создает очень комфортное ощущение "стены за спиной", а это очень важно.

    3. Дневник проблем.

    3.1. Самоостановы. Самоостановы случились 2 раза. Но что радует. В комплекте имеется monitor, который сам обнаруживает останов демона и сам его перезапускает и извещает меня о конфузе. Самоостановы не были вызван большой нагрузкой, кое-какой маячок обнаружился (т.е., вроде бы причина ребятам ясна).
    ТП я известила, ребята поняли, о чем идет речь, и обещали к след. версии подправить.

    3.2. Проблема с созданием тредов: thread_create() failed: 11, try again.
    По поводу проблемы с созданием тредов, к сожалению, могу констатировать ее наличие и в связке sendmail+VadeRetro. В ближайших планах - наращивание памяти (скорее всего в эти дни). Если наращивание памяти не поможет, то, поскольку мысли по поводу неблагополучия milter, libmilter и всего, что с ними связано, появились еще при общении со Спамообороной и антивирусом ДокторВеб, я начинаю подумывать о тестировании других почтовых систем в связке с анти(вирусами/спамами).
    29.05.2008. С сегодняшнего дня ОП - 2Gb. Проблем с созданием тредов не наблюдается.
    20.08.2008. И все-таки эта проблема сохраняется.
    20.10.2008. Т3р - после двух изменений в конфигурации сервера из предыдущей ссылки пока все спокойно.
    26.11.2008. И все-таки проблема с самоостановами есть. И она опять не связана с нагрузкой.
    16.12.2008. После выставления в конфиг рекомендованных TП значений, все ОК (т3р).
    InPoolStackSize = 2m
    OutPoolStackSize = 2m

    3.3. Отсутствие номера sendmail-процесса в строках, заполняемых VR.
    VR пишет номер sendmail-процесса только в строке drweb-milter, сообщения drweb-maild можно привязать к определенному процессу только через имя директории, в которую складывается сообщение на период обработки.

    3.4 Непомеченный спам.
    20.01.2009. Когда полгода назад я выбирала между Спамообороной и VadeRetro, значительную, если не решающую, роль сыграла разница в цене. Причем, несмотря на хороший результат пробного тестирования, я обратила внимание заинтересованных сторон на возможное ухудшение качества фильтрации, но это никого не испугало. И до сей поры VadeRetro держался молодцом. В течение последней недели наблюдаю возросшее количество пропущенного спама. В течение дня в мой почтовый ящик попадает до 20 непомеченных спам-писем (с учетом того, что в мой почтовый ящик попадает почта, поступающая на всевозможные административные алиасы)
    Спасибо Владимиру Васильеву: 25 спам-писем, пропущенных VR, были отправлены на почтовую систему со Спамообороной. СО пометила спам-меткой 22 письма, из них 19 набрали больше 20 баллов.
    Посмотрим, как поведет себя VR дальше.
    22.01.2008. Ситуация стабилизировалась. Т3р.
    10.02.2009. Сглазила. За последние полмесяца Спамообороне было отправлено 76 не помеченных VadeRetro спам-писем, результат для VR плачевный. Спамооборона не пометила только 16 писем, а это около 20%. :(
    17.02.2009. Наблюдается странная вещь: если делать forward (TheBat! вложение исходного письма с сохранением заголовков) письма, то, как правило, Спамооборона не помечает это письмо, при этом оно набирает только до 4-х баллов. А если делать redirect (прежние заголовки не сохраняются, вложения нет) - то почти все спам-письма распознаются.
    Пример forward'a. Пример redirect'a.
    А в целом, ситуация по VR опять выправилась: в день не более 1-2 непомеченных спам-письма.
    Общая статистика по CO: 85 спам-писем помечены СО, 23 непомечены.
    10.03.2009. Ситуация с пропущенным спамом нестабильная. То тихо-тихо, то до 10 непомеченных спам-писем. Добавила себе вот такую штуку - часть непомеченного спама c zen.spamhaus.org-dnsbl уходит в папку X-SPAM.
    Да, продолжаю непомеченный спам "показывать" Спамообороне. За сегодня из 6 непомеченных VR писем СО пометила только одно. Общий счет за 2 с половиной месяца: 177 спам-писем СО пометила, 54 - нет.

    3.5 Нехватка памяти на другие сервисы.
    25.03.2009. Дано: ОП 2ГБ, на сервере крутятся DrWeb (drwebd + drweb-maild-sendmail + drweb-maild-plugin-vaderetro), jabber, MySQL. Почтовый трафик небольшой (300-1000 писем в день), но DrWeb-maild занимает порядка 1,2Гб, оставшейся памяти стало не хватать на другие сервисы.
    Решение от Kevin. Сегодня уже точно закончил разбор проблем с саппортом, провел много тестов, вроде всё работает, сейчас maild кушает у меня 279м.
    Опция решает сколько кушает наш процесс
    MaxPoolSize = {численное значение}
    Максимальное количество страниц памяти (размером 8 Кб), выделяемых для базы данных. Если значение параметра равно 0, Dr.Web MailD автоматически определяет эту величину, исходя из доступного объема физической памяти. В текущей версии Dr.Web MailD при перезапуске программного комплекса по сигналу SIGHUP изменение данного параметра происходить не может. Значение по умолчанию: 0
    Я поставил сейчас 20480. Пока что ошибок в логах нигде не наблюдаю.
    Тиккет саппорта - здесь.


    5. Советы .

    5.1-5.3. Установка проста, советовать тут мне нечего. Разве что, пока ребята не подправили комментарии в конфигах, обратите внимание на то, что названия и местоположение одних и тех же сокетов, которые упоминаются в разных конфигах, должны совпадать.
    Ну и для любителей устанавливать все вручную все же скажу, что лучше воспрользоваться родным install.sh: скрипт простой, ничего лишнего не делает, а без него нужно знать права и владельцев веберовских директорий и файлов в /var/drweb. Без правильных прав и владельцев демон не стартует.
    20.08.2008. Все-таки нужно читать док-ию и следовать ее указаниям:
    readme_sendmail.rus:
    Первым следует устанавливать tarball-архив самого Dr.Web MailD, и только после него tarball-архивы плагинов (плагины могут устанавливаться в произвольном порядке). Если до этого были установлены почтовые фильтры антивируса Dr.Web для Unix, то перед установкой Dr.Web MailD их следует удалить (при необходимости предварительно сохранив конфигурационные файлы), подробнее см. в п. 6.
    То есть в моем случае важно было сначала запустить install.sh из drweb-maild-sendmail-4.44.2,
    затем из drweb-maild-plugin-drweb-4.44.2 и затем из drweb-maild-plugin-vaderetro-4.44.2.
    Ну а пакет drweb-4.44.0 нужно просто развернуть вручную, install.sh к нему не прилагается.

    5.4&5.5 имеют место и здесь, => тут надо разбираться с SUSE.

    5.6 VadeRetro не ведет список белых IP адресов. А, значит, пока невозможно отказатьcя от проверки письма, которое идет, например, из локальной сети.
    Нов след. версии это будет в таком виде:
    client-ip:127.0.0.1 cont scan=all:-vaderetro

    5.7 Обратите внимание на то, что в белых списках должны быть прописаны конвертные отправители. Спамооборона же работает с внутренними отправителями.

    5.8 Для VR лучше выбрать 8 уровень логирования: define(`confMILTER_LOG_LEVEL',`8'), иначе в лог пишется лишняя инфа.

    При 9 уровне логирования VR напишет небольшое сочинение:
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: from=<davisgil@earthlink.net>, size=2048, class=0, nrcpts=1, msgid=<000401c8b418$026a70e4$ce2203bd@gcghagu>, proto=ESMTP, daemon=MTA, relay=[91.185.11.85]
    May 12 16:15:45 apache drweb-milter: [2811445265] milter INFO [m4CAFYKd027197]: success save mail to /var/drweb/msgs/in/E/0001EE0E/
    May 12 16:15:45 apache drweb-maild: [114696] vaderetro INFO start processing msg 0001EE0E ...
    May 12 16:15:45 apache drweb-maild: [114696] vaderetro INFO Attach msg 0001EE0E to plugin vaderetro...
    May 12 16:15:45 apache drweb-maild: [114696] vaderetro INFO SpamState = 1; SpamScore = 900; Version=Vade Retro 01.264.01 AV+AS; apply: [pass]; time=76 ms
    May 12 16:15:45 apache drweb-maild: [114696] vaderetro INFO Msg 0001EE0E was accepted by plugin vaderetro
    May 12 16:15:45 apache drweb-maild: [114696] vaderetro INFO msg 0001EE0E is accepted: send it by filter
    May 12 16:15:45 apache drweb-milter: [2811445265] milter INFO drweb-maild return pass action for msg 0001EE0E
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter insert (4): header: Subject: [VR:SPAM:: ]=?koi8-r?B?yM/Sz9vJxSDTy8nEy8kgzsEgz9TE2cggz9Qg18XE1d3JyCDP0MXSwQ==?=\n\t=?koi8-r?B?1M/Sz9cg8s/T08nJ?=
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter insert (5): header: Date: Mon, 12 May 2008 08:23:36 +0000
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter insert (6): header: MIME-Version: 1.0
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter insert (7): header: Content-Type: text/plain;\n\tcharset="koi8-r"
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter insert (8): header: Content-Transfer-Encoding: 8bit
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter insert (9): header: X-Priority: 3
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter insert (10): header: X-MSMail-Priority: Normal
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter insert (11): header: X-Mailer: Microsoft Outlook Express 6.00.2900.3138
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter insert (12): header: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter insert (13): header: X-Drweb-SpamState: yes
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter insert (14): header: X-Drweb-SpamState-Num: 1
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter insert (15): header: X-Drweb-SpamScore: 900
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter insert (16): header: X-Drweb-SpamVersion: Vade Retro 01.264.01 AV+AS
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter delete: header Subject: =?koi8-r?B?yM/Sz9vJxSDTy8nEy8kgzsEgz9TE2cggz9Qg18XE1d3JyCDP0MXSwQ==?=\n\t=?koi8-r?B?1M/Sz9cg8s/T08nJ?=
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter delete: header Date: Mon, 12 May 2008 08:23:36 +0000
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter delete: header MIME-Version: 1.0
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter delete: header Content-Type: text/plain;\n\tcharset="koi8-r"
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter delete: header Content-Transfer-Encoding: 8bit
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter delete: header X-Priority: 3
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter delete: header X-MSMail-Priority: Normal
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter delete: header X-Mailer: Microsoft Outlook Express 6.00.2900.3138
    May 12 16:15:45 apache sendmail[27197]: m4CAFYKd027197: Milter delete: header X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
    May 12 16:15:45 apache drweb-milter: [2811445265] milter INFO [m4CAFYKd027197]: processing message from <davisgil@earthlink.net> is over
    May 12 16:15:47 apache sendmail[27332]: m4CAFYKd027197: to=<kuchod@anrb.ru>, delay=00:00:04, xdelay=00:00:02, mailer=smtp, pri=122048, relay=mail.anrb.ru. [212.193.134.2], dsn=2.0.0, stat=Sent (m4CAEbdG014778 Message accepted for delivery)

    Если выбрать другой уровень логирования (define(`confMILTER_LOG_LEVEL',`8')), то , на первый взгляд, вывод становится лаконичным:
    May 12 15:52:20 apache sendmail[22118]: m4C9qGMx022118: from=<asetobe@earthlink.net>, size=995, class=0, nrcpts=1, msgid=<000401c8b415$05b9882f$748f3f8d@tgktsgr>, proto=ESMTP, daemon=MTA, relay=89-178-154-134.broadband.corbina.ru [89.178.154.134]
    May 12 15:52:20 apache drweb-milter: [2794029117] milter INFO [m4C9qGMx022118]: success save mail to /var/drweb/msgs/in/1/0001ED41/
    May 12 15:52:20 apache drweb-maild: [131081] vaderetro INFO start processing msg 0001ED41 ...
    May 12 15:52:20 apache drweb-maild: [131081] vaderetro INFO Attach msg 0001ED41 to plugin vaderetro...
    May 12 15:52:20 apache drweb-maild: [131081] vaderetro INFO SpamState = 1; SpamScore = 900; Version=Vade Retro 01.264.01 AV+AS; apply: [pass]; time=47 ms
    May 12 15:52:20 apache drweb-maild: [131081] vaderetro INFO Msg 0001ED41 was accepted by plugin vaderetro
    May 12 15:52:20 apache drweb-maild: [131081] vaderetro INFO msg 0001ED41 is accepted: send it by filter
    May 12 15:52:20 apache drweb-milter: [2794029117] milter INFO drweb-maild return pass action for msg 0001ED41
    May 12 15:52:20 apache drweb-milter: [2794029117] milter INFO [m4C9qGMx022118]: processing message from <asetobe@earthlink.net> is over
    May 12 15:52:20 apache sendmail[22141]: m4C9qGMx022118: to=<myrna@anrb.ru>, delay=00:00:00, xdelay=00:00:00, mailer=smtp, pri=120995, relay=mail.anrb.ru. [212.193.134.2], dsn=2.0.0, stat=Sent (m4C9pBFF031515 Message accepted for delivery)

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

    На мой взгляд записывать в лог "Milter insert, Milter delete" смысла нет, вполне достаточно "Milter change", как это делает CO. При одинаковом уровне логирования (9) СО лаконичнее, и вместе с тем, все , что важно для меня, показано.
    Вот вы скажете, что я придираюсь, и все такое, а я читаю логи. Да-да-да, ч-и-т-а-ю! Конечно, не все 100 Мб, а выборочно: крон присылает мне по 200 строк лога, и кроме того мои скрипты шерстят лог на наличие нестандартных или критичных записей.
    И поэтому для большое значение имеет то, как фильтр отчитывается о проделанной работе:
    - не портит ли логику maillog'a;
    - вся ли важная информация выводится;
    - как много лишней для меня информации, которая мешает нормальному восприятию данных.


    5.9 Будьте крайне осторожны с уведомлениями антивируса DrWeb.
    Желая высылать уведомления только локальным юзерам, я подправила конфиги соответств. образом и наступила на страшные грабли: во время пиковой нагрузки случился самоостанов DrWeb, почта пошла непроверенная, и я засыпала уведомлениями об этом весь инет и даже попала в некоторые черные списки (не сработал отказ от высылки уведомления нелокальныи юзерам)!
    В общем, "и на старуху бывает проруха". Выяснить, что не так было в моем конфиге пока не удалось, а выставлять debug-уровень пока нет времени (за ним же нужно будет следить). Поэтому пока все уведомления вообще отключены.
    В свете этого происшествия, я подумываю вовсе отказаться от высылки уведомлений админу, когда почта перестает проверятся при ошибках, потому что в часы пиковой нагрузки это провоцирует дополнительный (в моем случае просто лавинообразный) трафик.
    По-моему, лучше написать скрипт, который будет проверять лог на такие события, скажем, раз в 10 минут и извещать меня одним письмом.

    15.09.2008. С помощью ТП все же удалось разобраться с синтаксисом секций [Rule], [Users], [Viruses].
    Для того, чтобы при получении вируса, уведомления высылались лишь получателям/отправителям моего домена + мне, нужно было выставить такие значения в /etc/drweb/maild _sendmail.conf:
    [Rule] # default
    notify = block
    notify.Virus = block
    notify.Virus = allow(admin:sender) if sender:@anrb\.ru
    notify.Virus = allow(admin:rcpt) if rcpt:@anrb\.ru
    а не
    notify.Virus = allow(any) if @anrb\.ru - это вызовет отправку уведомлений и получателю, и отправителю, и админу, потому как означает "notify, если вирус, и, если отправитель ИЛИ получатель из домена anrb.ru", а так как я (ттт3р) - не open relay, то такое условие будет выполняться всякий раз при поступлении зараженного сообщения.
    В данном случае меня спутал файл addresses.conf из предыд версии, который описывал
    # The file with the list of addresses allows to block notifications
    # to specified addresses or group of addresses depending on address role
    # in mail transaction.
    и то, что мне нужно, вполне описывалось одной строкой:
    any !"@(anrb)|(ns1\.anrb)|(magarif)\.ru|(102avto)\.ru"
    т.е. блокировать любые уведомления, если они не предназначены для доменов anrb.ru, ns1.anrb.ru, magarif.ru, 102avto.ru.

    Ну и для кучи приведу пример секции [Users].
    [Users]
    Здесь я отказываюсь от действия фильтра VadeRetro, если отправитель из моего домена.
    #Отказываюсь от обоих фильтров, если адреса отправителей - мои локальные root'ы + пара masters. Ес-но, предварительно я проверяю достоверность такой почты.
    sender:root@mail\.anrb\.ru scan=all:-drweb:-vaderetro
    sender:root@apache\.anrb\.ru scan=all:-drweb:-vaderetro
    sender:root@ns1\.anrb\.ru scan=all:-drweb:-vaderetro
    sender:drwebmaster@anrb\.ru scan=all:-drweb:-vaderetro
    sender:postmaster@anrb\.ru scan=all:-drweb:-vaderetro
    Кроме того, все отправителям, подписанным моим доменом, разрешаю проходить без проверки спам-фильтром.
    sender:@anrb\.ru scan=all:-vaderetro
    Если все правильно, то в логе должно быть следующее при приходе вируса:
    Sep 16 18:16:36 mail drweb-notifier: [81926] notifier.rules DEBUG GetNotify: success find 'virus' admin = allow
    Sep 16 18:16:37 mail drweb-notifier: [81926] notifier.rules DEBUG NotifyValue::Get: 'virus' for role sender NOT match rcpt:[< terrapin@anrb.ru >] with sender =~ "@anrb\.ru"
    Sep 16 18:16:37 mail drweb-notifier: [81926] notifier.rules DEBUG NotifyValue::Get: 'virus' for role sender NOT match sender:[< klaretta.fowler@wgint.com >] with sender =~ "@anrb\.ru"
    Sep 16 18:16:37 mail drweb-notifier: [81926] notifier.rules DEBUG NotifyValue::Get: 'virus' find val for role sender = block
    Sep 16 18:16:37 mail drweb-notifier: [81926] notifier.rules DEBUG GetNotify: success find 'virus' sender = block
    Sep 16 18:16:37 mail drweb-notifier: [81926] notifier.rules DEBUG GetNotify: success find 'virus' rcpt = allow
    И следующее при отсутствии проверки VR:
    Sep 16 19:16:17 mail drweb-maild: [278545] maild INFO CheckMsg: set skip for plugin vaderetro. from=< root@mail.anrb.ru >; to=< gatling@mail.anrb.ru > Sep 16 19:16:17 mail drweb-maild: [278545] maild INFO CheckMsg: set skip for plugin drweb. from=< root@mail.anrb.ru >; to=< gatling@mail.anrb.ru >

    5.10. Еcли вы, как и я, используете одновременно и антивирус, и антиспам и при этом указываете заниженный порог отказа письма (например, у меня указан параметр UnconditionalSpamThreshold=400 в plugin_vaderetro.conf), то в файле mail_sendmail.conf в строке BeforeQueueFilters рациональнее указать первым vaderetro, а вторым drweb: так большая часть спама будет уничтожаться, то нет никакой необходимости эту почту сначала проверять антивирусом.

    5.11. Не помешает озаботиться резервным сохранением базы данных /var/drweb/lib/libvaderetro.so.cache.
    18 сентября в результате скачивания обновления базы VadeRetro работоспособность антиспама была нарушена.
    (07.07.2004 по той же причине аналогичное произошло с антивирусом Drweb: dwlib: fd: wait for recv failed - timeout expired.)
    Ничего страшного в этом не вижу, тем более, что, когда я обнаружила проблему, то сразу зашла на форум и узнала, в чем дело.
    Мне не пришлось изводиться в самостоятельных поисках проблемы и в бесконечном ожидании ответа от ТП, к чему я так и не смогла привыкнуть, когда пользовалась Спамообороной.
    Пока ожидала исправления обновления, сильно пожалела, что не сохраняла работоспособные базы за предыдущие дни. В данной ситуации это помогло бы сразу вернуть VadeRetro в нормальное состояние. О чем и сообщила форуму, и практически сразу же последовал ответ с решением от Ivan Kuznetsov. Выкладываю его здесь, надеюсь, автор не будет против :)

    #!/bin/bash
    # Резервное копирование libvaderetro.so
    # Путь к libvaderetro.so
    VADERETRO_PATH="/var/drweb/lib/libvaderetro.so.cache"

    # Количество поколений резервных копий
    COUNT=10

    rm -f "$VADERETRO_PATH.backup.$COUNT.gz"

    for (( i=$COUNT; i>1; i-- )); do
    if [ -f "$VADERETRO_PATH.backup.$(($i-1)).gz" ]; then
    mv -f "$VADERETRO_PATH.backup.$(($i-1)).gz" "$VADERETRO_PATH.backup.$i.gz"
    fi
    done

    cp "$VADERETRO_PATH" "$VADERETRO_PATH.backup.1"
    gzip "$VADERETRO_PATH.backup.1"

    P.S. Еще раз повторю: никаких негативных эмоций у меня эта ситуация не вызвала. Рабочий момент, который у всех когда-либо случается. Нужно просто обождать. Было даже очень приятно, что проблема отражена на форуме. А обеспокоенным повалившим спамом клиентам я отвечала в таком ключе:
    "Вот теперь вы представляете, какую адскую работу выполняет VadeRetro, оберегая ваш почтовый ящик от спама?"
    "А ведь, действительно, разница колоссальная", - отвечали клиенты и,прощаясь, говорили свое "спасибо", которое я с удовольствием переадресую команде DrWeb.


    6. Маниловщина.
    6.1 Discard - mx-ам, reject - всем остальным.

    Ответ техподдержки:
    "...
    4. Насколько я понял это можно будет сделать в следующей версии через правила. Например так:
    [rules]
    client-ip:mx-ip cont VadeRetro/Action = discard
    NOT client-ip:mx-ip cont VadeRetro/Action = reject
    ..."
    Что очень радует.

    7. Заключение.

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

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

    02.06.08.=== Уже не в раздумьях. Выбор сделан. Счет подписан. Ждем-с.
    На одной стороне весов лежали
    - нужные фишки, к-х пока нет в VR;
    - ожидаемое лучшее качество фильтрации Спамообороной (ожидание это было основано на том, что при каждом разборе письма СО обращается к yandex-базам, которые, как обещает документация, обновляются оперативно).
    На другой стороне
    - легкость в установке и обслуживании (поставил и забыл) VadeRetro;
    - факт, что "при лицензии на 50 и более почтовых адресов указание конкретных проверяемых адресов в настоящее время не требуется";
    - адекватность ТП DrWeb.
    Одним cловом, моя душа лежала именно к VR, даже если бы качество фильтрации оказалось несравнимым. Но нужно было думать и об интересах пользователей (вес письма в теме, индивид. пороги отказов, качество фильтрации), поэтому я склонялась было к СО, хотя еще прошлой осенью зареклась иметь с ней дело. Но, когда пришел счет, и оказалось, что VR на 20 т.р. дешевле, сомнений почти не осталось. Ну а последние сомнения рассеяли результаты сравнительного тестирования, благо, что я получила такую возможность.
    NB! Я ни в коем случае не расцениваю результаты тестирования как подтверждение того, что один антиспам лучше другого в плане фильтрации. Для меня эти данные означают, что один антиспам в плане фильтрации ничем не хуже другого, а другой - ничем не хуже первого. И я даже рада такому результату. ===

    11.11.2008. По истечении полугода могу сказать, что я довольна, и юзеры столько же.
    Во-первых, я совершенно напрасно беспокоилась по поводу отсутствия некоторых фишек у VR: юзеры спокойно проглотили отсутствие веса письма в теме.
    Во-вторых, из-за отсутствия персональных порогов отказа, я выставила сильно заниженный общий порог (400), и спама стало не то что мало, а вообще очень мало. Ложных срабатываний по этому показателю пока (т3р) не наблюдалось.
    В-третьих, количество пропущенных спам-писем стабильно и сильно от пропусков Спамообороны не отличается. Все зависит от спамерской активности. Иногда пусто, иногда 1-2 письма проскочит.
    В-четвертых, ваши письма о спаме, дорогие коллеги, продолжают помечаться спам-меткой. Как и в случае со Спамообороной. Ну, тут все понятно и не смертельно. Так что сильно не удивляйтесь, если в теме ответного письма увидите Re:[VR::SPAM]Sendmail.

    8. Обмен опытом.

    Мне было бы интересно узнать ваше впечатление от VadeRetro, в особенности:
    -качество фильтрации
    -как на вашей системе ведет себя VR в часы пиковой нагрузки.

    9. Сравнительная таблица.

    15.09.2008. Спасибо Das-ich за данные по Антиспаму Касперского!

    Сравнительная таблица
    Функция/Антиспам Спамооборона Vade Retro КАС
    Опыт работы с фильтром 2 года (2006-2008) 6 месяцев (с апреля 2008) СО - 3года, КАС - месяц
    Система Suse Suse RH
    Установка От недели (ранние версии) до 4 часов (*) 2 часа(*) 15 минут
    Базы данных Локальная копия доступна только для лицензии свыше 1000 пользователей.
    Для остальных - обращение за данными к yandex-базам при каждом разборе письма     		Локальная копия.
    Обновление ежедневное.    		 Локальная копия
    Качество фильтрации Хорошее Хорошее
    См. таблицу     		Хорошее, и гораздо лучше, чем у СО.
    Противоположное мнение.
    И еще одно (см. 3 стр.).
    Спам-метка темы Есть Есть Есть
    Вес в метке спам-письма Есть Нет+ Есть
    Отказ от приема письма(тихий/громкий) Есть Есть Есть
    Работа с группами Нет Нет Есть
    Индивидуальный порог отказа Есть Нет+ Есть (с.п. групп)
    Белый список для ip&nets Есть Нет+ Есть
    Белый список для emails Условный Условный, но возможность безусловного отказа есть Условный, (с.п. групп)
    Самоостановы Есть Есть+ Нет
    Контроль за самоостановом Нет Есть Есть
    Поведение при пиковой нагрузке Самоостанов или отказ "thread_create() failed:"(*)
    При ОП 2Gb за месяц проблем не наблюдалось    		 Отказ "thread_create() failed:" Отказ "thread_create() failed:"
    Пропуск письма в случае сбоя антиспама Есть Есть Есть
    Требовательность к ресурсам системы CO+DrWeb менее требовательны VR+DrWeb более требователены(*) Без тонкой настройки системы в целом - достаточно высокие (*)
    Ведение статистики Есть Есть Есть
    Дополнительные возможности: Есть Есть Нет
    1) фильтрация заголовка письма Нет Есть(*)
    2) фильтрация тела письма Есть Нет+(*)
    Тех.поддержка Без комментариев Отличная Пока не приходилось обращаться за помощью напрямую
    Форум ТП Нет http://new-forum.drweb.com/mod/forum/view/?id=5 http://forum.kaspersky.com
    Описание принципов фильтрации в документации Нет
    Для чего мне это было нужно...     		Нет Есть (см. п.2.2. Технологии распознавания)
    Грамотные специалисты по sendmail Есть(*) Есть См. п. ТП
    Бесплатная версия CO-1024 письма в сутки Нет Нет
    + означает "обещано добавить/исправить в след. версии".

    Комментарии к установке.
    Установка Спамообороны пройдет на "ура" у тех админов, которые используют дистрибутивы "как есть". То есть выбирают установку выбранного дистрибутива по умолчанию или вносят в перечень пакетов минимальные изменения.
    Ну, а таким, как я, приходится выбирать ручную установку Спамообороны. А точнее сказать, комбинированную. Потому что несколько конфигурационных файлов заполняются только скриптом. Поэтому приходится изворачиваться, что-то исполнять через install.sh, что-то добавлять вручную, потом еще править "подпорченный" установщиком /etc/rc.d. В общем, после опыта предыдущих установок переход на новую версию в декабре 2007г. занял всего около 4 часов (это прогресс!), а вот первый раз я ставила СО около недели.
    Старые версии СО требовали добавлений в конфиг named'a. Ну я добросовестно и исправляла named.conf. Добавляла-добавляла нужные записи, добавляла-добавляла, а толку-то и нет! Через пару дней меня стукнуло: у меня же named в chroot да на отдельном разделе. А что, если СО и не знает о таком варианте, и хочет обращаться только к /etc/named.conf? Так оно и вышло! Создала пустой /etc/named.conf, добавила строчки, нужные для СО, И ВСЕ ЗАРАБОТАЛО. Ну это был не единственный прикол с СО за неделю установки, но самый показательный в том плане, что СО не любит моей самодеятельности.
    Да, а каким таким "как я"?
    Если вы при установке дистрибутива терпеливо выбираете пакеты, которые действительно необходимы для работы предполагаемого сервера, а ключевые сервисы устанавливаете не из rpm, а самостоятельно собираете и заказываете при этом необходимый функционал, то, возможно, но необязательно, столкнетесь c некоторыми проблемами при установке СО.

    На этом фоне установка VadeRetro производит самое приятное впечталение. Сначала немного напрягло непонимание того, какой перечень пакетов мне необходим (см. начало статьи), потом немного подвела моя склонность к самостоятельным установкам: я внаглую скопировала файлы из rpm-ок, подкорректировла конфиги и попыталась было запустить все это хозяйство, но тут оказалось, что над правами и владельцами я не поработала. Поэтому вернула все на место и воспользовалась-таки install.sh (простой рабочий скрипт, без ненужных окошек и прочей мишуры). Ну и прежний опыт работы с антивирусом DrWeb'a тоже помог: что где должно лежать и как выглядеть, я уже знала, а файл drweb32.ini просто скопировала c рабочего сервера. Да, еще пришлось немного поработать с конфигами в плане выправления путей к сокетам и симметричности сокетов. В общем, если бы не моя самодеятельность на этапе установки из rpm-ок, возможно, за часок бы и управилась, включая чтение-разбор новых для меня конфигов к VadeRetro & drweb-sendmail.

    16.08.2008. === Только сегодня обнаружила на форуме DrWeb ссылку на документ "Антивирус + Антиспам Dr.Web® и Антиспам Dr.Web® для почтовых серверов Unix (Linux, FreeBSD и Solaris)"
    То, что я смогла установить и использовать VR без этого подробного описания, подтверждает простоту установки, настройки и эксплуатации.===


    Комментарии к требовательности VR к сист. ресурсам.
    20.08.08. После установки связки drwebd + drwebd-maild + vaderetro на основном почтовике всплыла старая проблема с созданием тредов даже при ОП 2,7Gb. Сначала по рекомендации тех. поддержки был увеличен swap-раздел до 5,5Gb. Проблема на время исчезла. При следующем появлении ТП посоветовала увеличить max user processes, что и было сделано (768). Пока (т3р) проблем не наблюдается. Следует отметить, что Спамооборона справлялась с нагрузкой даже при полностью отключенных антиспам-фичах sendmail'a (что создавало дикую нагрузку) и при размере swap 256Мб (почему такой размер - это отдельный раговор) и при max user processes=200.
    06.04.2010. Комментарий к проблеме от Сергея Афонина:
    "Есть confMAX_DAEMON_CHILDREN, далее добавляется столько же на каждый мильтер. Вот и число процессов. Осталось только проверить /etc/security/limits, только не забывая о том, каким юзерам повышать, в зависимости от того, под какими юзерами какие фильтры пускаются. Ну и запас на забытое."

    Комментарии к требовательности КАС к сист. ресурсам.
    15.09.2008. Взято отсюда:
    "... С sendmail поменялись параметры, отвечающие за прием почты при высоких значениях LA и увеличились значения таймаутов в определении фильтов. Каспер по-умолчанию ставит очень маленькие.
    Было
    Xkasfilter, S=local:/var/run/kas-milter.socket, T=C:10s;S:20s;R:30s
    стало
    Xkasfilter, S=local:/var/run/kas-milter.socket, F=, T=C:15m;S:5m;R:5m;E:10m
    Увеличены два параметра в конфиге каспера filter.conf
    ClientConnectTimeout 100
    ClientDataTimeout 100
    До этого были умолчальные 40.
    Все это вместе позволило избавиться от очередей и поиска сокета, но осталась ошибка с нехваткой потоков:
    Aug 26 10:02:48 spam-guard kas-milter[4967]: KAS-Filter: thread_create() failed: 12, try again
    Ее удалось устранить увеличением параметра ядра kernel.threads-max до 65536 в sysctl и заданием фильтру kas3-milter при загрузке меньшего размера стека ulimit -s 2048, потому что в rhel5 по-умолчанию задано 10 мегабайт, что быстро сжирало всю память..."

    Комментарии к пиковой нагрузке.
    1. Отказ "thread_create() failed - это узкое место sendmail, а точнее libmilter.
    Если отказ и случится, то ничто не помешает ни СО, ни VR нормально принять следующее письмо, если нагрузка спала.
    А вот если случился самоостанов СО, то никто, кроме вас, не поможет ему поднятся.
    Нужен скрипт, анализирующий наличие СО-процессов в ps и предпринимающий соответствующие действия.
    Напротив, самоостановы VadeRetro не имеют отношение к пиковым нагрузкам, поэтому рестарт VadeRetro не вызывает последующий немедленный самоостанов.

    Комментарии к фильтрации заголовков письма.
    Имеется отдельный плагин headersfilter. Для тех, кто впадает в ступор при виде sendmail.cf, он будет весьма полезен. Отличием от фильтрации заголовков средствами sendmail.cf является следующее: headersfilter работает через milter, а, стало быть, письмо сначала будет принято, а потом будет произведен анализ заголовков. Фильтрация средствами sendmail.cf позволяет отказаться от письма на этапе smtp-диалога.

    Комментарии к фильтрации тела письма. Ответ ТП: " ... Возможно с данной функциональностью будет отдельный плагин..."

    Комментарии к пункту "Грамотные специалисты по sendmail".
    Я бы, пожалуй, не стала включать этот пункт в данную таблицу, если бы не одно обстоятельство. Ко мне обращался за советом один админ: ТП одной антиспам-системы на запрос некой фичи дала такой ответ, что он решил обратиться ко мне за разъяснениями, что же она (ТП) имела в виду. Прочитав этот ответ и придя в тихий ужас, а также припомнив из своего опыта общения с этой же ТП неспособность справиться с проблемой "cannot alias non-local names" в 2000 году ( "у меня все ходы записаны!" ), я начала особо ценить наличие грамотных sendmail-специалистов в конторе, которая пишет фильтры к sendmail.

    Вообще-то, человек не может знать всего, и нет ничего страшного в том, что он пока чего-то не знает. Особенно, если это касается sendmail. Это я к проблеме "cannot alias non-local names". Плохо, когда толпы народа носятся по форумам месяцами и спрашивают, что делать, в то время как ТП тихо отмалчивается и продолжает лепить баг из версии в версию, хотя тогда ТП достаточно было сходить на родной форум sendmail'a, узнать причину и добавить-таки недостающий флаг "А" в определение мэйлера (define(`AVPKEEPER_MAILER_FLAGS',`sPhnu9A') или MODIFY_MAILER_FLAG(`AVPKEEPER',`+A')).

    Итак, могу сказать что СО повезло особо. Один раз в 2007г. мне ответил Сева Глущенко - специалист, которого все (ну или почти все) sendmail-админы знают по его антиспам-фильтру. Это был один из первых, если не самый первый российский sendmail-антиспам-фильтр, и он мгновенно разошелся по нашим конфигам.
    DrWeb тоже повезло, и тоже особо, потому что с ним работал Сергей Ахапкин. Именно он написал патч к sendmail, решающий проблему "drweb-smf: Dr.WEB Sendmail filter VER: thread_create() failed: 11, abort" Насколько я знаю, Сергей больше не работает в DrWeb, но, уверена, основу для фильтров он заложил крепкую.
    В общем, логику sendmail и его конфигов надо понимать очень хорошо, а иначе и не стоит писать к нему фильтры.

    О качестве фильтрации.
    10. Каскадное тестирование: VadeRetro->Спамооборона. Май-июнь 2008г.

    VR тестировался в два периода. Первый - с 16 апреля по 16 мая. Второй период начался 29 июня и будет продолжаться по 29 июня.
    29.05.2008. === Уррааа! Эксперимент продолжается! Сегодня я, во-первых, добавила на оба почтовика по 2GB памяти, значит, теперь можно будет убедиться в устойчивости фильтров, а во-вторых, получила демо-ключ на VadeRetro еще на месяц, значит теперь смогу обсчитать качество фильтрации в обоих направлениях.Уррааа! ===

    Выложена собранная статистика за 30 дней. Один главный момент - количество писем, не помеченных спам-меткой VR, но распознанных СО - учтен. Другой не менее важный момент (количество писем со спам-меткой VR, не помеченных СО), к моему великому сожалению, был посчитан только за последние два дня первой фазы эксперимента, но зато подсчитывается сейчас.
    Меня сбило с толку то, что, если письмо не спам, СО не пишет в лог строку об изменении темы письма, как и должно быть. А если нет этой строки, то я не могу проверить была ли в исходной теме спам-метка VR или нет.

    Ну вот это была совершенно непростительная ошибка, потому что кому, как не мне, знать о том, что средствами sendmail.cf можно вывести тему письма в лог. В конце концов я догадалась это сделать, но было уже поздно. Поэтому показатель VR-ONLY доступен только с 16 мая.
    Можно было бы брать за этот показатель разницу между помеченной VR почтой на одном почтовике и помеченной СО почтой на другом, но в моем случае опираться на это значение невозможно:
    1) для VR это общее значение: VR в демо-версии обслуживает всю почту (вх, исх, без ограничений по обслуживаемым доменам);
    2) время ежедневной ротации файлов на этих почтовиках немного отличается, поэтому одно и то же письмо на mx2 может попасть в один файл, а на основном почтовике - в другой, а скрипты обрабатывают логи целиком, а не за точный период с 0 часов до 24 часов;
    3)а самое гланое, как в этом случае представить "доказательную базу" - логи пропусков того и другого антиспама?

    Итак, на транзитном mx-е 212.193.134.3 установлен VadeRetro. На основном - Спамооборона.
    На транзитном почтовике обсчитывалось общее количество обработанных VR писем, далее через тире кол-во писем, помеченных спам-меткой, значение в скобках - discard'ы VR (первый столбец MX2). То есть разница между первым и третьим значениями - это и есть количество писем, отправленных далее, причем не только на основной почтовик.

    На основном почтовике стат. обработке подвергались только те процессы, к которым имели отношение sendmail-строки c relay=www.anrb.ru.
    ALL - общее количество этих записей, т.е. количество писем, поступивших с транзитного mx-а
    SKIP - число писем, вообще не проверенных СО (их получатели не принадлежат обслуживаемого СО-ой домену)
    NO - не спам-письма по версии СО, т.е. число писем, набравших вес меньше 7 баллов (начиная именно с этого значения СО помечает письма спам-меткой, рекомендованное разработчиками значение по умолчанию - 9)
    DISC - количество писем, набравших большой вес по версии СО (для всех - 40 баллов, для 30 человек - от 15 до 30, рекомендованное разработчиками значение по умолчанию - 50), и поэтому уничтоженных. Во время первого цикла эксперимента я не изменяла значение по умолчанию для discard'a VR (1000 балов), в то время как вес для discard'a СО был уже снижен. Думаю, поэтому данные этого столбца такие внушительные. Во время второй фазы эксперимента discard-порог VR был снижен до 500 балов, но вместе с тем убраны почти все ограничения (DNSBL,connlimit,ratelimit,greet_pause,iptables connlimit). Я ожидала значительного увеличения потока писем с транзитного mx-а, но, как видно, уменьшение discard-порога VR позволило сократить почтовый поток несмотря на отмену многочисленных предпроверок средствами sendmail & iptables. ==>Антиспам-фильтр на транзитном mx-е - это вещь! Но с 02.06 этот порог увеличен до 3500, потому что мне нужно создать трафик, необходимый для пороговой нагрузки СО. Поэтому количество CO-discarded-писем снова возросло, а VR-discard обнулился.
    YES - число писем, помеченных спам-меткой CO

    SO-ONLY - число писем, не получивших спам-метку VR, но помеченных спам-меткой CO (лог)
    (DISC) - число писем из SO-ONLY-писем, получивших к тому же SO-discard-вес. Рекомендуемое значение для discard'a - 50, мое значение по умолчанию - 40, для 30 человек discard-вес составляет от 15 до 30 баллов. Из-за этих 30 человек это значение не столь показательно, как VR-ONLY(DISC).
    Я могла бы посчитать количество hits>40 у SO-ONLY-писем, но из-за невозможности привязки напрямую записей СО и sendmail'a, сделать это простым способом невозможно. А скрипт, отлавливающий записи с транзитного mx-a по шаблону "For message from 212.193.134.3 will return" с последующим вычислением номера sendmail-процесса по адресу отправителя, оказался настолько "долгоиграющим" (оказалось, что строки СО & sendmail, имеющие отношение к одному и то му же письму, могут оказаться на расстоянии более 4500 строк(да-да-да, я не опечаталась!)) , что от него пришлось отказаться.
    20.06.08. === 10-20-30-40 - кол-во SO-ONLY-писем, набравших от 7 до 10, от 10 до 20, от 20 до 30, от 30 до 40 баллов.===

    VR-ONLY - число писем, не получивших спам-метку SO, но помеченных спам-меткой VR (из-за моего тугодумия эти данные доступны только с 16 мая)(лог)
    VR-ONLY не может быть больше показателя NO.
    (DISC) - число писем из VR-ONLY-писем, получивших к тому же VR-discard-вес (на транзитном mx-е пока discard пока отключен, для того чтобы перенаправлять всю поступившую почту на основной почтовик). Рекомендуемое значение для discard'a - 1000, мое значение по умолчанию - 500, индивидуальные пороги для VR пока невозможны.
    20.06.08. === 200-500-999>1000 - кол-во VR-ONLY-писем, набравших от 0 до 200, от 200 до 500, от 500 до 900, от 1000 баллов.===

    Логи пропусков спама по всем дням могут быть предоставлены.
    * Помечены дни, когда были отменены все ограничения (iptables, /etc/msil/access, sendmail.mc) на почтовый трафик.

    01.07.2008. Эксперимент закончен. Результат, как говорится, налицо. То, что CO "сдала" в последние дни эксперимента, связываю с летне-отпускным временем, возможно, базы шинглов СО стали обновляться не столь регулярно. Кстати, именно в эти последние деньки действия лиц. ключа СО стало гораздо больше пропусков спама, а в логе появлялись многочисленные ошибки "ERR_F Could not find rule имя_правила_фильтрации".

    MX2ALLSKIPNO DISC YES SO-ONLY 10-20-30-40 VR-ONLY 200-500-999 DATE
    (DISC)(DISC)>1000
    ---------------------------------
    2919152921297460(0)16(10)0-6-5-5Jun30
    04:02-14:00
    2708-2686(0)2694181221065581(0)0-0-0-110(9)0-1-8-1Jun29
    2920-2883(0)291518231780109418(3)0-9-5-121(19)1-1-12-7Jun28
    3989-3875(0)3985651242057173949(2)2-37-5-3123(109)0-14-44-65Jun27
    6139-6089(0)61224342383422034(0)0-3-1-039(36)0-3-19-17Jun26
    6627-6597(0)661924102368128120(0) 97(87)0-10-37-50Jun25
    6970-6916(0)69604346479020814(0)2-2-0-042(39)0-3-15-24Jun24
    13393-13312(5)133748477652966820(0)77(69)0-8-30-39Jun23*
    5792-5743(0)57865325283328750(0)24(19)0-5-6-13Jun22*
    3149-3094(0)3149602982322372(0)2-0-0-027(17)0-10-8-9Jun21*
    8665-8313(5)8659767654273079269(145)2-18-45-5962(53)1-8-19-34Jun20*
    12459-11913(5)12432677792093075440(118)28-85-101-10839(34)0-5-3-31Jun19*
    7017-6894(0)701425734407250988(14)7-40-17-1063(51)7-5-15-36Jun18
    15217-14975(3)1517896122110793877150(72)3-22-24-29113(93)0-20-38-55Jun17*
    10683-10024(0)10681526456631335245(27)5-6-2-971(62)2-7-23-39Jun16*
    3281-3238(0)327812302099113727(3)2-9-6-729(26)0-3-12-14Jun15
    1503-1484(0)150418407047420(0)39(37)0-2-21-16Jun14
    1745-1686(0)1740178169195136(5)1-18-8-474(64)0-10-22-42Jun13
    2475-2409(0)247824561329106937(10)3-10-8-651(28)0-23-18-10Jun12
    4891-4850(0)48903489305717109(3)1-0-2-386(65)0-21-35-30Jun11
    6389-6342(0)63854681400822508(3)0-1-1-378(60)0-18-28-32Jun10
    7653-7470(0)76153515644992925124(7)17-54-28-18123(72)1-50-21-51Jun9
    2336-2185(0)234414781331921128(17)8-51-36-1668(5)2-61-1-4Jun8
    3470-3296(0)34591911817541568151(14)4-78-36-19113(59)1-53-33-25Jun7
    6250-5764(6)62392216237572295380(25)65-166-91-3374(39)0-35-28-10Jun6
    11201-10972(3)108473516269643676140(28)26-44-17-25111(82)0-29-33-49Jun5*
    14773-14741(3)14742581011073238505(0)3-1-0-197(59)0-38-14-45Jun4*
    -----------------------------
    MX2ALLSKIPNODISCYESSO-ONLYVR-ONLYDATE
    14657-14624(0)1466835128106263879 718Jun3*
    14799-14726(5989)4893155733851436 357Jun2* 17:51-Jun3 04:02
    -98914854242514Jun2 04:02-15:45
    7186-7150(6510)6771613261387 1610Jun1
    3519-3502(3134)385131486270 214May31
    8273-8232(7475)787205340422 182May30
    2577-2555(2127)40933224179 93May29 19:58-May30 04:02
    1012-1002(527)4871211294170 011May17
    3926-3891(2439)14822220905531 311May16
    ---
    MX2ALLSKIPNODISCYESSO-ONLYDATE
    10926-10894(8100)2803223320277172May15
    15292-15254(12596)2689221420505997May14
    11776-11468(9368)2282141041465687113May13
    6549-6332(5133)1375261780552668May12
    ---
    MX2ALLSKIPNODISCYESSO-ONLYDATE
    2773-2593(1577)1191121973942134May11
    1389-1268(404)98111160136873May10
    1471-1374(355)1113123562644049May9
    3729-3695(2371)1357162498633111May8
    4154-4061(2845)1308232562763349May7
    4494-4451(3330)1162121563150227May6
    6382-6341(4883)149624408655632May5
    ---
    MX2ALLSKIPNODISCYESSO-ONLYDATE
    2935-2911(2148)78411113624009May4
    3304-3288(2510)7881144852870May3
    4188-4174(3188)10041037282611May2
    3983-3968(2797)11841218842872May1
    4005-3983(3098)90312213615073Apr30
    5231-5193(4220)99620363545852Apr29
    5696-5583(4117)1567143376974847Apr28
    ---
    MX2ALLSKIPNODISCYESSO-ONLYDATE
    3944-3921(2833)111011107443459Apr27
    4298-4281(3375)92110133625361Apr26
    4059-4019(3156)89815292276171Apr25
    7773-7736(6401)1507232797947735Apr24


    11. Каскадное тестирование: Спамооборона->VadeRetro. Апрель - май 2009г.

    Вопрос, который я и сама себе в который раз задаю: зачем мне это тестирование нужно. Ведь, если будут деньги, мы купим опять VR, если не будут - начну осваивать SpamAssassin.
    Ответ: если вы читали мою страницу про Спамооборону, то наверное уже поняли, что в моей системе координат равнодушие ТП к проблемам пользователей - страшное, ужасное, выбивающее из нормальной колеи зло. Однако мне довелось пообщаться с одним человеком от СО, который не вписывается в общую картину. И поскольку он высказал такое пожелание, мне хочется его исполнить и повторить тестирование. Тем более, что скрипт уже написан, установка для меня знакома, надеюсь, это не займет много времени. А результат мне и самой очень интересен. Мой прогноз: на этот раз VR проиграет.
    Это тестирование проводится еще и для очень хорошего человека и большого мастера своего дела - Амира Даутовича Максутова (директор Интернет-центра БашГУ). В сфере IT он настоящий стахановец в первоначальном смысле это тюркского слова ((о/у)ста хан - человек, у которого любое дело спорится, Мастер-золотые руки, умелец и увлеченный своим делом человек). Поскольку он сейчас стоит перед выбором антиспама, то мой опыт ему пригодится.

    Конечно жаль, что у меня не хватило времени в апреле, тогда почтовая нагрузка была побольше. А к лету традиционно активность снижается.
    22.04.09. Начала установку CO. Застряла. Разбираюсь.
    28.04.09. В результате кровопролитных боев Спамооборона все-таки отступила и была запущена в дело. Количество убитых и раненых уточняется.
    29.04.2009. Все-таки скрипт пришлось кардинально перписывать. В первый раз была схема MX2->VR->MX1->SO. А теперь наоборот: MX2->SO->MX1->VR. И из-за того, что невозможно без "плясок с бубном" по номеру sendmail-процесса выцепить всю историю данного письма, приходится писать немаленькие такие скрипты для обработки лога.

    30.04.2009. Тестирование будет проходить с 28 апреля по 25 мая.
    ALL - кол-во писем, пришедших с MX2+CO.
    Из них:
    SKIP - письма, не подвергавшиеся проверке Спамообороной. Остальная почта была проверена.
    N0 - это не спам.
    DLVR - письма, которые СО посчитала легальной рассылкой.
    YES - это спам.
    DISC - в том числе спам, набравший больше 40 баллов.
    SO-ONLY(Disc) - кол-во писем, помеченных СО, но не помеченных VR ( кол-во писем, набравшее больше 40 баллов ). Количество ложных срабатываний, наверное, уже не будет определено вовсе, ибо терпение мое на этом закончилось.
    VRNO - столько писем из числа ALL VadeRetro не посчитало спамом .
    VR-ONLY(DLVR,Disc,FP) - кол-во писем, помеченных VR, но не помеченных CO (из них кол-во писем, имеющее для СО статус DLVR; кол-во писем, набравшее больше 500 баллов по версии VR). Количество ложных срабатываний (FP) было определено вручную только несколько раз, на большее меня не хватило.
    VR,SO spam-fails - спам-письма, не помеченные ни одним из фильтров. Определить эти значения вручную у меня терпения не хватило, хотя данные (логи) пока сохраняются.

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

    14.05.2009. Для того, чтобы собрать почту, помеченную СО и непомеченную VR, вчера настроила с.п. procmail перекладывание писем со спам-меткой Спамообороны в отдельный файл (по предыдущему опыту ложных срабатываний было оч. мало). Сегодня весь день разгребала ложные срабатывания (около 100 штук). Под раздачу попали многочисленные рассылки для Института Химии, Института Биологии, Института Генетики, Института Нефтехимии и Катализа (вывод: химиков и биологов СО не любит, рассылки для остальных институтов не пострадали, к слову VR этим же рассылкам дал от -500 до -1000 баллов), а также не поздоровилось рассылкам от drweb.com, kaspersky.com и от банка ВТБ24. Прокляла все на свете и в первую очередь себя: зачем мне это было нужно ???
    21.05.09. А это то, о чем я говорила. После возвращения в конфиг следующих features
    FEATURE(`ratecontrol')dnl
    FEATURE(`conncontrol')dnl
    FEATURE(`greet_pause',`3000')
    FEATURE(`dnsbl',`bl.spamcop.net', `Spam blocked see: http://spamcop.net/bl.shtml?$&{client_addr}')
    FEATURE(`dnsbl', `cbl.abuseat.org', `"550 Mail from " $&{client_addr} " rejected - see cbl.abuseat.org/lookup.cgi?ip="$&{client_addr}')
    FEATURE(`dnsbl', `zen.spamhaus.org', `"550 Mail from " $&{client_addr} " rejected - see zen.spamhaus.org"')
    ситуация изменилась.

    ALL SKIP NO DLVR YES DISC SO-ONLY(Disc,FP) VRNO VR-ONLY(DLVR,Disc,FP) VR,SO fails DATE
    21440352666862220(6)818(0,2)-Apr28
    1066131484610443868284(30)26613(0,5)-Apr29
    294201961242619215271(20)37913(2,3)-Apr30
    3234078353120244041(4)1494(0,1)-May1
    6410401758431927(4)813(2,2)-May2
    6730382660836541(11)996(1,1)-May3
    76730116647492636275(35)24312(1,5)-May4
    37090229703410273092(22)37216(0,6)-May5
    409702058038073068177(64)43724(6,8)-May6
    660402219662604541127(50)43014(2,13)-May7
    429701795640533073105(40)3338(2,2)-May8
    125903624119893342(21)1011(0,1)-May9
    1252025241202100140(18)854(0,1)-May10
    4766078464641375150(15)16311(0,6)-May11
    8590027010682086434318(158)67919(2,5)-May12
    8836035714583296488618(387,50)107744(3,8)-May13
    10355336716597027434618(350,50)112033(4,?)-May14
    7475043813567675043382(181)94114(4,?)-May15,16
    847101075381176249110(47)2627(0,?)-May17
    1495114141601415310394613(371)115340(13,?)-May18
    106390443148100017839532(314,30)108337(6,10)-May19
    119910357105114818103419(216)83946(9,20)-May20 before 22:00
    dnsbl+ratecontrol+conncontrolstartedup-May20 22:00
    11230406177532204115(12,15)67429(3,10)-May21
    10260378128515248108(15)59324(8,4)-May22
    44701044929215353(18)19215(6,4)-May23
    362014867145231(0)20146(0,39)-May24
    420024423152413(0)21862(2,32)-May25


    Почему VRNO != SKIP+NO+DLVR+SO_ONLY буду разбираться после праздников.

    15. Новости.

    12.03.2009. Уррра! Белый список IP-адресов, индивидуальные спам-пороги и избирательный discard/reject (в зависимости от IP отправителя), пропуск без проверки писем от smtp-авторизованных пользователй будут в новой пятой версии VadeRetro! И еще многое что другое! Уррра!

    16. И все-таки, почему я выбираю VadeRetro?.

    16.1. Человеческий фактор.

    Когда юзеру приходит много-много спам-писем, ему становится безразлично, помечена она или нет, отложена помеченная почта в спам-ящик или нет. Завидев меня на горизонте, он жалобно ноет: "Чтооо случииилось со спам-фииильтром? СТОЛЬКО СПАААМА!" Я начинаю выяснять, помечена ли спам-почта или нет. Большинство на этот вопрос ответить не могут. Ладно, иду к компу, обнаруживаю спам-паку, забитую помеченными письмами. Спрашиваю, чем недовольны? Спам-фильтр сделал свое дело: обнаружил спам и пометил его. TheBat! сделал свое дело: обнаружил спам-метку в теме и переложил письмо в отдельную папку. Выясняется, что за день человеку приходит, скажем, 5 приличных писем и 50 спам-писем. Поскольку ложные срабатывания никто не отменял, то юзер вынужден просматривать и спам-папку. И какая, говорит он, мне разница, помечена почта или нет, если мне все равно приходится просматривать всю поступившую почту ???
    Когда мимо пробегавший супер-мупер-админ (ALTовод, ALTовед, ALT-гуру всех времен и народов), один из первых линуксоидов в Уфе, бросил мне на ходу: "Похоже антиспам перестал ловить мышей - спама много стало", а на мой встречный вопрос:"Спам помеченный или нет?" ответить не смог, мне стало окончательно ясно, что, если спам-писем много, то сам факт мечения спам-писем юзерам безразличен! И качество работы антиспам-фильтра даже для прожженного IT-шника (когда он выступает в роли юзера, а не сисадма) не в том, чтобы не было спам-писем, не помеченных меткой, а в том, чтобы спама было мало вообще! И тогда не важно, помечен он или нет. То есть для них важно, чтобы приличная почта поступала без проблем, вся остальная же была сведена к минимуму.
    Итак, у админа и юзера различный подход к оценке эффективности фильтра.
    Админ: вся спам-почта должна быть помечена.
    Юзер: спама должно быть мало.
    Единственное, в чем мы с ними сходимся - это в нежелании ложных срабатываний.
    Если спама будет много, то юзеру совершенно безразлично, что я поставила - VadeRetro или Спамооборону. И как качественно метит спам-письма выбранный мной фильтр. Спама много - фильтр плохой, а я так вообще ...
    Ну а поскольку все-таки мы работаем для юзеров, приходится идти навстречу их пожеланиям. А значит не обойтись без дополнительных фильтров.

    Вы спрОсите, а почему я не использую reject/discard спам-почте при пониженном спам-пороге? Ведь тогда до получателя дойдет гораздо меньше спам-писем?
    Ответ: боюсь ложных срабатываний, поэтому не использую discard;
    боюсь "лишнего шума", поэтому не использую reject.
    А выборочный rejeсt/discard пока ни тот, ни другой фильтр не позволяют, хотя в 5-ой версии VR это будет.

    16.2. Неизбежность дополнительных фильтров.

    Я много общаюсь по поводу антиспама. И всегда просматриваю соответствующие темы на форумах.
    Я еще не видела ни одного человека, который бы похвастался сведением количества спама к самому минимальному минимуму с помощью не важно KAC (см.2-3 стр.) ли, СО ли, VR ли, SpamAssassin ли без привлечения дополнительных фильтров.
    То есть, если человек заявляет, что к нему в почтовый ящик в день попадает не более 1-2 помеченных спам-писем, это говорит о том, что перед фильтром у него или собственный фильтр, или dnsbl, или greylist, или SPF или что-то еще.
    На период каскадного тестирования я убрала dnsbl-checks из конфига sendmail'a, потому что мне нужно было увеличить почтовый трафик. Кстати, никто из юзеров не пострадал. Они этого даже не заметили (об этом позже).
    Если я верну dnsbl-checks на место, то кол-во пропусков спама VR резко уменьшится (может, я это и продемонстрирую в последнюю неделю тестирования). А значит, разница в качестве фильтрации VR & SO будет не столь значительной. Помимо этого такой подход (дополнит. фильтр + спам-фильтр) позволяет экономить ресурсы системы, ведь часть спама не будет доходить до антиспама.

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

    16.3. Раздвоение академической почты на 2 почтовых домена: anrb.ru & ufaras.ru.

    Поскольку УНЦ РАН пожелал иметь собственный домен, отражающий его принадлежность к РАН, хотя в названии домена anrb.ru, imho, не было ничего зазорного (Academic Network of RB), то в ближайшие лет 5 использование СО становится просто нереальным. Ведь мы не будем покупать лицензию на 800 адресов, вместо привычных 400. А домены anrb.ru & ufaras.ru будут работать симметрично сколь угодно долго. Именно поэтому это раздвоение, а не разделение.
    Корни этой проблемы СО здесь. И хотя решение на sendmail-конфе найдено, я не буду его применять сейчас, потому что все-таки двойная отправка одного и того же сообщения в рамках одного почтовика - это конкретный изврат, которого нельзя избежать, если выхода нет, и который нужно обязательно избежать, если выход есть. А он у меня есть - VR.

    16.4. Цена.

    Ну тут все ясно. VR дешевле.

    16.5. У VR значительно меньше ложных срабатываний.

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

    16.6. Личное.

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

    16.6.


    II. Сезон 2010.

    15.03.2010. Дано: P4/XEON, 2CPU 3GHz, 2Gb ОЗУ, 2Gb swap; Sisyphys ServerSpecialEdition; sendmail 8.14.4, пакет drweb-mail-servers-av-as_5.0.1.3-1002031750_linux, из коего я использую:
    drwebd (drweb-демон, общий и для антивируса, и для антиспама) +
    maild-sendmail (модуль, соединяющий демон, sendmail и фильтры) +
    plugin-drweb (антивирус-фильтр) +
    plugin-vaderetro (антиспам-фильтр)

    1. 5-ая версия DrWeb. Нововведения.
    1.1 Комплексное логирование.

    В новой версии есть возможность писать логи как в syslog
    drweb32.ini: [Daemon]
    drweb32.ini: LogFileName = syslog
    drweb32.ini: SyslogFacility = Daemon

    drweb32.ini: [Scaner]
    drweb32.ini: LogFileName = syslog
    drweb32.ini: SyslogFacility = User

    drweb32.ini: [Updater]
    drweb32.ini: LogFileName = syslog
    drweb32.ini: SyslogFacility = Daemon

    monitor.conf: FileName = syslog
    monitor.conf: SyslogFacility = Daemon

    agent.conf: FileName = syslog
    agent.conf: SyslogFacility = Daemon

    , так и напрямую в файлы.
    drweb32.ini: LogFileName = /var/log/drweb_daemon.log
    drweb32.ini: LogFileName = /var/log/drweb_scanner.log
    drweb32.ini: LogFileName = /var/log/drweb_updater.log
    monitor.conf: FileName = /var/log/drweb_monitor.log
    agent.conf: FileName = /var/log/drweb_agent.log

    При выводе логов напрямую в файл возникли трудности c agent'ом и updater'ом, поэтому до их разрешения был найден такой выход:
    drweb32.ini:SyslogFacility = Local5
    agent.conf:SyslogFacility = Local4

    syslog.conf:
    local4.*                                             -/var/log/drwebag.log
    local5.*                                             -/var/log/drwebupd.log

    *.info;mail,local4,local5,auth,authpriv,daemon,cron.none                                    -/var/log/allinfo
    *.*;local4,local5,news,mail,auth,authpriv,cron.none;daemon.!=info;daemon.!=alert;daemon.!=err         -/var/log/messages

    1.2 Номер sendmail-процесса теперь указывается в записях drweb в maillog'е.

    У меня больше не болит голова при составлении отчетов пользователям, так как больше нет нужды писать пространные скрипты для "вылавливания" drweb-записей, относящихся к данному sendmail-процессу.
    egrep $sendmail_pid /var/log/maillog при define(`confMILTER_LOG_LEVEL',`8') даст полную информацию по данному процессу:
    Mar 15 19:46:40 mail sendmail[8472]: o2FEkZHW008472: from=<apache@ns3.srjmarketing.com>, size=775, class=0, nrcpts=1, msgid=<20100315144046.1131A1625613@ns3.srjmarketing.com>, proto=ESMTP, daemon=MTA, relay=ns3.srjmarketing.com [64.25.11.38]
    Mar 15 19:46:40 mail drweb-milter.real: [3007679344] milter INFO 00011461/o2FEkZHW008472 success save mail to /var/drweb/msgs/in/1/00011461/
    Mar 15 19:46:40 mail drweb-maild.real: [1946102640] maild INFO 00011461/o2FEkZHW008472 Attach msg to plugin vaderetro...
    Mar 15 19:46:40 mail drweb-maild.real: [1946102640] vaderetro INFO 00011461/o2FEkZHW008472 SpamState = 1; SpamScore = 420; Version=Vade Retro 01.290.66 AV+AS Profile: <none>; Bailout: N/A; apply: [discard];
    Mar 15 19:46:40 mail drweb-maild.real: [1946102640] maild INFO 00011461/o2FEkZHW008472 plugin vaderetro block msg; time=19 ms
    Mar 15 19:46:40 mail drweb-milter.real: [3007679344] milter INFO 00011461/o2FEkZHW008472 drweb-maild return discard action
    Mar 15 19:46:40 mail drweb-milter.real: [3007679344] milter INFO 00011461/o2FEkZHW008472 processing message [from: <apache@ns3.srjmarketing.com>; to:<terrapin@anrb.ru>] is over
    Mar 15 19:46:40 mail sendmail[8472]: o2FEkZHW008472: Milter: data, discard
    Mar 15 19:46:40 mail sendmail[8472]: o2FEkZHW008472: discarded

    1.3 Получатель письма при discard'e указывается в записях drweb.

    Раньше в логе получатель при discard'e письма отсутствовал:
    Feb 20 04:10:58 mail sendmail[21778]: o1JNAsXQ021778: from=<paul_simpon@rediffmail.com>, size=3038, class=0, nrcpts=1, msgid=<20100219192540.97C2D3EA800@mail.sasatechnologies.com>, proto=ESMTP, daemon=MTA, relay=sasatechnologies.com [207.158.2.250]
    Feb 20 04:10:58 mail drweb-milter: [117833744] milter INFO [o1JNAsXQ021778]: success save mail to /var/drweb/msgs/in/0/003619E0/
    Feb 20 04:10:58 mail drweb-maild: [213005] maild INFO start processing msg 003619E0 ...
    Feb 20 04:10:58 mail drweb-maild: [213005] maild INFO Attach msg 003619E0 to plugin vaderetro...
    Feb 20 04:10:58 mail drweb-maild: [213005] vaderetro INFO SpamState = 1; SpamScore = 400; Version=Vade Retro 01.290.37 AV+AS Profile: <none>; Bailout: N/A; apply: [discard]; time=47 ms
    Feb 20 04:10:58 mail drweb-maild: [213005] maild INFO plugin vaderetro block msg 003619E0
    Feb 20 04:10:58 mail drweb-milter: [117833744] milter INFO drweb-maild return discard action for msg 003619E0
    Feb 20 04:10:58 mail drweb-milter: [117833744] milter INFO [o1JNAsXQ021778]: processing message from <paul_simpon@rediffmail.com> is over
    Feb 20 04:10:58 mail sendmail[21778]: o1JNAsXQ021778: Milter: data, discard
    Feb 20 04:10:58 mail sendmail[21778]: o1JNAsXQ021778: discarded

    И это вынуждало записывать получателя в лог самостоятельно с помощью правила
    # For terrapin's user reports:
    Rterrapin<@$=w.>                   $: $(syslog syslog:report: terrapin@$1 $) terrapin<@$1.>
    что засоряло лог и увеличивало его объем.
    Как видно из предыд. примера, теперь такой проблемы нет.

    2. Дневник проблем.

    2.1 Логирование в /var/log.
    15.10.2010.
    Не сразу удалось логировать логи агента и апдейтера в директорию /var/log. И если updater просто не пишет лог, то agent вообще не запускается, что влечет за собой невозможность работы drweb-milter:
    mail sendmail[13621]: o2BEbf1e013621: Milter (drweb-filter): local socket name /var/drweb/ipc/drweb-milter.sock unsafe
    Хроника боевых действий здесь. Объяснение от DrWeb :
    updater и агент не могли вести лог в /var/log так как при попытке создания файла с логомони работали не от пользователя root (в данном случае от drweb). То же самое касается и остальных компонент запускаемых из под монитора (если для них в mmc не прописано работать от root).

    III. Сезон 2011-2016.

    20.09.2011. Дано: P4/XEON, 2CPU 3GHz, 2Gb ОЗУ, 2Gb swap; Sisyphys ServerSpecialEdition; sendmail 8.14.4, пакет drweb-mail-servers-av-as_6.0.1.2-1106031150_linux, из коего я использую:
    drwebd (drweb-демон, общий и для антивируса, и для антиспама) +
    maild-sendmail (модуль, соединяющий демон, sendmail и фильтры) +
    plugin-drweb (антивирус-фильтр) +
    plugin-vaderetro (антиспам-фильтр)

    Я недовольна VadeRеtro.
    24.02.2012. В мире нет ничего постоянного?
    В этом сезоне я недовольна VadeRеtro. Бывают дни, когда я очень недовольна VadeRetro.
    Приступила к многоуровневой обработке статистики. Возможно, когда я увижу, какой большой объем спама отсеивается, пропуски спама перестанут меня так сильно раздражать. НО пока ... Пока я недовольна VadeRеtro. В планах поставить вторым фильтром Спамооборону-1024 и оценить работу СО со спамом, пропущенным VR.

    Документация.
    20.09.2011. Dr.Web для почтовых серверов UNIX. Руководство администратора. Настройка и запуск. Конфигурационный файл.Секция Rules. Графическое представление синтаксиса.
    Отчаявшись разобраться в премудростях конфига , составила такую таблицу. Стало немного легче.

    20.09.2012. drweb32.key нужно скопировать из agent.key.




    IV. Обсуждения антиспам-систем.

  • Независимое тестирование различных АнтиСпам решений (коммерческие и свободные продукты)
  • [1]
  • [2]
  • [3]


  • V. Важное, очень полезное.

  • 1 ноября 2012 года. Обновление продуктов Dr.Web для аварийного восстановления системы
  • Диск аварийного восстановления системы


  • VI. ...



  • Обратная связь
    Страница создана 18 апреля 2008г. Выложена 12 мая 2008г. Последнее обновление: 8 ноября 2012г.
    sciurus@mail.ru (тема Sendmail обязательна, иначе я не получу быстрого извещения о письме)
    Или постмастеру этого домена.