Hello George, Wednesday, February 16, 2005, 7:02:58 AM, you wrote:
>>GG> I had custom scores for them but they seem gone now... >>They've been archived -- moved to the 70_sare_header_arc.cf file. GG> okay next time I'll look at raising my rule count rather than GG> raising scores to block spam. not sure what you mean by that. IMO if you like a rule, and you're confident it won't hit ham on your system (after testing it, and after reviewing our mass-check results), then increasing the score IS the correct way to make this adjustment. GG> I've not looked at what meta does, but I'll add this comment: My GG> local.cf file is parsed after all other cf files, so my first GG> thought is it's going to override anything set before it (as GG> intended). If you were to copy the rule to your local.cf, then yes, you'd override what we have or don't have. That's intentional, and why all SARE rules files are supposed to be prefixed with 7* -- to ensure that your local.cf does just that. However, if you have only a score in your local.cf, then what you override is our score, which would be set to 0. So if we have three lines in our 70_sare_header0.cf file: > meta rulename 0 # always false > describe rulename Archived Feb 2005 because it hit too much hame > score rulename 0 then a) if you have no overrides, our score 0 applies, and the rule is ignored. b) if you override the score, then our meta definition applies, the rule hits nothing, and there's no damage. c) if you override score and rule, your rule and score apply, and your description if any. GG> Rather than squelching custom site rules, I think it more GG> appropriate to verbosely report why rules become obsoleted (not GG> necessarily in the new ruleset). Maybe a changes file for each cf GG> file is appropriate? You cannot guarantee what or how anything is GG> done in a local config, let the admin who created it address the GG> changes too. The question then becomes, where to verbosely report these. Putting into the config file probably doesn't help, since if RDJ sees the --lint failure, it wipes out the config file that has the change report, and if RDJ doesn't see a --lint failure, then there's no reason for an admin to go looking for it. I'm open to suggestions. Bob Menschel
