On ons 14 apr 2010 23:28:38 CEST, John Hardin wrote
Please do not post spammy mail to the list (it poisons our Bayes
with spammy tokens with hammy score).
If you're running SA list emails through SA you deserve what you get. :)
for sa 3.3.2 bayes_ignore_on_dkim_valid ? :)
bayes_ignore_to
Hi,
We had a legitimate e-mail hit the JM_SOUGHT_3 yesterday. It also
hit a few other rules that pushed it over our reject threshold of
10, and easily over the 'junk mail folder' level of 5.
I managed to get them to send me the message, and it hits rule
__SEEK_5ID3LI Conti nuum Intern ational
On Fri, 2010-04-16 at 12:20 +0100, Matthew Newton wrote:
We had a legitimate e-mail hit the JM_SOUGHT_3 yesterday. It also
hit a few other rules that pushed it over our reject threshold of
10, and easily over the 'junk mail folder' level of 5.
I managed to get them to send me the message,
Micah Anderson wrote:
This is version '1.2.74-4' from Debian... but now looking closer, it
seems as if dcc was removed after Debian Etch. It seems that it was
removed because the upstream authors changed its license to non-free
(according to Debian's DFSG) in version 1.30. This also means that
yep -- feel free to send me over copies of FP messages (or strings
that match them)
2010/4/16 Karsten Bräckelmann guent...@rudersport.de:
On Fri, 2010-04-16 at 12:20 +0100, Matthew Newton wrote:
We had a legitimate e-mail hit the JM_SOUGHT_3 yesterday. It also
hit a few other rules that pushed
On Fri, 16 Apr 2010, Benny Pedersen wrote:
On ons 14 apr 2010 23:28:38 CEST, John Hardin wrote
Please do not post spammy mail to the list (it poisons our Bayes with
spammy tokens with hammy score).
If you're running SA list emails through SA you deserve what you get. :)
for sa 3.3.2
On 4/15/10 5:35 PM, Micah Anderson wrote:
M
The Distributed Checksum Clearinghouse source carries a license that is
free to organizations that do not sell filtering devices or services
except to their own users and that participate in the global DCC
network. . . you may not redistribute
Hi,
On Fri, Apr 16, 2010 at 01:53:55PM +0200, Karsten Bräckelmann wrote:
On Fri, 2010-04-16 at 12:20 +0100, Matthew Newton wrote:
We had a legitimate e-mail hit the JM_SOUGHT_3 yesterday. It also
hit a few other rules that pushed it over our reject threshold of
10, and easily over the
I have a need to run several different instances of SA on a single box (in
development). In production, we have 3 different SA environments (with 2+
servers each) that have different rule sets and specific routing rules
determine which instance it gets sent to. We need to mimic this in
On Fri, 2010-04-16 at 10:08 -0700, Gary Smith wrote:
I have a need to run several different instances of SA on a single box (in
development). In production, we have 3 different SA environments (with 2+
servers each) that have different rule sets and specific routing rules
determine which
I'm sure it's possible, but rather than going through all the work of
trying to script and setup chroot environments, why not use VMs? You
can then quite literally match the production setup.
Since you are not worried about performance or memory you could give
each VM 128 MB of RAM and
Background:
I've been using SA for a long time, and for a verity of reasons, we run
different servers to support some minor changes in different rules. While
trying to setup a multi instance version on my laptop, I copied these rules
over into different directories, setup the startup/shutdown
Gary Smith wrote:
Instead of running multiple SA servers, it is possible to run a single
consolidated SA server where only the userpref's are different for each spamc
caller (given that the local config will override the global config) AND still
use a single bayes DB? We use a clustered
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kris Deugau wrote:
Gary Smith wrote:
Instead of running multiple SA servers, it is possible to run a single
consolidated SA server where only the userpref's are different for each
spamc caller (given that the local config will override the global
Why don't you just run 3 instances of spamd, each listening on different
ports/sockets and each with their own configuration:
spamd --siteconfigpath=/etc/spam1 --socketpath=/tmp/spam1.sock --port=783
spamd --siteconfigpath=/etc/spam2 --socketpath=/tmp/spam2.sock --port=784
spamd
Gary Smith wrote:
Bayes is the only real concern here, as I know I can run multiple copies (and had forgot that I could run a single copy with user_prefs). So I think this will work either way. I just needed to put a little thought into it and
bounce off of people who might have already done
If you're just trying to keep your Bayes table from exploding due to
multiple users, use the bayes_sql_override_username option.
I'm not worried about it exploding as we don't allow user_prefs. The machines
are processed via relays. I believe the bayes_sql_override_username will solve
the
Gary Smith wrote:
I'm not worried about it exploding as we don't allow user_prefs. The machines are processed via relays. I believe the bayes_sql_override_username will solve the last piece of the puzzle. I think I will test this out this weekend on the laptop, then our test environment.
Hi SpamAssassin folks!
I am currently looking for “corporate style” or “enterprise class”
Perl use-cases; and strangely it's quite difficult to find a central
resource for that.
Usually this is supported by running applications that are so
important and used in a very heavy environment that the
19 matches
Mail list logo
