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/compatib
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
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?
A quick walk through the SA log shows it isn't helping much here, so
I've disable
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?
A quick walk through the SA log shows it isn't helping much here, so
I've disabled it locally.
I checked out their rs
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 runn
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 runn
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.
(I
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,
chec
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. A
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.
R
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 spe
On Wed, Mar 24, 2010 at 12:17 PM, Charles Gregory 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 no issues what
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 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
in
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 che
On 3/23/2010 4:38 AM, Nigel Frankcom wrote:
On Tue, 23 Mar 2010 09:12:16 +, Nigel Frankcom
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 that I can't find it :
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 rec
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 w
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,
http://dag.wieers.co
19 matches
Mail list logo
