...
- A rule starts off in a developer's sandbox . It may be an experimental rule ("tflags nopublish" or "T_" prefix on the name)as an experimental rule, one that he doesn't want to publish just yet.
- Alternatively, it may be a non-experimental, but still in-sandbox, testing rule. These need to be marked by the developer with "tflags publish".
- 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 "rules" 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, "tflags nopublish", or the absence of a "tflags nopublishpublish", implies this. These rules are compiled, by the "build/mkrules" compiler at "make" time, to "rules/70_sandbox.cf".
- s_poor – promotable, listed with "tflags publish", but not meeting promotion criteria. Compiled to "rules/70_sandbox.cf". "T_" is prefixed to the rule name.
- s_good – promotable, listed with "tflags publish", and meeting criteria. Rules in this state are copied into the "active set". Compiled to "rules/72_active.cf".
...