Hello Hanspeter, Monday, November 15, 2004, 3:55:01 AM, you wrote:
HR> On Nov 14 at 21:28, Matt Kettler spoke: >> Defintiely custom. >> >> FVGT_TRIPWIRE_* are add-on rules, and are not a part of the standard SA set. >> TW_* are also add-on rules. In fact, I suspect they are a duplicate of the >> same ruleset, but with different names. >> LOCAL_OBFU generic is a local customization. And a heavy hitter at 1.8 >> points. >> SARE_HEAD_XBEEN is an add-on. >> >> The only "standard" rule in the list of hits is BAYES_00, a nonspam rule. HR> Ok, thanks for explaining. HR> If add-ons are added should the `required' level be increased in HR> order to prevent to much false positives? IMO: NO. 1) As Matt pointed out, you've duplicated your add-ons -- TW_* /is/ a later version of Tripwire, renamed to shorted the rule list in the email headers. The first step is to use add-ons correctly, without duplication, and using those add-ons which apply to your system without using those that don't. 2) Analyze why the emali was flagged. In addition to the rule duplication, it was flagged because it's not a "normal" email, but instead a technical email which has a lot of strange letter combinations, and it's specifically these strange letter combinations that Tripwire/TW checks for. If you expect to process a lot of these strange letter combination emails, then either a) find some way to bypass SpamAssassin for these emails (emails from technical lists), or don't use the Tripwire rules. Except for the duplication, the rules did what they're supposed to. Increase your threshold to allow for this strange effect (tripwire on technical email), and you'll let through lots of false negatives. Bob Menschel
