У меня есть серверы почтового шлюза, настроенные на использование 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
Маркеры Bayes запоминаются правильно, однако эта ошибка вызывает незначительное раздражение, и я хотел бы ее исправить ... Либо заставив SpamAssassin не проверять каталог /root/.spamassassin/ на предмет config и prefs, либо исправить MailWatch поэтому он правильно вызывает sa-learn и не выдает эту ошибку.
Это не ошибка, это связано с тем, что вы запускаете команду 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, чтобы соответствовать для ветчины и спама, и никогда не ошибаться. Убедитесь, что ваша настройка и группа user: верны в соответствующих файлах / каталогах.
Ссылка на краткое руководство о том, как исправить https://www.devcu.com/forums/topic/745-spamassassin-is-inaccessible-permission-denied/
Настоящее исправление состоит в том, чтобы отключить конфигурацию "для каждого пользователя" в spamassassin и глобально установить Baysean DB, но быстрое исправление будет заключаться в добавлении параметра "-H" в sudo для использования домашнего каталога postfix, где он должен иметь разрешение на запись как постфикс.
Это может быть обходной путь:
# 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
Разве вы не должны использовать демон spamassassin спам вместо? Тогда вы бы использовали спам command вместо spamassassin. В принципе, запустить спам из его сценария запуска и используйте спам из вашего почтового сканера.
Вы пробовали добавить такой параметр --dbpath?
sa-learn --dbpath /var/lib/amavis/.spamassassin/ ....
Причина
Причина в том, что spamassassin (который вызывается sa-learn, spamc, spamd, spampd и т. Д.) Пытается прочитать файл конфигурации для каждого пользователя из $ HOME.
Это происходит, даже если параметр конфигурации allow_user_rules установлен на 0 (IMO, вероятно, это ошибка, и это было около длинный время).
Поскольку он не может найти эту папку (из-за разрешений), он затем пытается создать папку.
Те, кто запускает sa-learn внутри cron, знают, что это очень раздражает, поскольку мы получаем сообщение об ошибке даже при успешном запуске. Просто погуглите ошибку config: путь "/root/.spamassassin" недоступен: в доступе отказано и посмотрите, на скольких людей это повлияет (и какие небезопасные решения они предлагают). Единственным безопасным решением для cron было игнорировать его и направлять stdout и stderr в / dev / null, но это немного экстремально.
Это происходит независимо от того, какие параметры -C или -p или --dbpath переданы, поэтому вы не можете исправить это ни в параметрах командной строки, ни в глобальной конфигурации.
Исправление
Решение, которое сработало для меня, состоит в том, чтобы вызвать sa-learn и передать временную переменную среды $ HOME, указывающую на место, куда может писать не-root пользователь, запускающий spamassassin, в моем случае это / var / cache / spampd: например.
HOME=/var/cache/spampd sa-learn --spam /var/vmail/jason/.SPAM/cur