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
