Bug 5710 - config size sanity warnings.
Summary: config size sanity warnings.
Status: RESOLVED WONTFIX
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamassassin (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: Other other
: P5 enhancement
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-30 19:54 UTC by Matt Kettler
Modified: 2019-07-08 08:39 UTC (History)
1 user (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Kettler 2007-10-30 19:54:39 UTC 
As discussed over on sa-users I propose some basic sanity checks.
While these are currently intended to help novices realize that sa-blacklist is
detrimental to SA's health, I think implementing this as a general-purpose
feature is helpful in letting users know their configuration is "too large".

So I propose the following options, which cause the parser to generate warnings
only. The idea is to trigger warnings when the config is "probably absurd unless
you've got large hardware"

1) warn_conffile_maxsize  (speced in KB, default 1024)
   generates a warning if any single config file exceeds this size. Conf files
could be large, but 1MB is probably uncalled for.. 3.2.3 as shipped has 1 .cf
over 100k. My config has 7 over 100k when you count all the SARE stuff, but
neither has any over 200k

Others that might be useful:

2) warn_whiteblack_maxentries (speced in entries, default 8192) 
   generates a warning if the entries in whitelist_* or blacklist_* exceeds this
count. Anyone with more than 8k black/whitelists is probably doing a LOT wrong
on their system, not even considering the performance issues..

3) warn_conf_maxrerules  (speced in regex-based rules, default 32768)
   generates a warning if the number of body, rawbody, uri, full and header
rules exceeds this count. 

A crude grep shows SA 3.2.3 shipped with 1495 such rules (might be overstated, I
just grepped for "body ", etc..). My test box has a very large SARE contingent,
and that adds 3057 more rules for a total of 4552. Others might be larger, but
32k is probably absurd. meta rules are lightweight generally speaking, so
shouldn't be counted here, IMO..

Takers on these 3 options? A lot of folks liked the first one.. what about the
other two? (when it comes to it, please specify the scope of any votes ie: 1-3)
+1 or: 1) +1 2) 0 3) -1 )
Comment 1 Michael Parker 2007-10-30 20:04:35 UTC 
I'm thinking this sort of thing needs to be command line so that it can be in
affect when config parsing begins.
Comment 2 Matt Kettler 2007-10-30 20:58:32 UTC 
True, although it could also be done in a .pre file.. Although that might set a
bad precedent that you can stick config options in .pre files..

However, 2) and 3) could be implemented without such a need. Those warnings
could, and probably should, be generated after all the configfiles are parsed. 

But I do see your point that for 1) you want to generate the warning as the
files are read, and for that to happen, the setting needs to be in-place already.
Comment 3 Justin Mason 2007-10-31 04:23:03 UTC 
if it's in a /usr/share/spamassassin/10*.cf file, that'd work fine too;
alternatively (and IMO better) we can just keep counters, and defer actually
issuing the warnings until all of the system-wide config has been parsed.  That
way a later config (or /etc/mail/spamassassin file) can modify the levels
if they like.
Comment 4 Matt Kettler 2007-10-31 05:55:17 UTC 
Well, I don't think the 10_misc.cf thing is going to work. The setting has to
live somewhere persistent in order for upgrades to work, and 10_misc.cf isn't
persistent.

I also don't think counters would work for 1), unless you want to store an the
name every file parsed and its size. I think for 1) to really serve its purpose,
the warning should list off all the over-sized files. Unfortunately, that makes
configuring this one difficult.

However, I do think counters (or perhaps array sizes that already exist) are the
way to go for 2) and 3).
Comment 5 Henrik Krohns 2019-07-08 08:39:26 UTC 
I don't see any merit for this. If user decides to use million regexes, it will obviously slow things down and as a reason it's not hard to find. A warning will do nothing to stop the actual issue, and a fatal error will just break people's system if they have weird configurations. Closing.