Thanks guys,
There isn't a lot of description of this because most people don't
want to
do this - most f the value of SA comes in the rules packaged with
it that
have been tested to hit current spam.
The main reason why you're finding little documentation about
"starting
from the ground up" is that it's a MASSIVE amount of work. I probably
sunk about 100 man-hours of my free time into creating the rules in
antidrug.cf, maybe more. That's for a very small number of rules.
Must be to many years of building legos, one brick at a time.
I may well use most of the well tested/supported cf files (including
antidrug.cf), but I want to use them in my own way. It appears that
most configurations handle few domains with a specific kind of email
and various exceptions. This lends itself to starting with the
public config and then modifying it. I want to handle a range of
types, all at the same time and all with the same configuration.
Short term it will be more work to get started and long term it will
mean more work keeping up to date (cross checking every line of each
file thats added/updated), but I'm that fanatical about FP/FN
performance.
My biggest challenge is actually getting an adequate spam/ham corpus
on which to perfect everything.
In theory, if you delete all the rule/config files, then you'd have a
perfectly working SA that would always generate scores of 0.
That said, this is not a well tested configuration. Some of the in-
code
defaults may not match those established by 10_misc.cf, and some
things
may not have defaults at all and may cause errors. You might want to
consider keeping this file, if for no other reason then ensuring
all the
settings get reasonable defaults.
...init.pre to enable some plugins
and a local.cf with some minimal configuration in it. And the one
or two
rules you want to run. Additional rules can be put into
anything.cf in the
same directory with local.cf, and the files will be read
alphabetically.
Will do. The approach I'm taking is to separate every file into what
I understand (ie filters) and what I don't (configs), push all the
filters aside, and try to understand every line of each config file.
At this point (I've been learning for a week now), most of what I
don't are the misc and .pre files. Once I learn them and build my
scoring foundation, I will add the filter content (if not the actual
files) back in.
Yes, rules can be in any file with any name that ends in .cf
Just remember that SA parses rule files in alphabetic order, so if you
want to reference rules across files, name them to fit the parse-order
you need.
Nice, thats more flexibility than I'm used to, but flexibility that
forces us to use our own structure(s), less we get lost. I just have
a habit of pushing things to there limits, so I want to know what
they are. This is looking like a robust platform (a la Unix).
Are new rules in new files automatically added when present?
Yes, but if you use spamd, spamd only parses these two directories
when
it loads, so you'd have to restart spamd.
Will do. I'll work out a update regiment.
Dan
