On 2020-05-28 15:32, Bert Van de Poel wrote:
Almost all of the email we process are forwarders. It doesn't really
make sense for us to do a non-global bayes db. The large majority of
email we process is also for a uniform group: student organizations at
our local university.
On 28.05.20 21:05,
Oh, I had misunderstood you, Matus. My bad! I thought you meant we
should use a separate bayes db for every mailbox user, but now I
understand you were referring to the amavis user which indeed runs
everything.
I just moved the existing bayes db (after stopping amavis of course) to
the amavis
On 2020-05-28 15:32, Bert Van de Poel wrote:
Almost all of the email we process are forwarders. It doesn't really
make sense for us to do a non-global bayes db. The large majority of
email we process is also for a uniform group: student organizations at
our local university.
does not matter if
On 2020-05-28 15:22, Matus UHLAR - fantomas wrote:
On 28.05.20 13:38, Bert Van de Poel wrote:
We're using a global bayes_path defined in local.cf:
This is your problem imho.
if you use amavis, you need no bayes database, but amavis users',
i guess in /var/lib/amavis/.spamassassin/
if amavis
On 2020-05-28 10:18, Matus UHLAR - fantomas wrote:
I wonder where did these files come from.
did you sety bayes_path in /etc/spamassassin/ ?
setup userprefs file for amavisd, in this file make sure bayes data keep
in amavisd user, not the spamassasin user where there is no write access
hop
On 28.05.20 15:32, Bert Van de Poel wrote:
Almost all of the email we process are forwarders. It doesn't really
make sense for us to do a non-global bayes db. The large majority of
email we process is also for a uniform group: student organizations at
our local university.
you have apparently
Almost all of the email we process are forwarders. It doesn't really
make sense for us to do a non-global bayes db. The large majority of
email we process is also for a uniform group: student organizations at
our local university.
On 28/05/2020 15:22, Matus UHLAR - fantomas wrote:
On 28.05.20
On 28.05.20 13:38, Bert Van de Poel wrote:
We're using a global bayes_path defined in local.cf:
This is your problem imho.
if you use amavis, you need no bayes database, but amavis users',
i guess in /var/lib/amavis/.spamassassin/
On 28/05/2020 10:18, Matus UHLAR - fantomas wrote:
On 25.05
We're using a global bayes_path defined in local.cf:
use_bayes 1
use_bayes_rules 1
bayes_auto_learn 1
bayes_expiry_max_db_size 150
bayes_path /var/lib/spamassassin/bayes_db/bayes
bayes_file_mode 0775
bayes_ignore_to spam-analy...@ulyssis.org
bayes_ignore_from spam-analy...@ulyssis.org
bayes_a
On 25.05.20 23:34, Bert Van de Poel wrote:
Recently, we've been setting up Bayesian learning on our existing
Amavis with Spamassassin setup on Ubuntu 18.04 (Spamassassin
3.4.2-0ubuntu0.18.04.3 and Amavis 1:2.11.0-1ubuntu1). We've decided to
use a global db that was seeded with an aggregation of
Plugin initialization+journal sync would make a lot of sense.
What would be the cleanest solution in that case? It's quite annoying to
receive the same error mail every day. Should we use --cnf to disable
the bayes plugin, or is there a more elegant solution? Should we file a
bug about this?
On Mon, 25 May 2020 23:34:27 +0200
Bert Van de Poel wrote:
> My question therefore specifically is: what exactly does sa-compile
> do to the bayes database files?
I don't know for sure, but it's probably just a side-effect of
initializing plugins. Possibly it's trying to perform an opportunistic
12 matches
Mail list logo
