OK, but isn't spamd the "settings" file for spamassassin?
How does spamassassin know how to work if spamd is not used when amavis is
doing the routing?
And if spamassissin is still the "anti-spammer" where do I tell it that
it's
not doing
SA is a really big bunch of perl modules that process one mail message at a
time.
"spamassassin" is simply a perl wrapper script that will cause all of these
modules to come into existance and filter exactly one message.
Amvis-New, and several other tools, are also either written in perl or can
call perl modules directly. So what Amvis-New does is it internally
instantiates all of the perl modules that comprise the guts of spamassassin.
It then takes a mail message, hands it to the SA modules, tells the modules
to do their thing, and then pulls the result back out of the modules. It
looks at the result (spam/not spam and the hit level) compares that to
Amvis' internal setting for spam level, and based on that decides whether to
send the original message through and discard the SA result, or whether to
discard the original and use the SA result.
Now, instantiating all of the perl modules that make up SA is a
resource-consuming activity, and if you have a lot of mail it will eat your
server alive. So spamc and spamd came into existance. Spamd is a perl
script that instantiates an instance of SA as a "server" of sorts. You can
pass it a mail message, it will process it and return the results to you.
But it keeps the SA instance around to process another message, just like
Amvis is doing internally. Spamc is the client that passes a mail message
to spamd and gets the results back.
The end result in this case is you would either be using spamc/spamd, or you
would be using Amvis-New, but typically not both. In either case you are
using the perl modules that comprise SA, but they are instantiated in
different processes.
SA uses a number of configuration files, and they can live in several
places. There are two main default locations, but these locations can be
overridden by passing paths to SA when it is instantiated.
These locations contain a number of *.cf files and several *.pre files.
There might also be some user_prefs files around.
Most of the pre and cf files are part of the SA install and contain the
stock rules and settings. There is local.cf and possibly some others that
contain the local tuning settings. Typcailly when installing SA you need to
look at the *.pre files that contain LoadPlugin lines, and make sure that
the ones you want are uncommented. Many tests will be disabled if the
plugins that implement them are commented out. Then you also need to set up
some basic configuration in local.cf.
That will configure SA itself. As you have already found though, Amvis
itself has some configuration lines that ALSO control how SA will work in
that environment. I suspect many of these options are equivalent to the
command line options on spamd.
So the long answer to your question is "there are several places to look".
The main ones will be local.cf, *.pre, and whatever settings Amvis has.
Loren
