You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Rule Sandboxes

(Note: this is now documentation, meaning that RulesProjectPlan et al have become historical planning docs. we planned this bit at RulesProjSandboxes.)

Every committer has a 'sandbox' area in the rules source tree ('rulesrc'). This is an area for rules under development.

'Sandbox' rules are expected to break, fall over, conflict with existing rules, contain syntax errors, etc. – the compiler should catch those. It's a low-risk development area, in contrast to the "safe" published rulesets.

Repository Organization

The "rulesrc" tree looks like this:

  • 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", 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.

If their names collide with existing rules seen elsewhere, they will be auto-renamed to avoid the collision.

Extras/

Some initial thoughts on typical 'extra' rulesets:

  • 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.

Getting Started

  1. Create a new sandbox in rulesrc/sandbox (e.g. rulesrc/sandbox/duncf): 
    mkdir rulesrc/sandbox/whatever
    svn add rulesrc/sandbox/whatever

2. Create as many files in this directory as I wish, containing as many rules as I wish, named "NN_anything.cf" (where "NN" is 2 digits)

3. Check those files into SVN:

    svn add rulesrc/sandbox/whatever/NN_anything.cf

4. Watch as the preflight mass-checker starts checking them immediately at http://buildbot.SpamAssassin.org/preflight/ .

5. (Optionally) wait for a nightly mass-check.

6. Wait until the mass-check results are in, and look at the results at http://buildbot.spamassassin.org/ruleqa/ .

7. Tweak until I'm satisfied with my rule.

8. ???

9. Profit!

(To expand – those last two steps require some thinking about how we're to do the promotion criteria, which is as yet undone.)

  • No labels