Hi,
I'm also having exactly the same error after yum-updating to
spamassassin-3.3.1-3.el5.rf on CentOS 5.4 x86.
RPM details:
Name: spamassassin Relocations: (not relocatable)
Version : 3.3.1 Vendor: Dag Apt Repository,
Hi
Just found the solution: Run the command 'sa-update'
Note: Found the hint, after I tried to run spamd without '--daemonize'
Hope this works also for others!
Spamassassin List wrote:
Hi,
I followed the instruction in the download page to built my own rpm. All
went well. But when
On Wed, 2010-03-24 at 01:14 +0100, Jonas Eckerman wrote:
Not exactly that, but I have written a non-image-specific SA plugin that
can check for mismatches. It's a bit overkill if you only want to check
for mismatches for images though.
It uses the freedesktop file magic database to
On 3/23/2010 4:38 AM, Nigel Frankcom wrote:
On Tue, 23 Mar 2010 09:12:16 +, Nigel Frankcom
ni...@blue-canoe.com wrote:
Hi All,
Apologies if this has already been asked. A hunt through Google didn't
help much nor did any digging around the SA site. That's not to say
it's not there, just
Yes I'm using amavisd-new, this got me on the right track.
Thanks,
James
On Mar 23, 2010, at 7:39 PM, Mark Martinec wrote:
James,
I have a few emails from internal servers that got flagged as SPAM.
I added trusted_networks 10.10.10.0/24 to my local.cf so that emails from
those servers aren't
Had a nice HEART-STOPPING moment this morning! Logged in and
found my mailbox had no new mail! WTF!??
Checked the logs and discovered that my nightly automatic updates via YUM
had pulled in the new SA 3.3.1-3.
WARNING: Centos does NOT run the required sa-update to get all the files
On Wed, 24 Mar 2010, Charles Gregory wrote:
Had a nice HEART-STOPPING moment this morning! Logged in and
found my mailbox had no new mail! WTF!??
Checked the logs and discovered that my nightly automatic updates via YUM had
pulled in the new SA 3.3.1-3.
WARNING: Centos does NOT run
On Wed, Mar 24, 2010 at 12:17 PM, Charles Gregory cgreg...@hwcn.org wrote:
But if anyone is running CentOS and runs yum manually, be warned that SA
3.3.1 will come in on the next update and you will have to run sa-update
manually as soon as it is installed.
Upgraded today as show below and had
On Wed, 24 Mar 2010, R P Herrold wrote:
WARNING: Centos does NOT run the required sa-update to get all the files
into shape to run with the new SA engine! SA will ERROR.
rather: ... some third-party repository packagings, oriented to be used on
CentOS, do not ...
Correct.
My warning more
Hi,
Any one have any idea what might cause an increase of scan times when
going from 3.3 to 3.3.1.
I've upgraded one server and the average scan time is now 4.3 seconds.
The 3 other servers still running 3.3 average 1.38
All running Centos on exactly the same hardware.
Thanks in advance.
On 3/23/2010 2:49 PM the voices made Charles Gregory write:
On Tue, 23 Mar 2010, Alex wrote:
This is what I have:
/^[^a-z]{0,10}(http:\/\/|www\.)(\w+\.)+(com|net|org|biz|cn|ru)\/?[^
]{0,20}[a-z]{0,10}$/msi
My bad. I got an option wrong. Please remove the 'm' above.
I always get it backwards.
On 3/24/10 2:23 PM, Rick Macdougall wrote:
Hi,
Any one have any idea what might cause an increase of scan times when
going from 3.3 to 3.3.1.
I've upgraded one server and the average scan time is now 4.3 seconds.
The 3 other servers still running 3.3 average 1.38
several more RBL's,
Rick Macdougall wrote:
Any one have any idea what might cause an increase of scan times when
going from 3.3 to 3.3.1.
I've upgraded one server and the average scan time is now 4.3 seconds.
The 3 other servers still running 3.3 average 1.38
All running Centos on exactly the same hardware.
On 24/03/2010 2:40 PM, Michael Scheidell wrote:
On 3/24/10 2:23 PM, Rick Macdougall wrote:
Hi,
Any one have any idea what might cause an increase of scan times when
going from 3.3 to 3.3.1.
I've upgraded one server and the average scan time is now 4.3 seconds.
The 3 other servers still
On 24/03/2010 2:40 PM, Michael Scheidell wrote:
On 3/24/10 2:23 PM, Rick Macdougall wrote:
Hi,
Any one have any idea what might cause an increase of scan times when
going from 3.3 to 3.3.1.
I've upgraded one server and the average scan time is now 4.3 seconds.
The 3 other servers still
Michael Scheidell wrote:
several more RBL's,
check your dns performance?
Looks like the new PSBL DNSBL is a bit slow. I wonder if the new load
from SA 3.3 is the cause? g
A quick walk through the SA log shows it isn't helping much here, so
I've disabled it locally.
I checked out their
On 24/03/2010 4:09 PM, Kris Deugau wrote:
Michael Scheidell wrote:
several more RBL's,
check your dns performance?
Looks like the new PSBL DNSBL is a bit slow. I wonder if the new load
from SA 3.3 is the cause? g
A quick walk through the SA log shows it isn't helping much here, so
I've
On Wed, 2010-03-24 at 14:44 -0400, Kris Deugau wrote:
[...] that should save a little CPU time because I dropped the SARE
90_2tld channel for 3.3.x
The CPU time saved by dropping that file is negligible, hardly
measurable.
Anyway, it'll soon be deprecated in favor of 20_aux_tlds.cf, which is
Hi,
Anyway, it'll soon be deprecated in favor of 20_aux_tlds.cf, which is
part of the stock rule-set since 3.3.1. Bug 6361. As mentioned in the
release announcement.
Is the 20_aux_tlds.cf stable and available for use to replace it now?
Will the new RBLs in v3.3.1 ever be available/compatible
19 matches
Mail list logo
