You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Daniel J McDonald <da...@austinenergy.com> on 2007/10/26 14:35:13 UTC
Re: blacklist.cf needs to die (was Re: Help figuring our why SA is
taking like 1.5 minutes to filter...)
On Fri, 2007-10-26 at 08:16 -0400, Matt Kettler wrote:
> Justin Mason wrote:
> >
> > What else can we do?
> >
> Add code to generate a lint warning any time a .cf file over 1mb is read
> unless a config option is set to silence it?
But people don't read logs, or they would know... I'd suggest die-ing
instead.
>
> Possibly even have this as as:
> warn_conffile_maxsize (speced in KB, default 1024)
>
> Users that want to use absurdly large files can just raise the number..
+1
--
Daniel J McDonald, CCIE #2495, CISSP #78281, CNX
Austin Energy
http://www.austinenergy.com
Re: blacklist.cf needs to die (was Re: Help figuring our why SA is
taking like 1.5 minutes to filter...)
Posted by mouss <mo...@netoyen.net>.
Matt Kettler wrote:
> Daniel J McDonald wrote:
>
>> On Fri, 2007-10-26 at 08:16 -0400, Matt Kettler wrote:
>>
>>
>>> Justin Mason wrote:
>>>
>>>
>>>> What else can we do?
>>>>
>>>>
>>>>
>>> Add code to generate a lint warning any time a .cf file over 1mb is read
>>> unless a config option is set to silence it?
>>>
>>>
>> But people don't read logs, or they would know... I'd suggest die-ing
>> instead.
>>
>
> -1 on die-ing. There's no precedent for that in any of SA's existing
> behavior, even under the most severe config errors. This is largely done
> because it could screw over someones mail queue following an upgrade.
>
> And in this case, even if they read the logs, or ran a --lint, they
> wouldn't know anything other than "it's slow" and maybe "it eats memory
> like a hog". At least this way we can reach the ones that actually check
> the basics.
>
>
>
>
another example: machine reboots and for some reason, a new big file is
there. nobody to read logs.
I don't think there is now a need to have a general solution for large
files. the problem of the black*.cf can be solved by
- rename the file to something like READWARNINGINSIDEFILE-black*.cf
- create empty black*.cf
there's no reason to punish those who do efforts to listen to advice.
those who blindly download files with RDJ or other will notice that
their system is faster and that some spam may be missed. not a critical
issue.
Re: blacklist.cf needs to die (was Re: Help figuring our why SA
is taking like 1.5 minutes to filter...)
Posted by James Lay <jl...@slave-tothe-box.net>.
On 10/26/07 6:59 PM, "Matt Kettler" <mk...@verizon.net> wrote:
> Daniel J McDonald wrote:
>> On Fri, 2007-10-26 at 08:16 -0400, Matt Kettler wrote:
>>
>>> Justin Mason wrote:
>>>
>>>> What else can we do?
>>>>
>>>>
>>> Add code to generate a lint warning any time a .cf file over 1mb is read
>>> unless a config option is set to silence it?
>>>
>>
>> But people don't read logs, or they would know... I'd suggest die-ing
>> instead.
>
> -1 on die-ing. There's no precedent for that in any of SA's existing
> behavior, even under the most severe config errors. This is largely done
> because it could screw over someones mail queue following an upgrade.
>
> And in this case, even if they read the logs, or ran a --lint, they
> wouldn't know anything other than "it's slow" and maybe "it eats memory
> like a hog". At least this way we can reach the ones that actually check
> the basics.
>
For what it's worth: I stopped using blacklist.cf back around
2.1.3..haven't seen much of a difference with or without it....one of the
companies I work with has:
File messages : from Oct 1 00:01:37 to Oct 26 19:28:48
Total number of emails processed by the spam filter : 74552
Number of spams : 69518 ( 93.25%)
Number of clean messages : 5034 ( 6.75%)
Average message analysis time : 6.73 seconds
Average spam analysis time : 6.61 seconds
Average clean message analysis time : 8.29 seconds
Average message score : 21.62
Average spam score : 23.80
Average clean message score : -6.44
Total spam volume : 345 Mbytes
Total clean volume : 92 Mbytes
We are well pleased with SA without blacklist.cf :)
James
Re: blacklist.cf needs to die (was Re: Help figuring our why SA is
taking like 1.5 minutes to filter...)
Posted by Matt Kettler <mk...@verizon.net>.
Daniel J McDonald wrote:
> On Fri, 2007-10-26 at 08:16 -0400, Matt Kettler wrote:
>
>> Justin Mason wrote:
>>
>>> What else can we do?
>>>
>>>
>> Add code to generate a lint warning any time a .cf file over 1mb is read
>> unless a config option is set to silence it?
>>
>
> But people don't read logs, or they would know... I'd suggest die-ing
> instead.
-1 on die-ing. There's no precedent for that in any of SA's existing
behavior, even under the most severe config errors. This is largely done
because it could screw over someones mail queue following an upgrade.
And in this case, even if they read the logs, or ran a --lint, they
wouldn't know anything other than "it's slow" and maybe "it eats memory
like a hog". At least this way we can reach the ones that actually check
the basics.
Re: blacklist.cf needs to die (was Re: Help figuring our why SA is taking like 1.5 minutes to filter...)
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> > > But people don't read logs, or they would know... I'd suggest die-ing
> > > instead.
> On Fri, 26 Oct 2007, Duane Hill wrote:
> > Why not make it a configurable option in local.cf defaulting to
> > die. That way for those of us who create custom .cf files that
> > have the system resources can do so and not have to split them up
> > into more than one file.
On 26.10.07 09:43, John D. Hardin wrote:
> No, the size-to-die-at should be configurable, not whether you die or
> warn. If you *want* to support large custom config files, then up the
> limit.
...and some people would be surprised why is SA dying after they added one
line to their config file, instead of being a bit slower.
No, I don't think this is a good idea.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Boost your system's speed by 500% - DEL C:\WINDOWS\*.*
Re: blacklist.cf needs to die (was Re: Help figuring our why SA is
taking like 1.5 minutes to filter...)
Posted by "John D. Hardin" <jh...@impsec.org>.
On Fri, 26 Oct 2007, Nigel Frankcom wrote:
> On Fri, 26 Oct 2007 09:43:37 -0700 (PPT), "John D. Hardin"
> <jh...@impsec.org> wrote:
>
> >On Fri, 26 Oct 2007, Duane Hill wrote:
> >
> >> > But people don't read logs, or they would know... I'd suggest die-ing
> >> > instead.
> >>
> >> Why not make it a configurable option in local.cf defaulting to
> >> die. That way for those of us who create custom .cf files that
> >> have the system resources can do so and not have to split them up
> >> into more than one file.
> >
> >No, the size-to-die-at should be configurable, not whether you die or
> >warn. If you *want* to support large custom config files, then up the
> >limit.
>
> Perhaps a little more info about each rule would be helpful? I've
> ended up with mine through a variety of trial and error and list post
> comments and suggestions.
Huh? We're discussing adding a capability for limiting rules file
sizes, so that things like blacklist.cf can be made obviously painful.
This isn't about individual rules - though I suppose if you tried hard
enough you could write a 50kb RE...
Is that what you were commenting on?
Here's my topical comment: in addition to globally upping the limit,
perhaps an explicit per-filename size limit bypass as well?
CONFIG_FILE_SIZE_LIMIT 100kb
ACCEPT_LARGE_CONFIG_FILE generated_rules_01.cf
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
...the Fates notice those who buy chainsaws...
-- www.darwinawards.com
-----------------------------------------------------------------------
5 days until Halloween
Re: blacklist.cf needs to die (was Re: Help figuring our why SA is taking like 1.5 minutes to filter...)
Posted by Nigel Frankcom <ni...@blue-canoe.com>.
On Fri, 26 Oct 2007 09:43:37 -0700 (PPT), "John D. Hardin"
<jh...@impsec.org> wrote:
>On Fri, 26 Oct 2007, Duane Hill wrote:
>
>> > But people don't read logs, or they would know... I'd suggest die-ing
>> > instead.
>>
>> Why not make it a configurable option in local.cf defaulting to
>> die. That way for those of us who create custom .cf files that
>> have the system resources can do so and not have to split them up
>> into more than one file.
>
>No, the size-to-die-at should be configurable, not whether you die or
>warn. If you *want* to support large custom config files, then up the
>limit.
Perhaps a little more info about each rule would be helpful? I've
ended up with mine through a variety of trial and error and list post
comments and suggestions.
I run SA on a dedicated machine and it has had problems in the past,
though admittedly some of those could have been attributed to a
combination of remote DNS and remote MySQL. Still, some explanation
regarding the caveats (which _are_ included in some rules info) could
help the process some?
Just my 2p worth.
Kind regards
Nigel.
BTW - 5 days to Halloween and the little buggers are knocking my door
already - some things American should remain American! :-D
Re: blacklist.cf needs to die (was Re: Help figuring our why SA is
taking like 1.5 minutes to filter...)
Posted by Duane Hill <d....@yournetplus.com>.
On Fri, 26 Oct 2007 09:43:37 -0700 (PPT)
"John D. Hardin" <jh...@impsec.org> confabulated:
> On Fri, 26 Oct 2007, Duane Hill wrote:
>
> > > But people don't read logs, or they would know... I'd suggest
> > > die-ing instead.
> >
> > Why not make it a configurable option in local.cf defaulting to
> > die. That way for those of us who create custom .cf files that
> > have the system resources can do so and not have to split them up
> > into more than one file.
>
> No, the size-to-die-at should be configurable, not whether you die or
> warn. If you *want* to support large custom config files, then up the
> limit.
Yes. That would be better.
------
_|_
(_| |
Re: blacklist.cf needs to die (was Re: Help figuring our why SA is
taking like 1.5 minutes to filter...)
Posted by "John D. Hardin" <jh...@impsec.org>.
On Fri, 26 Oct 2007, Duane Hill wrote:
> > But people don't read logs, or they would know... I'd suggest die-ing
> > instead.
>
> Why not make it a configurable option in local.cf defaulting to
> die. That way for those of us who create custom .cf files that
> have the system resources can do so and not have to split them up
> into more than one file.
No, the size-to-die-at should be configurable, not whether you die or
warn. If you *want* to support large custom config files, then up the
limit.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
...the Fates notice those who buy chainsaws...
-- www.darwinawards.com
-----------------------------------------------------------------------
5 days until Halloween
Re: blacklist.cf needs to die (was Re: Help figuring our why SA is
taking like 1.5 minutes to filter...)
Posted by Duane Hill <d....@yournetplus.com>.
On Fri, 26 Oct 2007 07:35:13 -0500
Daniel J McDonald <da...@austinenergy.com> confabulated:
> On Fri, 2007-10-26 at 08:16 -0400, Matt Kettler wrote:
> > Justin Mason wrote:
> > >
> > > What else can we do?
> > >
> > Add code to generate a lint warning any time a .cf file over 1mb is
> > read unless a config option is set to silence it?
>
> But people don't read logs, or they would know... I'd suggest die-ing
> instead.
Why not make it a configurable option in local.cf defaulting to die.
That way for those of us who create custom .cf files that have the
system resources can do so and not have to split them up into more than
one file.
------
_|_
(_| |