Re: Constant .info domain spam

2010-10-13 Thread Michelle Konzack
Hello Julian Yap, Am 2010-10-12 10:32:39, hacktest Du folgendes herunter: > NOTE: I changed the domains below to 'dot info' as the mailing list > rejected my initial submission. > > I'm pretty sure it's not just me but there is some constant spamming > from dot info domains. Perhaps for the pas

Re: Difference in score returned and sum of all points

2010-10-13 Thread Anthony Cartmell
All *.cf files under that directory contain rule definitions. How are their names chosen is not important. What is the point of your question? Matus, this particular point was just out of my curiosity, nothing more than that. I just wanted to understand the reason for prefixing file names

Re: Difference in score returned and sum of all points

2010-10-13 Thread John Hardin
On Tue, 12 Oct 2010, Gnanam wrote: Matus, this particular point was just out of my curiosity, nothing more than that. I just wanted to understand the reason for prefixing file names with 10,20,30,etc. when it can be just actual rule names as file name like head_tests.cf, html_tests.cf, etc.

overlapping HABEAS_ACCREDITED_SOI and RCVD_IN_BSP_TRUSTED

2010-10-13 Thread Matus UHLAR - fantomas
Hello, I've received a spam that his both HABEAS_ACCREDITED_SOI and RCVD_IN_BSP_TRUSTED. I believe it's because both BSP and HABEAS were bought by ReturnPath Inc. However those two rules seems to be superflous to each other and while I can of course manually disable them or lower the scores, I w

Re: Babes in blue spam

2010-10-13 Thread mdunlap
Thanks Karsten, I am a bit new to this so I do apologize. Here is a link to one of the offending emails, http://drop.io/xf2ict5/asset/spam When I try to have the Bayesian filter learn from spam in the terminal and was to run "sa-learn --spam RANDOM_SPAM_MESSAGE" it would output as: "Learned tokens

Re: overlapping HABEAS_ACCREDITED_SOI and RCVD_IN_BSP_TRUSTED

2010-10-13 Thread Jason Bertoch
On 2010/10/13 12:25 PM, Matus UHLAR - fantomas wrote: Hello, I've received a spam that his both HABEAS_ACCREDITED_SOI and RCVD_IN_BSP_TRUSTED. I believe it's because both BSP and HABEAS were bought by ReturnPath Inc. There's good info on these rules in Bug 6247 https://issues.apache.org/SpamA

Re: overlapping HABEAS_ACCREDITED_SOI and RCVD_IN_BSP_TRUSTED

2010-10-13 Thread Clayton Keller
On 10/13/2010 1:26 PM, Jason Bertoch wrote: On 2010/10/13 12:25 PM, Matus UHLAR - fantomas wrote: Hello, I've received a spam that his both HABEAS_ACCREDITED_SOI and RCVD_IN_BSP_TRUSTED. I believe it's because both BSP and HABEAS were bought by ReturnPath Inc. There's good info on these rule

Re: Babes in blue spam

2010-10-13 Thread Karsten Bräckelmann
On Wed, 2010-10-13 at 13:10 -0500, mdunlap wrote: > Thanks Karsten, I am a bit new to this so I do apologize. Here is a link > to one of the offending emails, http://drop.io/xf2ict5/asset/spam That sample is about 980 kB large. This would solve the first mystery -- why SA "does not recognize it a

Re: Babes in blue spam

2010-10-13 Thread Karsten Bräckelmann
On Wed, 2010-10-13 at 21:06 +0200, Karsten Bräckelmann wrote: > On Wed, 2010-10-13 at 13:10 -0500, mdunlap wrote: > > Thanks Karsten, I am a bit new to this so I do apologize. Here is a link > > to one of the offending emails, http://drop.io/xf2ict5/asset/spam > > That sample is about 980 kB large

Re: overlapping HABEAS_ACCREDITED_SOI and RCVD_IN_BSP_TRUSTED

2010-10-13 Thread J.D. Falk
On Oct 13, 2010, at 9:25 AM, Matus UHLAR - fantomas wrote: > I've received a spam that his both HABEAS_ACCREDITED_SOI and > RCVD_IN_BSP_TRUSTED. I believe it's because both BSP and HABEAS were bought > by ReturnPath Inc. > > However those two rules seems to be superflous to each other and while

Re: overlapping HABEAS_ACCREDITED_SOI and RCVD_IN_BSP_TRUSTED

2010-10-13 Thread Matus UHLAR - fantomas
> On Oct 13, 2010, at 9:25 AM, Matus UHLAR - fantomas wrote: > > > I've received a spam that his both HABEAS_ACCREDITED_SOI and > > RCVD_IN_BSP_TRUSTED. I believe it's because both BSP and HABEAS were bought > > by ReturnPath Inc. > > > > However those two rules seems to be superflous to each ot