> On Mon, 6 Sep 2010 13:20:56 +0200
> Matus UHLAR - fantomas wrote:
> > using clamav directly, without SA, is more effective. ClamAV plugin
> > seems to be OK for checking for things like phishes or strustured
> > data like credit card numbers, in which case it may cause false
> > positives.
On 0
On Tue, 2010-09-07 at 00:54 +0200, Karsten Bräckelmann wrote:
> On Mon, 2010-09-06 at 17:32 -0500, Chris wrote:
> > On Mon, 2010-09-06 at 17:03 +0200, Karsten Bräckelmann wrote:
>
> > > Unless the limit of 50k results in quite some spam ending up unprocessed
> > > by SA, I doubt this will help.
>
On Mon, 2010-09-06 at 17:32 -0500, Chris wrote:
> On Mon, 2010-09-06 at 17:03 +0200, Karsten Bräckelmann wrote:
> > Unless the limit of 50k results in quite some spam ending up unprocessed
> > by SA, I doubt this will help.
> >
> > Dropping large-ish third-party rule sets, if any, is much more li
On Mon, 2010-09-06 at 17:03 +0200, Karsten Bräckelmann wrote:
> On Sun, 2010-09-05 at 17:44 -0500, Chris wrote:
> > Thanks for the input John, I can accept 30 or 45 seconds of drive access
> > however when it comes to 300 I can't accept that. And you're absolutely
> > correct, the problem is my lac
On Mon, 2010-09-06 at 13:20 +0200, Matus UHLAR - fantomas wrote:
> >> On Mon, 06 Sep 2010 12:26:08 +0200
> >> Yet Another Ninja wrote:
>
> >>> You're using the SA ClamAV plugin which isn't the most effcient
> >>> method do do AV checks.
>
> > On 2010-09-06 12:49, RW wrote:
> >> What's wrong with
On Mon, 2010-09-06 at 13:14 +0200, Yet Another Ninja wrote:
> On 2010-09-06 12:49, RW wrote:
> > On Mon, 06 Sep 2010 12:26:08 +0200
> > Yet Another Ninja wrote:
> >
> >
> >> You're using the SA ClamAV plugin which isn't the most effcient
> >> method do do AV checks.
> >
> > What's wrong with it
On Mon, 2010-09-06 at 12:09 +0200, Bernd Petrovitsch wrote:
> On Son, 2010-09-05 at 17:44 -0500, Chris wrote:
> > On Sun, 2010-09-05 at 12:54 -0700, John Hardin wrote:
> > > On Sun, 5 Sep 2010, Chris wrote:
> > >
> > > > On Sun, 2010-09-05 at 12:33 -0500, Len Conrad wrote:
> > > >>> Mem:772880
On Mon, 06 Sep 2010 17:03:02 +0200
Karsten Bräckelmann wrote:
> Since you mentioned procmail, your spamc calling recipe is *with*
> locking, right? Limiting concurrent SA processes pretty much to one as
> far as filtering is concerned.
And start spamd with --max-children=1. That not only free
On Sun, 2010-09-05 at 17:44 -0500, Chris wrote:
> Thanks for the input John, I can accept 30 or 45 seconds of drive access
> however when it comes to 300 I can't accept that. And you're absolutely
> correct, the problem is my lack of memory I realize that now.
> Just one user, me, though I alread
On Mon, 6 Sep 2010 13:20:56 +0200
Matus UHLAR - fantomas wrote:
> using clamav directly, without SA, is more effective. ClamAV plugin
> seems to be OK for checking for things like phishes or strustured
> data like credit card numbers, in which case it may cause false
> positives.
I don't see wh
On Mon, 6 Sep 2010, Martin Gregorie wrote:
On Sun, 2010-09-05 at 14:55 -0500, Chris wrote:
On Sun, 2010-09-05 at 20:02 +0200, Karsten Bräckelmann wrote:
On Sat, 2010-09-04 at 08:42 -0500, Chris wrote:
I'm trying to figure out why I'm having ridiculous scan times such as
the above examples. Lo
>> On Mon, 06 Sep 2010 12:26:08 +0200
>> Yet Another Ninja wrote:
>>> You're using the SA ClamAV plugin which isn't the most effcient
>>> method do do AV checks.
> On 2010-09-06 12:49, RW wrote:
>> What's wrong with it?
On 06.09.10 13:14, Yet Another Ninja wrote:
> nothing "wrong" but my first
On 2010-09-06 12:49, RW wrote:
On Mon, 06 Sep 2010 12:26:08 +0200
Yet Another Ninja wrote:
You're using the SA ClamAV plugin which isn't the most effcient
method do do AV checks.
What's wrong with it?
nothing "wrong" but my first choice would be to reject infected files at
MTA level (via
On Mon, 06 Sep 2010 12:26:08 +0200
Yet Another Ninja wrote:
> You're using the SA ClamAV plugin which isn't the most effcient
> method do do AV checks.
What's wrong with it?
On 2010-09-05 0:00, Chris wrote:
On Sat, 2010-09-04 at 08:42 -0500, Chris wrote:
I'm trying to figure out why I'm having ridiculous scan times such as
the above examples. Lower scan times such as in the 20 second range are
the exception rather than the rule. I'm running bind as a local caching
n
On Sun, 2010-09-05 at 14:55 -0500, Chris wrote:
> On Sun, 2010-09-05 at 20:02 +0200, Karsten Bräckelmann wrote:
> > On Sat, 2010-09-04 at 08:42 -0500, Chris wrote:
> > > I'm trying to figure out why I'm having ridiculous scan times such as
> > > the above examples. Lower scan times such as in the 2
On Son, 2010-09-05 at 17:44 -0500, Chris wrote:
> On Sun, 2010-09-05 at 12:54 -0700, John Hardin wrote:
> > On Sun, 5 Sep 2010, Chris wrote:
> >
> > > On Sun, 2010-09-05 at 12:33 -0500, Len Conrad wrote:
> > >>> Mem:772880k total, 685316k used,87564k free,31344k buffers
> > >>> Swap:
On Sun, 2010-09-05 at 12:54 -0700, John Hardin wrote:
> On Sun, 5 Sep 2010, Chris wrote:
>
> > On Sun, 2010-09-05 at 12:33 -0500, Len Conrad wrote:
> >>> Mem:772880k total, 685316k used,87564k free,31344k buffers
> >>> Swap: 1076312k total, 249032k used, 827280k free, 156328k
On Sun, 2010-09-05 at 20:02 +0200, Karsten Bräckelmann wrote:
> On Sat, 2010-09-04 at 08:42 -0500, Chris wrote:
> > I'm trying to figure out why I'm having ridiculous scan times such as
> > the above examples. Lower scan times such as in the 20 second range are
> > the exception rather than the rul
On Sun, 5 Sep 2010, Chris wrote:
On Sun, 2010-09-05 at 12:33 -0500, Len Conrad wrote:
Mem:772880k total, 685316k used,87564k free,31344k buffers
Swap: 1076312k total, 249032k used, 827280k free, 156328k cached
250MB swapped, for less than 1 GB RAM, used is disastrous for
On Sat, 2010-09-04 at 08:42 -0500, Chris wrote:
> I'm trying to figure out why I'm having ridiculous scan times such as
> the above examples. Lower scan times such as in the 20 second range are
> the exception rather than the rule. I'm running bind as a local caching
Do you use the URICountry plug
On Sun, 2010-09-05 at 12:33 -0500, Len Conrad wrote:
> >Mem:772880k total, 685316k used,87564k free,31344k buffers
> >Swap: 1076312k total, 249032k used, 827280k free, 156328k cached
>
> 250MB swapped, for less than 1 GB RAM, used is disastrous for an MTA.
>
> Increase RAM
>Mem:772880k total, 685316k used,87564k free,31344k buffers
>Swap: 1076312k total, 249032k used, 827280k free, 156328k cached
250MB swapped, for less than 1 GB RAM, used is disastrous for an MTA.
Increase RAM to 2GB, or until swap is always "0k used"
Len
On Sun, 2010-09-05 at 09:18 -0700, John Hardin wrote:
> On Sat, 4 Sep 2010, Chris wrote:
>
> > Running an X session, and I noticed that this is back:
>
> How much memory in that box?
>
754Mb and 1Gb swap, top shows
top - 12:16:19 up 51 days, 16:18, 2 users, load average: 0.31, 0.37,
0.65
Tas
On Sat, 4 Sep 2010, Chris wrote:
Running an X session, and I noticed that this is back:
How much memory in that box?
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6
On Sun, 2010-09-05 at 07:35 -0500, Shane Williams wrote:
> In several places, Justin Mason has said the sysread debug line
> doesn't necessarily indicate an error (he actually says they're
> normal in debug mode), though these are fairly old posts.
>
> http://www.mail-archive.com/users@spamassassi
In several places, Justin Mason has said the sysread debug line
doesn't necessarily indicate an error (he actually says they're
normal in debug mode), though these are fairly old posts.
http://www.mail-archive.com/users@spamassassin.apache.org/msg31175.html
http://mail-archives.apache.org/mod_mbo
Plus; parallel scans give a clue too. Next time compare one session
vs. 2 or more sessions . If both times are nearly equal then it's not
related
to cpu usage or any other machine related bottleneck, coz probably SA waits
for something -then timeout occurs? -
On Sun, Sep 5, 2010 at 3:55 AM, John
On Sat, 2010-09-04 at 17:55 -0700, John Hardin wrote:
> On Sat, 4 Sep 2010, Chris wrote:
>
> > On Sat, 2010-09-04 at 14:33 -0700, John Hardin wrote:
> >> On Sat, 4 Sep 2010, Chris wrote:
> >>
> >>> I'm trying to figure out why I'm having ridiculous scan times such as
> >>> the above examples. Low
On Sat, 4 Sep 2010, Chris wrote:
On Sat, 2010-09-04 at 14:33 -0700, John Hardin wrote:
On Sat, 4 Sep 2010, Chris wrote:
I'm trying to figure out why I'm having ridiculous scan times such as
the above examples. Lower scan times such as in the 20 second range are
the exception rather than the r
On Sat, 2010-09-04 at 17:00 -0500, Chris wrote:
> On Sat, 2010-09-04 at 08:42 -0500, Chris wrote:
> > I'm trying to figure out why I'm having ridiculous scan times such as
> > the above examples. Lower scan times such as in the 20 second range are
> > the exception rather than the rule. I'm running
On Sat, 2010-09-04 at 14:33 -0700, John Hardin wrote:
> On Sat, 4 Sep 2010, Chris wrote:
>
> > I'm trying to figure out why I'm having ridiculous scan times such as
> > the above examples. Lower scan times such as in the 20 second range are
> > the exception rather than the rule. I'm running bind
Hi,
On Sun, Sep 5, 2010 at 12:00 AM, Chris wrote:
> On Sat, 2010-09-04 at 08:42 -0500, Chris wrote:
> I've started SA now with -D
>
> OPTIONS="-d -D -c -H -m 4 --max-conn-per-child=3 --min-children=1"
>
> While looking at my syslog I noticed the following:
>
> Sep 4 16:21:46 localhost spamd[157
On Sat, 2010-09-04 at 08:42 -0500, Chris wrote:
> I'm trying to figure out why I'm having ridiculous scan times such as
> the above examples. Lower scan times such as in the 20 second range are
> the exception rather than the rule. I'm running bind as a local caching
> nameserver and it seems to be
On Sat, 4 Sep 2010, Chris wrote:
I'm trying to figure out why I'm having ridiculous scan times such as
the above examples. Lower scan times such as in the 20 second range are
the exception rather than the rule. I'm running bind as a local caching
nameserver and it seems to be working correctly.
On Sat, 4 Sep 2010, Emin Akbulut wrote:
If cpu usage is normal then it's related to DNS or
online things, it maybe wait for communication...
I think the -L parameter disables online checks.
Just try without online checks. Also use -D for debug.
Another posibility for delay would be waiting fo
If cpu usage is normal then it's related to DNS or
online things, it maybe wait for communication...
I think the -L parameter disables online checks.
Just try without online checks. Also use -D for debug.
On Sat, Sep 4, 2010 at 7:25 PM, Michael Scheidell <
michael.scheid...@secnap.com> wrote:
On 9/4/10 9:42 AM, Chris wrote:
I'm trying to figure out why I'm having ridiculous scan times such as
the above examples. Lower scan times such as in the 20 second range are
the exception rather than the rule. I'm running bind as a local caching
nameserver and it seems to be working correctly. I
I'm trying to figure out why I'm having ridiculous scan times such as
the above examples. Lower scan times such as in the 20 second range are
the exception rather than the rule. I'm running bind as a local caching
nameserver and it seems to be working correctly. I've just seen a ham
that has a scan
39 matches
Mail list logo
