
axb.lists at gmail
Feb 28, 2012, 9:38 AM
Post #10 of 11
(344 views)
Permalink
|
|
Re: __FILL_THIS_FORM_SHORT* rule slowness
[In reply to]
|
|
On 02/28/2012 03:27 PM, John Hardin wrote: > 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. > >> John, >> 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.
|