You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Jim Smith <ma...@blarneystone.com> on 2006/03/15 14:52:45 UTC
AWL growing too large
I've got some clients with auto-whitelist files in their
/home/USER/.spamassassin directory that are over 20 megs. Is there a ceiling
to these AWL files and a way to adjust that ceiling? I think 20 megs is
rather large for clients with 25 meg limits. If it needs to be 20+ megs to
work well, I'll need to adjust everyone's email limits upward. I don't want
to remove it as it is an effective tool. Suggestions?
Thanks,
Jim Smith
Re: blacklist not working
Posted by mouss <us...@free.fr>.
seanmattingly@insightbb.com a écrit :
> Yeah, and how can I implement something like that when
> my host provides Cpanel?
>
> When you throw out those command lines, I'm afraid I
> don't know how/where to add those in. I do know how to
> manipulate Cpanel from a user's standpoint, but that's about it.
> All I'm after is to block emails based on their IP address or IP
> range.
>
if you mean reject these clients, then you'd better do at the MTA level
(I think cpanel uses exim). now you need to check where this exim gets
its config and tune it. so the question is for cpanel or exim
users/forums. If cpanel doesn't already provide this functionality, I'm
afraid you'll need to do that "by hand"....
Re: blacklist not working
Posted by se...@insightbb.com.
Yeah, and how can I implement something like that when
my host provides Cpanel?
When you throw out those command lines, I'm afraid I
don't know how/where to add those in. I do know how to
manipulate Cpanel from a user's standpoint, but that's about it.
All I'm after is to block emails based on their IP address or IP
range.
Thanks for all your help.
--
** Sean Mattingly (Sean@UltimateGTO.com)
** The Ultimate GTO Picture Site
** featuring Pontiac GTO cars 1964 - 2006.
** http://UltimateGTO.com
----- Original Message -----
From: "mouss" <us...@free.fr>
To: "Matt Kettler" <mk...@comcast.net>
Cc: <us...@spamassassin.apache.org>
Sent: Sunday, March 19, 2006 8:31 PM
Subject: Re: blacklist not working
> Matt Kettler a écrit :
> >>header RELAY_CN *X*-*Relay*-*Countries*=~/\bCN\b/
> >>describe RELAY_CN Relayed through china
> >>score RELAY_CN 1.0
> >>
> >>
> >>header RELAY_KR *X*-*Relay*-*Countries*=~/\bKR\b/
> >>describe RELAY_KR Relayed through Korea
> >>score RELAY_KR 1.0
> >>
> >
> >
> > Erk! How'd those *'es get in there.. Evil conversion from HTML bold-text
> > styles I guess..
>
> Thunderbug?
>
> What is the "cost" of the relay country plugin? is it just a lookup (db
> or dns) or does it do more?
>
>
Re: blacklist not working
Posted by mouss <us...@free.fr>.
Matt Kettler a écrit :
>>header RELAY_CN *X*-*Relay*-*Countries*=~/\bCN\b/
>>describe RELAY_CN Relayed through china
>>score RELAY_CN 1.0
>>
>>
>>header RELAY_KR *X*-*Relay*-*Countries*=~/\bKR\b/
>>describe RELAY_KR Relayed through Korea
>>score RELAY_KR 1.0
>>
>
>
> Erk! How'd those *'es get in there.. Evil conversion from HTML bold-text
> styles I guess..
Thunderbug?
What is the "cost" of the relay country plugin? is it just a lookup (db
or dns) or does it do more?
Re: blacklist not working
Posted by Matt Kettler <mk...@comcast.net>.
Matt Kettler wrote:
> seanmattingly@insightbb.com wrote:
>
>> Well, then how do I get SA to read the headers and exclude
>> some IP addresses? Surely there is a command for that - or a
>> box to fill out - or a custom config. I need something to exclude
>> all those bothersome emails from Japan, Nigeria, China, etc.
>>
>>
> The normal way to do this in SA would be to use the RelayCountry plugin,
> and add on rules that match the countries you want to tag.
>
> RelayCountry automatically identifies what countries the IP's in the
> received: path are from.
>
> Once RelayCountry is loaded you can just add rules with country codes:
>
> header RELAY_CN *X*-*Relay*-*Countries*=~/\bCN\b/
> describe RELAY_CN Relayed through china
> score RELAY_CN 1.0
>
>
> header RELAY_KR *X*-*Relay*-*Countries*=~/\bKR\b/
> describe RELAY_KR Relayed through Korea
> score RELAY_KR 1.0
>
Erk! How'd those *'es get in there.. Evil conversion from HTML bold-text
styles I guess..
Here they are corrected:
header RELAY_CN X-Relay-Countries=~/\bCN\b/
describe RELAY_CN Relayed through china
score RELAY_CN 1.0
header RELAY_KR X-Relay-Countries=~/\bKR\b/
describe RELAY_KR Relayed through Korea
score RELAY_KR 1.0
Re: blacklist not working
Posted by Theo Van Dinter <fe...@apache.org>.
On Sat, Mar 18, 2006 at 04:04:10AM -0500, Matt Kettler wrote:
> Admittedly it would be somewhat nice for SA to have this feature, but
> really you're 100% better off doing it at the MTA or firewall layer if
> you're going to do all the work of maintaining an IP address list.
FWIW, there is the AccessDB plugin.
--
Randomly Generated Tagline:
It is pitch black.
You have been eaten by a Grue.
Your score is 0 out of 400.
Re: blacklist not working
Posted by Matt Kettler <mk...@comcast.net>.
seanmattingly@insightbb.com wrote:
> Well, then how do I get SA to read the headers and exclude
> some IP addresses? Surely there is a command for that - or a
> box to fill out - or a custom config. I need something to exclude
> all those bothersome emails from Japan, Nigeria, China, etc.
>
The normal way to do this in SA would be to use the RelayCountry plugin,
and add on rules that match the countries you want to tag.
RelayCountry automatically identifies what countries the IP's in the
received: path are from.
Once RelayCountry is loaded you can just add rules with country codes:
header RELAY_CN *X*-*Relay*-*Countries*=~/\bCN\b/
describe RELAY_CN Relayed through china
score RELAY_CN 1.0
header RELAY_KR *X*-*Relay*-*Countries*=~/\bKR\b/
describe RELAY_KR Relayed through Korea
score RELAY_KR 1.0
If you want a long list of them, here's a post I made on the subject in
some archive (one I didn't even know existed)
http://www.nabble.com/Re%3A-What-countries-to-block--p1456069.html
> How to filter out emails from IP addresses and IP address ranges?
> Is there ANY program that will do it?
>
Any MTA has this built-in.. Firewalls work too.
Admittedly it would be somewhat nice for SA to have this feature, but
really you're 100% better off doing it at the MTA or firewall layer if
you're going to do all the work of maintaining an IP address list.
Re: blacklist not working
Posted by se...@insightbb.com.
Well, then how do I get SA to read the headers and exclude
some IP addresses? Surely there is a command for that - or a
box to fill out - or a custom config. I need something to exclude
all those bothersome emails from Japan, Nigeria, China, etc.
How to filter out emails from IP addresses and IP address ranges?
Is there ANY program that will do it?
Sean
> seanmattingly@insightbb.com wrote:
> > It's in the configuration screens. It's the second screen under cpanel.
> > Do you mean to say that I cannot enter an IP address into the
> > "blacklist_from" boxes?
> >
>
> No, because blacklist_from will blacklist email with matching text in the
From:
> header.
>
> The IP address won't appear in the From: header, unless they format their
email
> address that way.
>
Re: blacklist not working
Posted by Matt Kettler <mk...@evi-inc.com>.
seanmattingly@insightbb.com wrote:
> It's in the configuration screens. It's the second screen under cpanel.
> Do you mean to say that I cannot enter an IP address into the
> "blacklist_from" boxes?
>
No, because blacklist_from will blacklist email with matching text in the From:
header.
The IP address won't appear in the From: header, unless they format their email
address that way.
Re: blacklist not working
Posted by jdow <jd...@earthlink.net>.
It may be that the best shot is a custom rule for the particular header
item you want to catch, a "Received:" header I suspect.
header BAD_IP1 Received =~ /ip1\.ip2\.ip3\.ip4/
describe BAD_IP1 Another bad IP.
score BAD_IP1 20
That sort of a rule should do it. The describe line is entirely optional.
Stick these into a "blacklist.cf" file of your own in /etc/mail/spamassassin
or wherever good local ".cf" files go on your system.
{^_^}
----- Original Message -----
From: <se...@insightbb.com>
> It's in the configuration screens. It's the second screen under cpanel.
> Do you mean to say that I cannot enter an IP address into the
> "blacklist_from" boxes?
>
> --
> ** Sean Mattingly (Sean@UltimateGTO.com)
> ** The Ultimate GTO Picture Site
> ** featuring Pontiac GTO cars 1964 - 2006.
> ** http://UltimateGTO.com
>
> ----- Original Message -----
> From: "Matt Kettler" <mk...@evi-inc.com>
> To: <se...@insightbb.com>
> Cc: <us...@spamassassin.apache.org>
> Sent: Thursday, March 16, 2006 2:49 PM
> Subject: Re: blacklist not working
>
>
>> seanmattingly@insightbb.com wrote:
>> > I have configured SA on my hosting account through Cpanel.
>> > I've set up about 20 blacklist settings. It's supposed to blacklist
>> > according to certain IP addresses. Problem is - none of them are
>> > actually getting blocked! The spams are still streaming in by the
> dozens
>> > from China and elsewhere.
>>
>> Erm.. How'd you blacklist by IP address? SA doesn't have any support for
> that.
>>
>> >
>> > My hosting company seems to not know what to do. How can I guide
>> > the hosting company (Crucial Paradigm) into fixing their installation
>> > of SpamAssassin to make the IP blacklisting portion operational?
>> >
>>
>
Re: blacklist not working
Posted by se...@insightbb.com.
It's in the configuration screens. It's the second screen under cpanel.
Do you mean to say that I cannot enter an IP address into the
"blacklist_from" boxes?
--
** Sean Mattingly (Sean@UltimateGTO.com)
** The Ultimate GTO Picture Site
** featuring Pontiac GTO cars 1964 - 2006.
** http://UltimateGTO.com
----- Original Message -----
From: "Matt Kettler" <mk...@evi-inc.com>
To: <se...@insightbb.com>
Cc: <us...@spamassassin.apache.org>
Sent: Thursday, March 16, 2006 2:49 PM
Subject: Re: blacklist not working
> seanmattingly@insightbb.com wrote:
> > I have configured SA on my hosting account through Cpanel.
> > I've set up about 20 blacklist settings. It's supposed to blacklist
> > according to certain IP addresses. Problem is - none of them are
> > actually getting blocked! The spams are still streaming in by the
dozens
> > from China and elsewhere.
>
> Erm.. How'd you blacklist by IP address? SA doesn't have any support for
that.
>
> >
> > My hosting company seems to not know what to do. How can I guide
> > the hosting company (Crucial Paradigm) into fixing their installation
> > of SpamAssassin to make the IP blacklisting portion operational?
> >
>
Re: blacklist not working
Posted by Matt Kettler <mk...@evi-inc.com>.
seanmattingly@insightbb.com wrote:
> I have configured SA on my hosting account through Cpanel.
> I've set up about 20 blacklist settings. It's supposed to blacklist
> according to certain IP addresses. Problem is - none of them are
> actually getting blocked! The spams are still streaming in by the dozens
> from China and elsewhere.
Erm.. How'd you blacklist by IP address? SA doesn't have any support for that.
>
> My hosting company seems to not know what to do. How can I guide
> the hosting company (Crucial Paradigm) into fixing their installation
> of SpamAssassin to make the IP blacklisting portion operational?
>
blacklist not working
Posted by se...@insightbb.com.
I have configured SA on my hosting account through Cpanel.
I've set up about 20 blacklist settings. It's supposed to blacklist
according to certain IP addresses. Problem is - none of them are
actually getting blocked! The spams are still streaming in by the dozens
from China and elsewhere.
My hosting company seems to not know what to do. How can I guide
the hosting company (Crucial Paradigm) into fixing their installation
of SpamAssassin to make the IP blacklisting portion operational?
--
** Sean Mattingly (Sean@UltimateGTO.com)
** The Ultimate GTO Picture Site
** featuring Pontiac GTO cars 1964 - 2006.
** http://UltimateGTO.com
Re: AWL growing too large
Posted by Mark Martinec <Ma...@ijs.si>.
Michael,
> This line right here tells me that you are NOT using MySQL for you AWL db.
Oops, my bad. Bayes is on SQL, AWL is obviously not.
Still, is the complaint warranted or am I expecting too much
from a bdb-based awl?
Mark
Re: AWL growing too large
Posted by Michael Parker <pa...@pobox.com>.
Mark Martinec wrote:
> Matt Kettler wrote:
>> in the /tools directory of the tarball is a script called
>> "check_whitelist". If you run check-whitelist --clean, it will run
>> through the current user's AWL and purge any AWL entries which have only
>> been seen once.
>
> $ check_whitelist --clean
>
> Out of memory during request for 36 bytes, total sbrk() is 536625152 bytes!
> Out of memory during request for 48 bytes, total sbrk() is 536625152 bytes!
>
>
> $ spamassassin --remove-addr-from-whitelist=test@example.com
>
> [60198] warn: auto-whitelist: open of auto-whitelist file failed:
> Out of memory during ridiculously large request
> at /usr/local/lib/perl5/site_perl/5.8.8/Mail/SpamAssassin/DBBasedAddrList.pm
> line 171.
This line right here tells me that you are NOT using MySQL for you AWL db.
Michael
>
> The AWL database is on MySQL and it grew pretty large (still works fine).
> Once it gets large enough, it becomes impossible to remove
> anything from it by the supplied procedures. Perhaps a review
> of the removal/cleaning algorithm would be in order, one can't expect
> that the whole database would fit into the process' virtual memory
> on a site that keeps site-wide AWL database.
>
> I'm noticing this behaviour with at least 3.1.1 and 3.0.*, quite likely
> earlier too.
>
> Mark
>
Re: AWL growing too large
Posted by Mark Martinec <Ma...@ijs.si>.
Matt Kettler wrote:
> in the /tools directory of the tarball is a script called
> "check_whitelist". If you run check-whitelist --clean, it will run
> through the current user's AWL and purge any AWL entries which have only
> been seen once.
$ check_whitelist --clean
Out of memory during request for 36 bytes, total sbrk() is 536625152 bytes!
Out of memory during request for 48 bytes, total sbrk() is 536625152 bytes!
$ spamassassin --remove-addr-from-whitelist=test@example.com
[60198] warn: auto-whitelist: open of auto-whitelist file failed:
Out of memory during ridiculously large request
at /usr/local/lib/perl5/site_perl/5.8.8/Mail/SpamAssassin/DBBasedAddrList.pm
line 171.
The AWL database is on MySQL and it grew pretty large (still works fine).
Once it gets large enough, it becomes impossible to remove
anything from it by the supplied procedures. Perhaps a review
of the removal/cleaning algorithm would be in order, one can't expect
that the whole database would fit into the process' virtual memory
on a site that keeps site-wide AWL database.
I'm noticing this behaviour with at least 3.1.1 and 3.0.*, quite likely
earlier too.
Mark
Re: AWL growing too large
Posted by mouss <us...@free.fr>.
Michael W Cocke a écrit :
>
> You could never convince me to do that - the CPAN install facility is
> just too useful for me to do anything that would impede my using it!
> (Was that a sentence? it's too early here.)
>
> I install anything perl from either CPAN or source tarball, in that
> order. I've never gotten into a dual-install problem (if I understand
> your use of the term) that I couldn't straighten out fairly easily,
> and as a half-assed perl hacker I treat it as a learning experience.
>
what if you have two perl versions installed?
Re: AWL growing too large
Posted by Michael W Cocke <co...@catherders.com>.
On Wed, 15 Mar 2006 18:24:41 -0500, you wrote:
>jdow wrote:
>
>>
>> OK, when the storage structure of the tarball based package you want
>> changes how do you extirpate the old and insert the new without the
>> rather depressingly familiar dual SpamAssassin install? (Not that the
>> package systems like RPM always get it right. They do better than most
>> if you stick with the RPMs.)
>
>The "depressingly familiar dual install" for install-from-tarball users only
>comes about when you don't build the same way.
>
>i.e.: if you built with PREFIX=/usr one time, make sure you pass the same
>*every* time.
>
>I've been building from source tarball since SA 2.40 and I've never had a
>dual-install problem when installing this way.
>
>On the other hand back in 2.31 era I was using cpan, and I *did* get a dual
>install once. However that was CPAN deciding to install a whole new copy of perl
>to put SA into because the required perl version was screwed up.
>
>After that I ditched CPAN and went to pure tarball installs and have never
>regretted it.
You could never convince me to do that - the CPAN install facility is
just too useful for me to do anything that would impede my using it!
(Was that a sentence? it's too early here.)
I install anything perl from either CPAN or source tarball, in that
order. I've never gotten into a dual-install problem (if I understand
your use of the term) that I couldn't straighten out fairly easily,
and as a half-assed perl hacker I treat it as a learning experience.
Mike-
--
If you're not confused, you're not trying hard enough.
--
Please note - Due to the intense volume of spam, we have installed
site-wide spam filters at catherders.com. If email from you bounces,
try non-HTML, non-encoded, non-attachments,
Re: AWL growing too large
Posted by Nix <ni...@esperi.org.uk>.
On Sun, 19 Mar 2006, Matt Kettler stipulated:
> I'm just pointing out the only time I've had the dual-install problem was due to
> a CPAN install, not a source install.. And that was a LONG time ago.
I've had it on boxes with vendor trees of perl in strange places and
multiple simultaneously live copies of perl. Of course on any such box
you should tread carefully, but that doesn't stop certain vendors from
producing boxes that have perls you can't upgrade, or even multiple
perls at the very start, all with carefully buggered-up Config.pm's.
--
`Come now, you should know that whenever you plan the duration of your
unplanned downtime, you should add in padding for random management
freakouts.'
Re: AWL growing too large
Posted by Matt Kettler <mk...@evi-inc.com>.
Nix wrote:
> On Wed, 15 Mar 2006, Matt Kettler said:
>> On the other hand back in 2.31 era I was using cpan, and I *did* get a dual
>> install once. However that was CPAN deciding to install a whole new copy of perl
>> to put SA into because the required perl version was screwed up.
>
> Well, you'll be glad to know that that CPAN bug was fixed about four
> years ago. :)
>
True, of course, that didn't help me four years ago.. :)
I'm just pointing out the only time I've had the dual-install problem was due to
a CPAN install, not a source install.. And that was a LONG time ago.
Re: AWL growing too large
Posted by Nix <ni...@esperi.org.uk>.
On Wed, 15 Mar 2006, Matt Kettler said:
> On the other hand back in 2.31 era I was using cpan, and I *did* get a dual
> install once. However that was CPAN deciding to install a whole new copy of perl
> to put SA into because the required perl version was screwed up.
Well, you'll be glad to know that that CPAN bug was fixed about four
years ago. :)
--
`Come now, you should know that whenever you plan the duration of your
unplanned downtime, you should add in padding for random management
freakouts.'
Re: AWL growing too large
Posted by Matt Kettler <mk...@evi-inc.com>.
jdow wrote:
>
> OK, when the storage structure of the tarball based package you want
> changes how do you extirpate the old and insert the new without the
> rather depressingly familiar dual SpamAssassin install? (Not that the
> package systems like RPM always get it right. They do better than most
> if you stick with the RPMs.)
The "depressingly familiar dual install" for install-from-tarball users only
comes about when you don't build the same way.
i.e.: if you built with PREFIX=/usr one time, make sure you pass the same
*every* time.
I've been building from source tarball since SA 2.40 and I've never had a
dual-install problem when installing this way.
On the other hand back in 2.31 era I was using cpan, and I *did* get a dual
install once. However that was CPAN deciding to install a whole new copy of perl
to put SA into because the required perl version was screwed up.
After that I ditched CPAN and went to pure tarball installs and have never
regretted it.
Re: AWL growing too large
Posted by jdow <jd...@earthlink.net>.
From: "Matt Kettler" <mk...@evi-inc.com>
> mouss wrote:
>> Matt Kettler a écrit :
>>>
>>> AFAIK, *VERY* few distro packages contain anything from tools.
>>>
>>> That said, I personally wonder why anyone would use a distro package for
>>> something that updates are often time-sensitive. (ie: SpamAssassin, clamav, etc).
>>>
>>
>> While I try to avoid pre-packaged binaries, I prefer pre-packaged sources.
>>
>> some reasons:
>> - system specific options are already there (no need to tell the sw
>> where to install its files).
>> - to manage dependencies automatically (at least to avoid dll hell)
>> ...
>
> I agree there are some upsides to distro packages. However, there are downsides:
...
> I myself am completely turned off by distro packages of SA. They seem to hurt
> more often than they help compared to source-tarball installs. At least with the
> tarballs I know what's in them matches what Justin, Theo, Dan and the SA crew
> talk about. Sure you can check with your distro, but I like getting my support
> here and I like knowing I'm using a version that matches their code-base exactly.
OK, when the storage structure of the tarball based package you want
changes how do you extirpate the old and insert the new without the
rather depressingly familiar dual SpamAssassin install? (Not that the
package systems like RPM always get it right. They do better than most
if you stick with the RPMs.)
{^_^}
Re: AWL growing too large
Posted by Matt Kettler <mk...@evi-inc.com>.
mouss wrote:
> Matt Kettler a écrit :
>>
>> AFAIK, *VERY* few distro packages contain anything from tools.
>>
>> That said, I personally wonder why anyone would use a distro package for
>> something that updates are often time-sensitive. (ie: SpamAssassin, clamav, etc).
>>
>
> While I try to avoid pre-packaged binaries, I prefer pre-packaged sources.
>
> some reasons:
> - system specific options are already there (no need to tell the sw
> where to install its files).
> - to manage dependencies automatically (at least to avoid dll hell)
> ...
I agree there are some upsides to distro packages. However, there are downsides:
-You get the all the screw-ups the distro maintainer made because he didn't
understand the purpose of new files added to the package (ie: the addition of
init.pre caused a lot of distro maintainers to install this file in
/usr/share/spamassassin, or not at all)
-And all the "Extra features" they decided to bundle in, such as SARE rules they
liked but you might not...
-And all the "mixed version" issues because for some reason the distro
maintainer doesn't want to upgrade to the next minor rev and only backported the
security fixes, bypassing accuracy fixes that don't result in dependency changes.
-And miss out on utilities the distro maintainer decided he didn't want to include.
Admittedly some of those downsides have their own upsides, (ie: the extra
features might be ones you want..) but they're things to consider about packages.
I myself am completely turned off by distro packages of SA. They seem to hurt
more often than they help compared to source-tarball installs. At least with the
tarballs I know what's in them matches what Justin, Theo, Dan and the SA crew
talk about. Sure you can check with your distro, but I like getting my support
here and I like knowing I'm using a version that matches their code-base exactly.
Re: AWL growing too large
Posted by mouss <us...@free.fr>.
Matt Kettler a écrit :
>
>
> AFAIK, *VERY* few distro packages contain anything from tools.
>
> That said, I personally wonder why anyone would use a distro package for
> something that updates are often time-sensitive. (ie: SpamAssassin, clamav, etc).
>
While I try to avoid pre-packaged binaries, I prefer pre-packaged sources.
some reasons:
- system specific options are already there (no need to tell the sw
where to install its files).
- to manage dependencies automatically (at least to avoid dll hell)
...
> Last time clamav had a security fix it took Fedora several days to get a updated
> package out onto the yum mirrors. I'm glad my important boxes install from
> source tarball. They were upgraded within 2 hours of the clamav-announce message.
>
Though not very clean, one can "manually upgdate" (or should it be
"upgrate"?) pre-packaged sources.
Re: AWL growing too large
Posted by Matt Kettler <mk...@evi-inc.com>.
jdow wrote:
> From: "Matt Kettler" <mk...@comcast.net>
>
>> Jim Smith wrote:
>>> I've got some clients with auto-whitelist files in their
>>> /home/USER/.spamassassin directory that are over 20 megs. Is there a
>>> ceiling
>>> to these AWL files and a way to adjust that ceiling? I think 20 megs is
>>> rather large for clients with 25 meg limits. If it needs to be 20+
>>> megs to
>>> work well, I'll need to adjust everyone's email limits upward. I
>>> don't want
>>> to remove it as it is an effective tool. Suggestions?
>>
>> in the /tools directory of the tarball is a script called
>> "check_whitelist". If you run check-whitelist --clean, it will run
>> through the current user's AWL and purge any AWL entries which have only
>> been seen once.
>
> Of course, the last time I checked FedoraCore 4 SpamAssassin did NOT
> include the tools directory. Go figure. So he might have to go to the
> spamassassin ftp site to get the tar file and unpack it somewhere to
> get the tools.
AFAIK, *VERY* few distro packages contain anything from tools.
That said, I personally wonder why anyone would use a distro package for
something that updates are often time-sensitive. (ie: SpamAssassin, clamav, etc).
Last time clamav had a security fix it took Fedora several days to get a updated
package out onto the yum mirrors. I'm glad my important boxes install from
source tarball. They were upgraded within 2 hours of the clamav-announce message.
Re: AWL growing too large
Posted by jdow <jd...@earthlink.net>.
From: "Matt Kettler" <mk...@comcast.net>
> Jim Smith wrote:
>> I've got some clients with auto-whitelist files in their
>> /home/USER/.spamassassin directory that are over 20 megs. Is there a ceiling
>> to these AWL files and a way to adjust that ceiling? I think 20 megs is
>> rather large for clients with 25 meg limits. If it needs to be 20+ megs to
>> work well, I'll need to adjust everyone's email limits upward. I don't want
>> to remove it as it is an effective tool. Suggestions?
>
> in the /tools directory of the tarball is a script called
> "check_whitelist". If you run check-whitelist --clean, it will run
> through the current user's AWL and purge any AWL entries which have only
> been seen once.
Of course, the last time I checked FedoraCore 4 SpamAssassin did NOT
include the tools directory. Go figure. So he might have to go to the
spamassassin ftp site to get the tar file and unpack it somewhere to
get the tools.
{o.o}
Re: AWL growing too large
Posted by Matt Kettler <mk...@comcast.net>.
Jim Smith wrote:
> I've got some clients with auto-whitelist files in their
> /home/USER/.spamassassin directory that are over 20 megs. Is there a ceiling
> to these AWL files and a way to adjust that ceiling? I think 20 megs is
> rather large for clients with 25 meg limits. If it needs to be 20+ megs to
> work well, I'll need to adjust everyone's email limits upward. I don't want
> to remove it as it is an effective tool. Suggestions?
in the /tools directory of the tarball is a script called
"check_whitelist". If you run check-whitelist --clean, it will run
through the current user's AWL and purge any AWL entries which have only
been seen once.
RE: AWL growing too large
Posted by derringer <qu...@eastown.com>.
I'll post my reply here, since my question on manipulating the AWL hasn't
been responded to.
Basically, and forgive me for saying this, I am contemplating moving the AWL
database to mySQL is well, not only because of what has been mentioned here,
but also because the supplied tools to even modify the database are really,
really poor. You cannot, unless I have missed it, remove an 'address:IP'
pair from the database via the spamassassin supplied commandline options...
it simply either removes every entry for whatever 'address' you supply, or
it parses all email addresses out of an email (which is not what you want),
then removes every instance of them from all source IPs, or it adds 100 to
every single instance of that 'address' that you supply, and not necessarily
the address:IP 'pair' that you want.
Have I missed something? I mean, can you send spamassassin a parameter on
the commandline like"email@domain.com:X.X" so it removes a specific
instance, or is that unsupported?
The AWL lacks sufficient manipulation tools at this point in time, that it
really should have. As an administrator, I get emails that the AWL has
adjusted badly, and I want to fix that specific email address:IP pair, and I
simply can't do that with the current tools.
Any suggestions other than switching to MySQL and directly manipulating the
database?
--
View this message in context: http://www.nabble.com/AWL-growing-too-large-t1284694.html#a3506512
Sent from the SpamAssassin - Users forum at Nabble.com.