Debian Jessie, Postfix + amavisd-new + spamassassin: не уверен, работает ли Байес
Уважаемые вежливые люди на этом форуме,
Я недавно перешел на новый почтовый сервер . Поскольку «возрастной разрыв» оборудования был слишком велик, было бы трудно одновременно просто обновить Debian Squeeze до Jessie (и, возможно, это не решило бы мою проблему). Я просто установил чистую Jessie и вручную переместил учетные записи пользователей, старую электронную почту и т. Д. По крайней мере, я знаю больше о внутреннем устройстве.
Единственное, с чем я, кажется, борюсь, - это байесовская база данных, управляемая Spamassassin - , порабощенная amavisd-new . (Хех уже знал, когда я хотел, чтобы заголовки оценок спама включались в каждое электронное сообщение : $ sa_tag_level_deflt находится в конфигурационном файле amavis .)
I есть
use_bayes 1
bayes_path /var/lib/spamassassin/.spamassassin/bayes
в spamassassin / local.cf. Мне кажется любопытным, что путь заканчивается словом «bayes», но эта последняя строка не является фактическим каталогом, это, кажется, просто префикс для файлов _toks и _seen.
Если я попробую «spamassassin -D --lint» 2> & 1 | less "Я вижу некоторую похвалу:
Jul 9 11:21:15.091 [5076] dbg: bayes: tie-ing to DB file R/O /var/lib/spamassassin/.spamassassin/bayes_toks
Jul 9 11:21:15.091 [5076] dbg: bayes: tie-ing to DB file R/O /var/lib/spamassassin/.spamassassin/bayes_seen
Возможно, в зависимости от каталога, в котором я его запустил, я однажды видел и BAYES_20 в этом списке.
Также sa-learn-cyrus, похоже, обновляет базу данных отлично, и sa-sync тоже не жалуется.
Я действительно перенес файлы байесовской базы данных со старого сервера, используя
sa-learn --backup
sa-learn --restore=...
, и мне пришлось настроить некоторые разрешения после обслуживания памяти ... sa-learn-cyrus.conf содержит пользователя и группу, под которой он должен запускаться, что должно соответствовать владельцу базы данных.
Теперь для любопытный момент:
Я не вижу никаких следов байесовского фильтра, реально работающего с проходящей электронной почтой. Amavis действительно работает, я могу видеть его действия в /var/log/amavis.log, иногда он ловит СПАМ на основе своих других эвристических правил. Но мне не удалось получить оценку BAYES ни в полученных электронных письмах (которые теперь содержат ожидаемый заголовок X-Spam-Status), ни в очень положительных материалах, помещенных в карантин в /var/virusmails.
Другими словами , если я запустил "grep -ri bayes *" в / var / log / и / var / virusmails /, я ничего не получу: s часть spamassassin ...
Любые идеи приветствуются: -)
Франк
вроде как нашел ответ: В /etc/spamassassin/local.cf вам нужно:
use_bayes 1
bayes_auto_learn 1
use_bayes_rules 1
Это была третья строка, которая отсутствовала в моем случае.
Кстати, при поиске проблемы мне удалось вставить "зонд регистрации" в модуле Spamassassin Perl, который напечатал для меня трассировку стека вызовов Perl:
В /usr/share/perl5/Mail/SpamAssassin/BayesStore/DBM.pm:
sub tie_db_readonly {
...
my $iii = 1;
print dbg("Stack Trace:");
while ( (my @call_details = (caller($iii++))) ){
dbg( $call_details[1].":".$call_details[2]." in function" . \
$call_details[3] );
}
Взято почти дословно из публикации Тариамы здесь .
Очевидно, мне понадобился какой-то переключатель отладки, чтобы отображать отладочные сообщения:
В /etc/amavis/conf.d/50-user:
$DO_SYSLOG = 0;
$LOGFILE = "/var/log/amavis.log";
$sa_tag_level_deflt = -9999; # always add spam info headers
$log_level = 2;
$sa_debug = 1;
На самом деле это только две последние строки ключ для отладки в Amavis и SpamAssassin. Строки выше - просто FYI.
==== ИЗМЕНИТЬ еще час спустя: ====
... но подождите, есть еще кое-что, похоже, это еще не конец игры: -)
Сразу после того, как я отправил предыдущее оптимистическое сообщение, Я принял холодный душ: снова пропали оценки BAYES. Итак, я вернулся к серьезному уровню отладки, попытался удалить некоторую конфигурацию, связанную с автоматическим истечением срока действия что я играл в то же время, но даже когда я вернул конфигурацию туда, где она работала, Байеса просто не было. Те же симптомы.
Пока я грустно рылся в журнале отладки, я заметил еще одно многообещающее предупреждение:
_WARN: plugin: eval failed: Небезопасная зависимость в sprintf при работе с ключом -T в / usr / share / perl5 / Mail / SpamAssassin / Logger.pm, строка 241.
Что, черт возьми, за переключатель -T ...
man perl
не может найти его прямо здесь (если бы я знал правильную главу).
Исходный код spamassassin тоже не сильно помог.
Но после небольшого поиска в Google, после того как я сузил запрос, Я получил это:
http://search.cpan.org/~bdfoy/PerlPowerTools-1.012/bin/printf
И несколько других указателей на
«Небезопасная зависимость в eval при запуске setuid»
То же самое? Вероятно. Переключатель -T предназначен для "испорченного режима".
https://perldoc.perl.org/perlsec.html#Taint-mode
И это мера безопасности, так что ваши случайные "оценки" с printf внутри "нелегко перехватить для" внедрения кода ".
Теперь, где, черт возьми, задействуется этот переключатель -T.
SpamAssassin работает как модуль Amavis.
Я уже знал, что Amavis на самом деле был сценарием Perl.
Интерпретатор Perl, вероятно, вызывается с помощью #! спецификация оболочки в первой строке в / usr / sbin / amavisd-new.
Конечно.
Отсюда обходной путь прост.
Но ... Ой! Наверное, не стоит никому рассказывать: ->
Тем не менее ... я не понимаю, почему это вдруг сработало какое-то время, а потом вдруг больше нет, больше нет. Где скрытое состояние? Я перезапускал Amavis после каждого изменения файлов конфигурации, это означает, что я перезапускал интерпретатор Perl каждый раз ...
«Это какой-то жуткий $ # | t, который мы получили, сержант ...»
(перефразируя Генри Роллинза в «Затерянном шоссе»)
Фрэнк