SpamAssassin пытается прочитать конфигурационные файлы в /root/
У меня есть серверы почтового шлюза, настроенные для использования MailScanner + Postfix + SpamAssassin, как описано здесь, наряду с MailWatch в качестве веб-интерфейса.
Когда sa-learn запускается из MailWatch (он запускается как пользователь postfix), он выдает эту ошибку:
SA Learn: config: path "/root/.spamassassin" is inaccessible: Permission denied, Learned tokens from 0 message(s) (1 message(s) examined)
Запуск "sudo -u postfix spamassassin --lint -D" дает следующую информацию:
dbg: config: read file /etc/mail/spamassassin/mailscanner.cf
warn: config: path "/root/.spamassassin" is inaccessible: Permission denied
dbg: config: mkdir /root/.spamassassin failed: mkdir /root/.spamassassin: Permission denied at /usr/lib/perl5/site_perl/5.8.8/Mail/SpamAssassin.pm line 1577
dbg: config: Permission denied
dbg: config: using "/etc/MailScanner/spam.assassin.prefs.conf" for user prefs file
Токены байесов изучены правильно, однако эта ошибка является незначительным раздражением, и я хотел бы ее исправить... Либо заставив SpamAssassin не проверять каталог /root/.spamassassin/ для config & prefs, либо исправить MailWatch поэтому он вызывает sa-learn правильно и не выдает эту ошибку.
6 ответов
Реальное исправление состоит в том, чтобы отключить конфигурацию "на пользователя" в spamassassin и глобально установить базу данных Baysean, но быстрый патч - добавить опцию "-H" в sudo, чтобы использовать домашний каталог postfix, где он должен иметь разрешение на запись как постфикс.
Это не ошибка, потому что вы запускаете команду sa-learn с недопустимым пользователем. Например, моя установка использует стандартного пользователя debian-spamd.
# sa-learn -u debian-spamd --dbpath /var/lib/spamassassin/.spamassassin/bayes --dump magic
0.000 0 3 0 non-token data: bayes db version
0.000 0 84 0 non-token data: nspam
0.000 0 6565 0 non-token data: nham
0.000 0 15128 0 non-token data: ntokens
0.000 0 1510837441 0 non-token data: oldest atime
0.000 0 1519232775 0 non-token data: newest atime
0.000 0 0 0 non-token data: last journal sync atime
0.000 0 0 0 non-token data: last expiry atime
0.000 0 0 0 non-token data: last expire atime delta
0.000 0 0 0 non-token data: last expire reduction count
И для аккаунтов
# sa-learn --ham -u debian-spamd --showdots --dir /var/vmail/mydomain.com/support/cur/*
.
Learned tokens from 1 message(s) (1 message(s) examined)
У меня есть 20 учетных записей электронной почты на сервере и crons, чтобы соответствовать ветчина и спам, и никогда не ошибка. Убедитесь, что ваши настройки и пользователь: группа правильно указаны в соответствующих файлах / каталогах.
Ссылка на краткое руководство о том, как исправить https://www.devcu.com/forums/topic/745-spamassassin-is-inaccessible-permission-denied/
Это может быть обходной путь:
# chmod o+x /root
# mv -f /root/.spamassassin /root/.spamassassin.err
# ln -s /var/spool/MailScanner/spamassassin /root/.spamassassin
# mkdir -p /var/spool/MailScanner/spamassassin
# chown postfix.apache /var/spool/MailScanner/spamassassin
# chmod 770 /var/spool/MailScanner/spamassassin
Вы пытались добавить параметр --dbpath, как это?
sa-learn --dbpath /var/lib/amavis/.spamassassin/ ....
Разве вы не должны вместо этого использовать spamassassin daemon spamd? Тогда вы бы использовали команду spamc вместо spamassassin. По сути, запустите spamd из его скрипта запуска и используйте spamc из вашего mailscanner.
Причина
Причина в том, что spamassassin (который вызывается sa-learn, spamc, spamd, spampd и т. Д.) Пытается прочитать файл конфигурации для каждого пользователя из $HOME.
Это происходит, даже если для опции конфигурации allow_user_rules задано значение 0 (IMO, вероятно, это ошибка, и она давно работает).
Поскольку он не может найти эту папку (из-за разрешений), он затем пытается создать папку.
Те, кто запускает sa-learn в cron, знают, что это очень раздражает, поскольку мы получаем сообщение об ошибке даже после успешного запуска. Просто погуглите конфиг ошибки : путь "/root/.spamassassin" недоступен: в доступе отказано и посмотрите, сколько людей это влияет (и предложенные небезопасные исправления). Единственное безопасное решение для cron - игнорировать его и направлять stdout и stderr в /dev/null, но это немного экстремально.
Он делает это независимо от того, какие параметры -C или -p или --dbpath переданы, поэтому вы не можете исправить это ни в параметрах командной строки, ни в глобальном конфиге.
Исправление
Решение, которое сработало для меня, состоит в том, чтобы вызвать sa-learn и передать временную переменную среды $ HOME, указывающую место, в которое может записать некорневый пользователь, выполняющий spamassassin, в моем случае это /var/cache/spampd: например
HOME=/var/cache/spampd sa-learn --spam /var/vmail/jason/.SPAM/cur