Pete
I thought the local gbudb got updates from the service or was that a future
enhancement?
Original message
Subject: [sniffer] Re: IP Change on rulebase delivery system
From: Richard Stupek rstu...@gmail.com javascript:_e({}, 'cvml',
'rstu...@gmail.com');
To: Message
On 2013-05-24 08:38, Richard Stupek wrote:
Pete
I thought the local gbudb got updates from the service or was that a
future enhancement?
That's true right now. GBUdb is part of a distributed machine learning
system. There is a conversation going on between all SNF nodes where
they share
@sortmonster.com
Subject: [sniffer] Re: IP Change on rulebase delivery system
Commtouch
Ryan Bair
Original message
Subject: [sniffer] Re: IP Change on rulebase delivery system
From: Richard Stupek rstu...@gmail.com
To: Message Sniffer Community sniffer@sortmonster.com
CC:
Can you
Looks like I have this issue again (pegging 4 core cpu) and resetting the
process doesn't make a difference. Not sure what is causing it but it does
slow down spam detection to 40-50 seconds for many emails. Any ideas what
I can look at or do to resolve this?
On Fri, Mar 29, 2013 at 12:27 PM,
I've been blocking subnets to the mail server manually for the past 10 days or
so. Scan the logs and look at common IP sources for spam. PITA but I've got
it under control. One of the earlier schemes I noticed was from .pw and .in
top level domains. What I'm seeing now are messages coming
On 2013-05-23 15:22, Richard Stupek wrote:
Looks like I have this issue again (pegging 4 core cpu) and resetting
the process doesn't make a difference. Not sure what is causing it
but it does slow down spam detection to 40-50 seconds for many emails.
Any ideas what I can look at or do to
Can you point me at the documentation for the truncate blacklist and its
usage?
On Thu, May 23, 2013 at 3:36 PM, Pete McNeil
madscient...@armresearch.comwrote:
On 2013-05-23 15:22, Richard Stupek wrote:
Looks like I have this issue again (pegging 4 core cpu) and resetting the
process
On 2013-05-23 16:41, Richard Stupek wrote:
Can you point me at the documentation for the truncate blacklist and
its usage?
http://gbudb.com/truncate/index.jsp
It's an ordinary ip4 dnsbl.
Most email systems have some mechanism for blocking connections based on
this kind of blacklist.
Hope
Would this:
http://armresearch.com/support/articles/software/snfServer/xci/gbudb.jsp yield
the same results as using the ip4 blocklist?
On Thu, May 23, 2013 at 4:11 PM, Pete McNeil
madscient...@armresearch.comwrote:
On 2013-05-23 16:41, Richard Stupek wrote:
Can you point me at the
On 2013-05-23 17:21, Richard Stupek wrote:
Would this:
http://armresearch.com/support/articles/software/snfServer/xci/gbudb.jsp yield
the same results as using the ip4 blocklist?
No. Asking your local GBUdb about an IP will only give you a local
perspective.
The truncate blacklist contains
.
*From:* Richard Stupek rstu...@gmail.com
*Sent:* Thursday, March 28, 2013 12:10 PM
*To:* Message Sniffer Community sniffer@sortmonster.com
*Subject:* [sniffer] Re: IP Change on rulebase delivery system
Ok looking at the log I see quite a few messages taking over a second to
process (samples
On 2013-03-29 12:59, Richard Stupek wrote:
well when all else fails restarting snf seems to have corrected the
issue for now.
In that case, it is likely that RAM fragmentation was involved. Dropping
the process allowed the fragmentation to be cleared. (theory).
Best,
_M
--
Pete McNeil
On 2013-03-28 12:10, Richard Stupek wrote:
Ok looking at the log I see quite a few messages taking over a second
to process (samples below):
s u='20130328155503' m=\temp\1332407477322.msg' s='0' r='0'
p s='1172' t='1109' l='72697' d='127'/
g o='0' i='12.130.136.172' t='u' c='0.486243'
with thousands of
files. We’ve also seen issues in the past with directories with a large
number of files being very poor performing.
Darin.
From: Richard Stupek
Sent: Thursday, March 28, 2013 12:10 PM
To: Message Sniffer Community
Subject: [sniffer] Re: IP Change on rulebase delivery system
Ok
Not sure if its related but since yesterday SNFserver CPU utilization has
been inordinately high (50%) for the middle of the day with not any
additional volume in mail being received.
On Mon, Mar 25, 2013 at 9:13 AM, Pete McNeil
madscient...@armresearch.comwrote:
Hi Sniffer Folks,
We are
Probably unrelated... and due to a significant increase in spam over the
past few days.
Darin.
From: Richard Stupek
Sent: Wednesday, March 27, 2013 2:18 PM
To: Message Sniffer Community
Subject: [sniffer] Re: IP Change on rulebase delivery system
Not sure if its related but since yesterday
On 2013-03-27 14:38, Darin Cox wrote:
Probably unrelated... and due to a significant increase in spam over
the past few days.
I agree with that -- our inbound spamtrap pre-processor has seen 4x
increase over the past few days so that's likely to be related.
Also, Richard, I took a quick
Its odd because the number of messags snf is processing isn't more than
usual and the % of spam being detected through snf is actually lower than
typical yet is is routinely maxing out 4 processors at 100%.
On Wed, Mar 27, 2013 at 3:20 PM, Pete McNeil
madscient...@armresearch.comwrote:
On
On 2013-03-27 16:49, Richard Stupek wrote:
Its odd because the number of messags snf is processing isn't more
than usual and the % of spam being detected through snf is actually
lower than typical yet is is routinely maxing out 4 processors at 100%.
You're saying that SNF is maxing out 4
It would be SNF routinely showing 80% utilization spikes for a 4 cpu
system. I hadn't ever seen it do that before which was why I sent the
message. Don't believe the load is any higher than normal. The spikes
aren't as prolonged at the present.
On Wed, Mar 27, 2013 at 4:08 PM, Pete McNeil
On 2013-03-27 17:16, Richard Stupek wrote:
The spikes aren't as prolonged at the present.
Interesting. A short spike like that might be expected if the message
was longer than usual, but on average SNF should be very light-weight.
One thing you can check is the performance data in your
21 matches
Mail list logo