spamassassin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Theo Van Dinter <>
Subject Re: moving uribl to rules dir (Re: svn commit: r383618 - in /spamassassin: rules/trunk/core/ rules/trunk/core/ trunk/rules/ trunk/rules/ )
Date Tue, 07 Mar 2006 17:25:40 GMT
On Tue, Mar 07, 2006 at 10:02:06AM +0000, Justin Mason wrote:
> > 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?

For non-code rules, yes.

> These are not really code-tied rules -- they're just a rule type
> implemented by a plugin!

If it's a plugin, it has to be a code-tied rule!  Otherwise it wouldn't need
the 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.

Unless we're distributing the plugins via rulesrc, I'd rather see us keep the
RE-rules and code rules separate.

> 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/, or revive the obsolete rules/ idea again.
> I think this is messy.

Well now, that's another issue.  For *testing*, living in the sandbox is fine.
However, if the rule is going to be promoted to "released", it should be moved
into rules.

It's the same thing that happens now for new EvalTests.  We test by putting a
plugin into the sandbox area, and writing the rules in the sandbox area.  If
it gets to the point it needs to be promoted, we copy the function to
EvalTests (or copy the plugin over), and move the rule to the rules/ dir.

> 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!

The main issue is that if we end up putting everything into rulesrc, we'll
need to start using "if version > ..." conditionals around as things change,
etc.  It gets a bit complex.  Then again, at the moment, we're using a
separate area for released rule updates, so maybe there isn't an issue?

> (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.)

There are a ton of legacy rules in the rulesrc/core area, so that's not a real
reason imo.

The reason we started this discussion is that there isn't a clear policy about
what goes where.  My understanding was that eval rules go into rules/, but
if you look in rulesrc/core you find a bunch of EvalTests-based rules, URIBL,
etc, and in rules/ you find other EvalTests-based rules, SURBL, Razor, etc.

Basically it looks like we went half-way when moving things around, and stopped.

So we really ought to figure out what we want to do and go that way.  If
we care about code-based vs non-code based, then we need to finish moving
things out of rulesrc/ and into rules/.  If we don't care, we can move
basically everything from rules/ into rulesrc/, and surround new
EvalTests/plugins with "if" conditionals, etc.

This tips into another issue which is: how are we going to deal with
rule updates?  The automatic promotion/demotion/active.list thing is
neat, but doesn't necessarily work for all versions of code since we're
only running mass-checks on the latest development version and not on
older versions which may behave differently (message and received header
parser changes, for instance, can cause rule hitrate/accuracy changes).

With judicious use of "if version" and such, we could probably just have a
single update and let everyone download it, though I haven't thought fully
about it yet.  If we manually maintain the previous version's updates, we can
just handle the issues when we want to make a new update -- but then what's
the point of active.list, etc?

Randomly Generated Tagline:
Dumb luck beats sound planning every time.

View raw message