axb.lists at gmail
Feb 28, 2012, 9:38 AM
Post #10 of 11
On 02/28/2012 03:27 PM, John Hardin wrote:
Re: __FILL_THIS_FORM_SHORT* rule slowness
[In reply to]
> On Tue, 28 Feb 2012, Axb wrote:
>>> T __FILL_THIS_FORM_SHORT2 5.9169 5.9169 1
>>> T __FILL_THIS_FORM_LONG2 5.9041 5.9041 1
>>> T RAZOR2_CF_RANGE_E8_51_100 5.0010 5.0010 1
>>> T __FILL_THIS_FORM_FRAUD_PHISH1 2.1362 2.1362 1
>>> T __FILL_THIS_FORM_SHORT2 6.9687 6.9687 1
>>> T __FILL_THIS_FORM_LONG2 6.8891 6.8891 1
>>> T __FILL_THIS_FORM_FRAUD_PHISH1 2.5187 2.5187 1
>>> T __FILL_THIS_FORM_LOAN1 1.6947 1.6947 1
>> THANKS! you made my day.
>> now: is this ReplaceTags slowness or .....
> Replacetags by itself is lightweight, it's just string substitution.
>> what can you do to solve this? kill the rules?
> Well, jeeze, you could give me a chance to look at them first... :)
> You're always welcome to zero the scores of these rules if their
> filtering performance for your mail stream doesn't justify their
> overhead. If there is community consensus that detecting
> fill-in-the-form spams isn't valuable enough to justify the overhead of
> running these (admittedly complex) rules, then I can disable them in my
> sandbox; but I'd like a consensus before doing that.
ruleqa's overlaps should give us more data.
If we can agree a small group to review hits, I'm pretty sure we'd find
lots of cases where rules are redundant, merely by autopromoting similar
rules from various sandboxes.
To be honest with you, I'd rather we put emphasis in frequent auto rule
generation than collecting heaps of low scoring rules/metas which aren't
doing speed a favour.