Title: RE: Normalized text ruletype

Hi,
(sorry about quoting, I'm stuck with using OWA for this email address
at the moment ickickick).

>  loadplugin    Mail::SpamAssassin::Plugin::ReplaceTags
This sounds interesting. Our two approaches are similar, but I don't
think they clash, more complement each other. ReplaceTags gives
more freedom to the rule writer, but also places a greater
burden on him, and normal rules restrict the rule writer somewhat
while keeping rules legible.

The replace tags are a lot more flexible, but as already stated, also
a lot more expensive. My version doesn't support multi-character
substitutions (yet, but that's just a matter of extending the maps),
replacetags otoh will still need lots of quantifiers to catch some of
the very gappy keywords.

>  body          VIAGRA_OBFU     /(?!viagra)<V>+<SP>*<I>+<SP>*<A>+<SP>*<G>+<SP>*<R>+<SP>*<A>+/i
11 unqualified quantifiers in one rule? :)


>  replace_post RE       +
>  replace_inter SP      [\s~_-]*

>  body          VIAGRA_OBFU     /<inter W2><post RE>(?!viagra)<V><I><A><G><R><SP>/i
I see a possible danger here. You're hiding the quantifiers from people,
so it will be a lot easier to write rules which will take a very long
time to complete, without people noticing what they're doing (not
demoting your approach, just pointing out a danger I'm seeing).

What I don't understand yet: Will ReplaceTags work on all exising rules
that get loaded after the plugin gets invoked? What happens when
people use ReplaceTags-Rules on their own and grab e.g. SARE rules where
the plugin would be used as well, and both versions have different
starting and ending tags?

Anyway, would it make sense to introduce normalized rules at some point
when convinient, so that we have both approaches running in parallel and
seeing if normalized rules actually get used/are useful in the real world?
If they prove to be too unflexible, it can always get yanked back out
again - the code impact isn't that big.

Regs,
Sven



Reply via email to