On Mon, 2010-11-01 at 23:05 +, RW wrote:
> On Mon, 01 Nov 2010 22:09:03 +
> Martin Gregorie wrote:
>
> > On Mon, 2010-11-01 at 21:15 +, RW wrote:
> > > I don't think it's a matter of locking-out updates - presumably
> > > token updates that occur after the start of a sync should go in
On Mon, 01 Nov 2010 22:09:03 +
Martin Gregorie wrote:
> On Mon, 2010-11-01 at 21:15 +, RW wrote:
> > I don't think it's a matter of locking-out updates - presumably
> > token updates that occur after the start of a sync should go into
> > the new journal file.
> >
> It may easily be a l
On Mon, 2010-11-01 at 21:15 +, RW wrote:
> I don't think it's a matter of locking-out updates - presumably
> token updates that occur after the start of a sync should go into the
> new journal file.
>
It may easily be a locking problem: To quote from the MySQL manual:
MySQL uses table-level
On Mon, 1 Nov 2010 10:28:43 -0400
Robert Blayzor wrote:
> Would it make more sense that when you do a learn_to_journal and a
> sync to make a copy of the bayes_toks database, say to
> "bayes_toks.new" and merge/add tokens from the journal to that?
> Then, once the sync is complete you can lock a
Great! -- thank you!
I appreciate all advice ... and will start reading
Thanks
Russ
Ned Slider wrote:
On 01/11/10 19:12, EACSI Support wrote:
That sound great!
We are using PostFix
Thank You
Russ
Ah, great.
Here's a couple guides I wrote for greylisting and postfix restricti
On 11/1/2010 3:10 PM, Ned Slider wrote:
> On 01/11/10 13:17, John Hardin wrote:
>> On Mon, 1 Nov 2010, Russ Sanders wrote:
>>
>>> Suggestions will be appreciated.
>>
>> You want to do things at SMTP time to reduce your email volume.
>>
>> Greylisting has been suggested; I see good results from it h
On 01/11/10 19:12, EACSI Support wrote:
That sound great!
We are using PostFix
Thank You
Russ
Ah, great.
Here's a couple guides I wrote for greylisting and postfix restrictions.
They are based on CentOS, but the principles are no different for Ubuntu.
http://wiki.centos.org/HowTos/post
That sounds great!
We are using PostFix ...
Thanks
Russ
Ned Slider wrote:
On 01/11/10 13:17, John Hardin wrote:
On Mon, 1 Nov 2010, Russ Sanders wrote:
Suggestions will be appreciated.
You want to do things at SMTP time to reduce your email volume.
Greylisting has been suggested; I s
That sound great!
We are using PostFix
Thank You
Russ
Ned Slider wrote:
On 01/11/10 13:17, John Hardin wrote:
On Mon, 1 Nov 2010, Russ Sanders wrote:
Suggestions will be appreciated.
You want to do things at SMTP time to reduce your email volume.
Greylisting has been suggested; I se
On 01/11/10 13:17, John Hardin wrote:
On Mon, 1 Nov 2010, Russ Sanders wrote:
Suggestions will be appreciated.
You want to do things at SMTP time to reduce your email volume.
Greylisting has been suggested; I see good results from it here.
Rejecting messages that do not have a FDQN in the H
EACSI Support wrote:
> The system commonly runs 2 to 3 connections to spamd with a maximum of
> 5, but when the email load gets high, it only seems to give two
> connections to spamd for the 1 user that is receiving the highest
> amount of eMail (8,000 per day).
>
> The problem is that the eMail
On 11/1/2010 2:26 PM, EACSI Support wrote:
>
> I read up on processing at SMTP time & GreyListing and it sounds
> effective.
If you are not already doing so, I would highly recommend using the
zen.spamhaus.org blacklist at the SMTP level. It will block a large
chunk of spam before SA even has to
NFN Smith wrote:
Lawrence @ Rogers wrote:
Are you running it against an e-mail with a known match? Using
spamassassin -D -t sample-spam.txt and having sample-spam.txt contain
the complete e-mail including headers?
Yes, it's a known match. I can take a full copy of a received message
(with h
I have had many helpful responses and I appreciate it.
Some simple answers :
The system is a "Linode 512" which is a virtual server hosted on a larger system
of which I don't have the true specifications. Howerver, it runs as a 4
CPU/Core system with 512M of memory.
I am looking at adding m
Theodoros V. Kalamatianos wrote:
> You keep mentioning SA throughput statistics, but you do not mention
> at all how your server fares load-wise. If your CPU(s) is(are) at 100%
> or your system is swapping a lot then simply raising the number of SA
> processes will not really help.
>
>> The syste
On Nov 1, 2010, at 1:54 PM, Michael Scheidell wrote:
> then you will probably always have delays.
Hence my suggestion for making copies of the database to be worked on during
the sync/expire process. Then there should be virtually no delay other than
lock/copy which should be virtually seconds
On 11/1/10 1:52 PM, Robert Blayzor wrote:
On Nov 1, 2010, at 10:38 AM, Michael Scheidell wrote:
Switch to the special mysql bayes. it will also allow you to expire based on
time (with some added table).
sync is dynamic but don't forget the cronjob to expire bayes daily.
Unfortunately mysql
On Mon, 1 Nov 2010, Russ Sanders wrote:
I have an Ubuntu Linux server running SpamAssassin Server version 3.2.4 running
on Perl 5.8.8 with zlib support (Compress::Zlib 2.008). I have at least one
account that is having to process from 250 - 400 emails, 99% spam, per HOUR.
This works out to be a
On 11/1/10 10:28 AM, Robert Blayzor wrote:
lock_method flock
Switch to the special mysql bayes. it will also allow you to expire
based on time (with some added table).
sync is dynamic but don't forget the cronjob to expire bayes daily.
--
Michael Scheidell, CTO
o: 561-999-50
For the past several months I have been trying to find a way to make
maintaining the SpamAssassin bayes database more effective on our SA servers.
We have several SA servers, all running bayes globally on the server, not per
user.
Bayes generally does a good job but on a fairly busy server ba
On 11/1/2010 12:59 AM, Russ Sanders wrote:
> I have an Ubuntu Linux server running SpamAssassin Server version 3.2.4
> running
> on Perl 5.8.8 with zlib support (Compress::Zlib 2.008). I have at least one
> account that is having to process from 250 - 400 emails, 99% spam, per HOUR.
> This works
On Mon, 1 Nov 2010, Russ Sanders wrote:
The system is a basic Linode running Ubuntu Linux 8.04 with 512M of memory.
Any way to add more RAM?
Suggestions will be appreciated.
You want to do things at SMTP time to reduce your email volume.
Greylisting has been suggested; I see good results
On Mon, 2010-11-01 at 04:59 +, Russ Sanders wrote:
> I have an Ubuntu Linux server running SpamAssassin Server version 3.2.4
> running
> on Perl 5.8.8 with zlib support (Compress::Zlib 2.008). I have at least one
> account that is having to process from 250 - 400 emails, 99% spam, per HOUR.
Russ Sanders wrote:
> I have an Ubuntu Linux server running SpamAssassin Server version
> 3.2.4 running on Perl 5.8.8 with zlib support (Compress::Zlib 2.008).
> I have at least one account that is having to process from 250 - 400
> emails, 99% spam, per HOUR. This works out to be approximately 8
24 matches
Mail list logo
