http://bugzilla.spamassassin.org/show_bug.cgi?id=3454
------- Additional Comments From [EMAIL PROTECTED] 2004-06-01 14:38 -------
Subject: Re: New rule form for de-obfuscation rules
> This idea is basically the same as bug 1050, I have some new ideas about
> how this should be done (a plug-in for one thing, and only transform the
> regular expression for performance reasons, but it should get discussed
over
> there.
I'm fine with the idea of plugins for oddball rules, BUT, I think this is a
thing that would be of suffcient general use, and easy enough to implement
(at least in the rule syntax, with no ambiguity) that strong consideration
should be given to implementing at least the basic s//g substitution
properties as an optional part of a normal rule.
I grant that if you need more than one or two substitutions then you
probably at the moment need to figure out how to write perl and do a plugin;
the current rules are not designed for anything vaguely procedural, or even
for a sequential set of transformations. But my current belief is that the
ability to do one or maybe a small number of sequential substitutions before
applying the re could be quite useful.
While tossing ideas around, a more aggressive form of this, although
potentially quite useful, would be to allow the user (either through some
new rule type or a plugin) to effectively declare new body/header parts,
which would then be exposed to normal rule testing for that email.
Thus you could do something like de-obfuscating the subject or body,
creating a cleansubject or cleanbody object, and then run a rule on
'cleanbody MY_TEST /best prices/' which would (obviously) do a normal scan
on the newly-created string.
The advantage of allowing a method of creating a persistant mangled form of
the email is that the form may be useful for many test rules, and making it
persistant means that the conversion would only be done once, not once for
each rule.
While something like this could obviously get done in a single plugin, the
result is to start migrating the test rules from the test base into a random
plugin someplace, which now tests for umpteen different things just because
they all depend on the same transform of the email.
I'm not at all sure that this would be a good idea. For one thing, I'm not
sure how to score the potentially many rules inside a single plugin vs the
normal rules. It would surely be a mistake to assign them all a single
score, which I think is exactly what would happen currently. It also leads
to fracturing the 'standard rules' into things that now have to be looked up
in potentially many places.
Loren
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
