On Mon, 16 Sep 2013, Abhijeet Rastogi wrote:
Hi John,
Thanks for the reply. I could get the above said rule as a "meta" one.
Thanks for that.
Apologies if that came across as condescending, I was just trying to be
thorough.
One more thing I was hoping you could help me with.
Can you explain as to what's the difference between rules under
"./rules" and under "./rulesrc/sandbox/" directory?
The "rules" directory is rules that are published no matter what. That's
the "static" ruleset, the base rules that everything can depend on to be
present, and rules that have always performed well.
The stuff under the sandbox directories is more dynamic. The rules there
are run through the nightly masscheck process, and if they perform well
enough they get published. They're more "dynamic", in that older rules
that stop performing well against current spam (as represented by the
masscheck corpora) may stop being published, and may automatically start
being published again if the corpora starts containing that type of spam
again.
The reason I want to know this is because I've a requirement where I
want to disable everything (meaning *all* rules) except a locally hosted
URIBL). I was hoping that I could do this by adding the output of the
below command. (running in the source code).
cat rules/*.cf | grep -E '^(header|body)' | awk '{print $2}' | sed
's/^/score /' | sed 's/$/ 0/'
But, to my surprise, it didn't help. I still had various checks stull
getting applied like __HAS_TO, __HAS_ERRORS_TO etc etc. Any idea as to
what can be done about that?
As __subrules don't have a score, their execution cannot be disabled by
setting their score to zero.
If you want to override the default behavior of SA to that degree, it's
easier to change the config directory that SpamAssassin and spamd use with
the -c option, so that none of the base rule files are read in the first
place. You'll need to provide some minimal set of config files in whatever
custom config directory you specify in order to get SA to run, but that
will avoid all the extra default stuff you don't seem to want.
I've never customized SA to that degree so there may be some pitfalls in
this that I'm not aware of - somebody else will probably say something if
there's other stuff you need to be aware of.
On Mon, Sep 16, 2013 at 10:07 PM, John Hardin <[email protected]> wrote:
On Mon, 16 Sep 2013, Abhijeet Rastogi wrote:
Problem is, how do I know that a certain rule like __RCVD_IN_NJABL is
a base rule for others?
The two leading underscores in the rule name indicate that the rule, by
itself, is not assigned a score, thus, by itself, does not affect the
overall score of the message at all. It must appear in a "meta" rule,
possibly with other rules, before it can be assigned a score and affect the
overall message score. So, at the most basic level, any rule having a name
that starts with two underscores is _inherently_ a base for other rules.
In order to determine *which* rules it's a base for, you have to look for
that rule name in the config files. This isn't too easy to do online, you
pretty much have to grep the rules files in a local install.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
[email protected] FALaholic #11174 pgpk -a [email protected]
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Where We Want You To Go Today 07/05/07: Microsoft patents in-OS
adware architecture incorporating spyware, profiling, competitor
suppression and delivery confirmation (U.S. Patent #20070157227)
-----------------------------------------------------------------------
Tomorrow: the 226th anniversary of the signing of the U.S. Constitution
