Page History

...

• A rule starts off in a developer's sandbox. It may be an experimental rule ("tflags nopublish" or "T_" prefix on the name).
• Alternatively, it may be a non-experimental, but still in-sandbox, testing rule.
• The developer may decide to switch the rule back and forth between those two states.
• Non-experimental rules' promotability is measured (see SaUpdateBackend).
• If it's good enough, it's published to the "active set".
• A good rule may be manually copied from the sandbox to the "rulesrc/corerules" directory.
• Eventually, it stops being good enough, through the normal attrition process for antispam rules, and it stops meeting the promotion criteria.
  

...

• experimental – don't promote me. "T_" prefix / in the rulesrc source file, or "tflags nopublish" implies this. These rules are compiled, by the "build/mkrules" compiler at "make" time, to "rules/70_sandbox.cf".
  
• s_poor – promotable, but not meeting promotion criteria. Compiled to "rules/70_sandbox.cf". "T_" is prefixed to the rule name.
  
• s_good – promotable, and meeting criteria. Rules in this state are copied into the "active set". Compiled to "rules/72_active.cf".
  

Rules in corethe engine tarball:

• core – no promotion criteria are needed; this is part of the core ruleset. Often tied closely to the distributed Mail::SpamAssassin perl modules. These are not compiled at all by "build/mkrules", and are always distributed. (new as of bug 5123.)
• c_poor – promotable, but not meeting promotion criteria. Compiled to "rules/70_inactive.cf".
  
• c_good – promotable, and meeting criteria. Rules in this state are copied into the "active set". Compiled to "rules/72_active.cf".
  

Deleted rules:

• gone – rule has been deleted. If a rule is in c_poor scores badly in core for "an extended period of time", it goes here. (Right now, this has to be done manually.)
  

...

• code_tied – rule is very dependent on the distributed Mail::SpamAssassin perl modules, and is therefore still distributed as part of the "rules" directory in the code package. These are not compiled at all by "build/mkrules", and are always distributed.
  

(History: \[http://www.nabble.com/hackathon-notes-from-Sat-p1887702.html mailing list message\], bug 5123)

State Transitions

The permitted transitions for those rule states, therefore, are as follows:

• experimental <---> s_poor
• experimental <---> s_good
• (hand copy) s_poorgood <---> s_goodc_poor core
• (hand copy) core <---> c_goodc_poor -> gone
  

List Of Build States

Some rules are only used from certain build states. Here are the list of states that SpamAssassin goes through, or that rules are packaged as, during various parts of its build process.

...