| Table of Contents |
|---|
Rule Sandboxes
Every committer has a 'sandbox' area in the rules source tree ('rulesrc'). This is an area for rules under development.
...
- rulesrc/core/ = standard rules directory, built into SpamAssassin by default;
- rulesrc/extra/<directory>/ = extra rulesets, not distributed with "core" SpamAssassin;
- rulesrc/sandbox/<username>/ = the sandboxes.
Building
When you run "make" from the masses/ directory, the compiler will run, and performs a few basic "compilation" tasks:
- it copies the 'core' ruleset from rulesrc/core/ into "rules/".
- it'll also look through all rules files in rulesrc/sandbox/*/ , and copies rules found to "rules/70_sandbox.cf" as testing rules.
"Testing rules" are given a T_ prefix, to make it clear (both to users and the code) that they're rules in testing. They also get a little rudimentary lint- and syntax-checking; if they fail, they're not copied.
...
- non-spam-oriented rules, such as the anti-virus-bounce ruleset
- non-English-language rulesets
- rules that positively identify spam from spamware, but hit <0.25% of spam
- an "aggressive" rules set might include rules that hit with an S/O of only 0.89, but push a lot of spam over the 5.0 threshold without impacting significantly on ham
The main thing is that it's a place to put rules that match the ruleset's publishing criteria (whatever they may be) without putting them in the SpamAssassin core.
...
- Create a new sandbox in rulesrc/sandbox (e.g. rulesrc/sandbox/duncf):
| No Format |
|---|
mkdir rulesrc/sandbox/whatever
svn add rulesrc/sandbox/whatever
|
...
- Individual developers may allow more access to files in their sandbox by adding comments to the beginning of the file.
2. If content in the sandbox has been promoted into the core codebase or rules, it is treated like any other portion of the code.
...
(Note: this is documentation; if you want to read the historical planning docs, see RulesProjectPlan and RulesProjSandboxes.)
CategoryRules CategoryDevelopment