Theo Van Dinter writes: > On Mon, Mar 06, 2006 at 08:11:24PM +0000, Justin Mason wrote: > > > more config files that go with plugins, so they should be in rules and > > > not rulesrc > > > > Hold on -- I'm not keen on this. What's wrong with "ifplugin"? > > There's nothing wrong with "ifplugin", but the idea was to have > code-related rules in the rules area, and not rulesrc. plugins are code, > and we already had the other plugin files (uribl, razor, dcc, awl, etc,) > in rules. I was just moving the outliers into the right place.
I thought the idea was to share as many rules as possible between releases, by keeping them in rulesrc instead of rules? These are not really code-tied rules -- they're just a rule type implemented by a plugin! The check_rbl() syntax, and the URIDNSBL rule syntax, hasn't changed afaik since 3.0. That's nice version portability, and rules using those syntaxes can live safely in rulesrc as a result, in my opinion. If we make it a guideline that rules implemented using "check_rbl()" or "urirhssub" are considered "code-tied" rules, as much as let's say header NO_DNS_FOR_FROM eval:check_dns_sender() and therefore should go in "rules", we can't test them in a sandbox -- instead we'd have to throw them in with the released set in rules/25_uribl.cf, or revive the obsolete rules/70_testing.cf idea again. I think this is messy. Basically I was planning to keep rules as much as possible in rulesrc, and where possible, render the "rules" dir obsolete -- just use it as the place where mkrules writes its output. Otherwise we run into a situation where there isn't really much point in *having* the rulesrc-vs-rules differentiation! (Bear in mind that rules in "rules" are considered legacy rules, are not compiled/lint-checked, are allowed to get past the new accuracy requirements, and so on. It really is a legacy situation.) --j.
