testing Malware Patrol rules?
hi Andre -- A SpamAssassin user mentioned this ruleset today: http://malware.hiperlinks.com.br/cgi/submit?action=list_sa it looks good! Would you mind if I added a copy of that to our rule-QA system (http://ruleqa.spamassassin.org/), primarily to determine false positive rate? If that goes well, btw, a possibility would be that I could generate a SpamAssassin rule updates channel for you, similar to how the sought ruleset works: http://wiki.apache.org/spamassassin/SoughtRules . Let me know if you're interested in that. cheers, --j.
Re: testing Malware Patrol rules?
On Fri, Jul 24, 2009 at 09:45:42AM +, Justin Mason wrote: hi Andre -- A SpamAssassin user mentioned this ruleset today: http://malware.hiperlinks.com.br/cgi/submit?action=list_sa it looks good! Would you mind if I added a copy of that to our rule-QA system (http://ruleqa.spamassassin.org/), primarily to determine false positive rate? If that goes well, btw, a possibility would be that I could generate a SpamAssassin rule updates channel for you, similar to how the sought ruleset works: http://wiki.apache.org/spamassassin/SoughtRules . Let me know if you're interested in that. I would add \b or so in front of the sigs.. For example, /zief\.pl\//i should be /\bzief\.pl\//i. Unbounded short domains like that have chances of FPs. Cheers, Henrik
Re: testing Malware Patrol rules?
On Fri, 24 Jul 2009 16:09:46 +0300, Henrik Krohns wrote: On Fri, Jul 24, 2009 at 09:45:42AM +, Justin Mason wrote: hi Andre -- A SpamAssassin user mentioned this ruleset today: http://malware.hiperlinks.com.br/cgi/submit?action=list_sa it looks good! Would you mind if I added a copy of that to our rule-QA system (http://ruleqa.spamassassin.org/), primarily to determine false positive rate? If that goes well, btw, a possibility would be that I could generate a SpamAssassin rule updates channel for you, similar to how the sought ruleset works: http://wiki.apache.org/spamassassin/SoughtRules . Let me know if you're interested in that. I would add \b or so in front of the sigs.. For example, /zief\.pl\//i should be /\bzief\.pl\//i. Unbounded short domains like that have chances of FPs. Plus they should be URI rules, otherwise you're just re-scanning the entire body. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: testing Malware Patrol rules?
On Fri, 2009-07-24 at 10:05 -0400, Matt Sergeant wrote:
On Fri, 24 Jul 2009 16:09:46 +0300, Henrik Krohns wrote:
I would add \b or so in front of the sigs..
For example, /zief\.pl\//i should be /\bzief\.pl\//i. Unbounded short
domains like that have chances of FPs.
Plus they should be URI rules, otherwise you're just re-scanning the
entire body.
Exactly my thought, when I saw this on the users list. These should be
uri rules, which will be *much* faster.
More importantly, though -- they need to be uri rules, to NOT FP with a
text match. This is exactly the problem ClamAV third-party sig writers
focusing on URIs currently are struggling with, because there is no
equivalent to SA uri rules, nor *any* way to have such sigs properly
bound. With ClamAV that is. ;) Much discussed recently.
For the very same reason I agree with Henrik. If used in SA, these not
only should be URI rules, but need to be bound. Both, at the beginning
and end. At the very least, using \b, need something slightly more
sophisticated for the end, to exclude a dot.
acebook.com, anyone? ;-)
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
