Re: Strange SpamAssassin Statistical Performance

2005-02-27 Thread Matt Kettler
At 05:55 PM 2/26/2005, Justin Mason wrote: I'm thinking it might be worthwhile setting up a section of the FAQ for MailScanner users, similarly for amavisd users, etc. with these type of answers. I'd say pretty much all MailScanner sites with bayes running would need to use that cronjob tactic. Agr

Re: Strange SpamAssassin Statistical Performance

2005-02-26 Thread Justin Mason
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Kettler writes: > At 08:57 PM 2/25/2005, jdow wrote: > > >Sometimes SA may time out. If it does there are no SA markups in the > >messages. Makes it easy to test for. > > True, this can happen when using MailScanner.. > > Although, as it turns

Re: Strange SpamAssassin Statistical Performance

2005-02-26 Thread Matt Kettler
At 08:57 PM 2/25/2005, jdow wrote: Sometimes SA may time out. If it does there are no SA markups in the messages. Makes it easy to test for. True, this can happen when using MailScanner.. Although, as it turns out, FN's aren't the poster's concern. As for SA timeouts under MailScanner, they are usu

Re: Strange SpamAssassin Statistical Performance

2005-02-26 Thread jdow
From: <[EMAIL PROTECTED]> Justin Mason wrote: > So you're seeing a varying amount of ham, peaking during work hours, > but a constant flow of spam? > > That's about right -- spamware never sleeps, whereas legitimate > user-to-user mail is sent when people are around to send it ;) > > - --j. This

Re: Strange SpamAssassin Statistical Performance

2005-02-26 Thread jdow
riday 16:14 Subject: Re: Strange SpamAssassin Statistical Performance > > That's MailScanner; I'm suggesting that if you look to see if it was > processed through SA or not (MS might be skipping if no processes are > available, or might be using the wrong queue, or any number of oth

Re: Strange SpamAssassin Statistical Performance

2005-02-26 Thread Justin Mason
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] writes: > Justin Mason wrote: > > So you're seeing a varying amount of ham, peaking during work hours, > > but a constant flow of spam? > > > > That's about right -- spamware never sleeps, whereas legitimate > > user-to-user mail is

Re: Strange SpamAssassin Statistical Performance

2005-02-26 Thread Jerome Cartagena
So you're seeing a varying amount of ham, peaking during work hours, but a constant flow of spam? That's about right -- spamware never sleeps, whereas legitimate user-to-user mail is sent when people are around to send it ;) You know that is quite an excellent, refreshing, and logical observati

RE: Strange SpamAssassin Statistical Performance

2005-02-26 Thread Matthew.van.Eerde
Justin Mason wrote: > So you're seeing a varying amount of ham, peaking during work hours, > but a constant flow of spam? > > That's about right -- spamware never sleeps, whereas legitimate > user-to-user mail is sent when people are around to send it ;) > > - --j. This causes one of my worries

Re: Strange SpamAssassin Statistical Performance

2005-02-26 Thread Justin Mason
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So you're seeing a varying amount of ham, peaking during work hours, but a constant flow of spam? That's about right -- spamware never sleeps, whereas legitimate user-to-user mail is sent when people are around to send it ;) - --j. Jerome Cartagena

Re: Strange SpamAssassin Statistical Performance

2005-02-26 Thread Eric A. Hall
That's MailScanner; I'm suggesting that if you look to see if it was processed through SA or not (MS might be skipping if no processes are available, or might be using the wrong queue, or any number of other things could be going wrong). On 2/25/2005 6:51 PM, Jerome Cartagena wrote: > MailScanner

Re: Strange SpamAssassin Statistical Performance

