Spamd для Exchange

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

Ранее, когда фильтр работал в последовательном (serial-mode) режиме, нередки были всякие неприятные эффекты в виде захлёбывания фильтра сотнями спам-сообщений. Неудивительно, ведь для анализа каждого входящего сообщения запускалась очередная копия интерпретатора Perl. И когда какой-нибудь Центр Американского Английского начинал свои спам-атаки, очередь сообщений быстро переполнялась, после чего никто не мог получить не только внешнюю корреспонденцию, но даже и внутренняя почта ходила с дикими задержками. Приходилось останавливать SMTP-службу, отключать фильтр спама, ждать пока пробка рассосётся, после чего включать всё обратно.

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

[7140] info: prefork: child states: BB
C:/cygwin/bin/perl.exe (8320): *** WFSO timed out after longjmp
[7140] error: panic: MUTEX_LOCK (45) [op.c:354] at /usr/bin/spamd. line 828.
panic: MUTEX_LOCK (45) [pad.c:1356] at /usr/lib/perl5/site_perl/5.8/Mail/SpamAssassin/Logger/Syslog.pm line 125.

Я это пока обхожу путём периодического перезапуска spamd. Решение не сильно красивое, но лучшего я пока не придумал.

Кстати, уже собранный WinSpamC, криво работает в связке с ExchangeSpamAssassin. Лучше для этих целей использовать spamc, собранный в cygwin и обёрнутый в батничек типа:

@echo off
spamc %1 %2 %3 %4 %5 %6 %7 %8 %9


Да, и на SourceForge есть ещё интересный проект: http://sourceforge.net/projects/exchangespamc/ Я его пока не пробовал, но, похоже, это несколько лучшее решение, чем ExchangeSpamAssassin, поскольку не требует промежуточного запуска spamc.

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

К сожалению (а может, к счастью?) у руководства обычно нет особого интереса к этой статистике, так что спамеры могут продолжать делать своё чёрное дело.