2005-02-26 Thread Ken A
Matt Kettler wrote: At 02:04 PM 2/25/2005, Jerome Cartagena wrote: The main reason I believe this is a performance issue is the strange flat line that is demonstrated by the graph. Although it concerns me that I get much more HAM than SPAM (I believe current industry standards report 80+% spam

Re: Strange SpamAssassin Statistical Performance

2005-02-25 Thread Jerome Cartagena
MailScanner does alter the Raw headers of each mail message and I can verify that each message does not get delivered to the user's INBOX until it has been processed. ~Jerome Cartagena On Feb 25, 2005, at 11:28 AM, Eric A. Hall wrote: On 2/25/2005 2:00 PM, Jerome Cartagena wrote: according to th

Re: Strange SpamAssassin Statistical Performance

2005-02-25 Thread Jerome Cartagena
Sorry for the confusion. The blue lines represent HAM "clean" messages. While the green lines represent SPAM. ~Jerome Cartagena On Feb 25, 2005, at 1:22 PM, jdow wrote: What do the colors mean, Jerome? {^_^} - Original Message - From: "Jerome Cartagena" <[EMAIL PROTECTED]> Ok. Here are

Re: Strange SpamAssassin Statistical Performance

2005-02-25 Thread jdow
What do the colors mean, Jerome? {^_^} - Original Message - From: "Jerome Cartagena" <[EMAIL PROTECTED]> > Ok. Here are the graph details of SpamAssassin performance: > > > spam_clean_day: (5 min avg) > Max spam: 1304.0 msgs Average spam: 489.0 msgs Current spam: 516.0 msgs > Max c

Re: Strange SpamAssassin Statistical Performance

2005-02-25 Thread Eric A. Hall
On 2/25/2005 2:00 PM, Jerome Cartagena wrote: > according to the graphs, the number of detected spam has a steady upper > limit while the actual number of undetected spam fluctuates wildly. Can you tell if the undetected spam is getting processed (I like to tag all mail regardless of score). >

Re: Strange SpamAssassin Statistical Performance

2005-02-25 Thread Matt Kettler
At 02:04 PM 2/25/2005, Jerome Cartagena wrote: The main reason I believe this is a performance issue is the strange flat line that is demonstrated by the graph. Although it concerns me that I get much more HAM than SPAM (I believe current industry standards report 80+% spam traffic), I simply c

Re: Strange SpamAssassin Statistical Performance

2005-02-25 Thread Jerome Cartagena
hello What makes you think this is a performance issue? The fact that you're getting more HAM than SPAM? or what? The main reason I believe this is a performance issue is the strange flat line that is demonstrated by the graph. Although it concerns me that I get much more HAM than SPAM (I belie

Re: Strange SpamAssassin Statistical Performance

2005-02-25 Thread Jerome Cartagena
Hello There are 86400 seconds in a 24-hour day, and if it takes you 10 seconds per message (high but possible with large number of remote tests) with just one process (unlikely) then you are going to be capped at 8,640 messages per day at flat-rate (nobody gets perfectly-distributed traffic patte

Re: Strange SpamAssassin Statistical Performance

2005-02-25 Thread Matt Kettler
At 01:43 PM 2/25/2005, Jerome Cartagena wrote: spam_clean_day: (5 min avg) Max spam: 1304.0 msgs Average spam: 489.0 msgsCurrent spam: 516.0 msgs Max clean: 7224.0 msgs Average clean: 1309.0 msgs Current clean: 1357.0 msgs Ok, that's better. I know what I'm looking at now. What ma

Re: Strange SpamAssassin Statistical Performance

2005-02-25 Thread Jerome Cartagena
Ok. Here are the graph details of SpamAssassin performance: <>spam_clean_day: (5 min avg) Max spam: 1304.0 msgs Average spam: 489.0 msgs Current spam: 516.0 msgs Max clean: 7224.0 msgs Average clean: 1309.0 msgs Current clean: 1357.0 msgs <> spam_clean_week: (30 min avg) Max spam: 2064.0 msgs A

Re: Strange SpamAssassin Statistical Performance

2005-02-25 Thread Eric A. Hall
On 2/25/2005 1:28 PM, Jerome Cartagena wrote: > problem/question is that according to our statistics we are reaching > some sort of upper bound on spam scanning performance. I have attached > 2 files to help demonstrate what I am talking about. I am wondering if > we are hitting some sort of

Re: Strange SpamAssassin Statistical Performance

2005-02-25 Thread Matt Kettler
At 01:28 PM 2/25/2005, Jerome Cartagena wrote: I am using spamassassin through MailScanner on a University mail server to help perform spam checks. I am using: SpamAssassin version 3.0.2 running on Perl version I have setup some scripts (spam-stats) to generate MRTG stats to help give us an i