-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Robert Menschel writes: >.... >And then, there's a whole universe of rules which are not included in >SA's distribution rule set, and which should NOT be included in SA's >distribution rule set. An example from my 70_sare_genlsubj3.cf: ># OVERALL% SPAM% HAM% S/O RANK SCORE NAME ># 2.674 3.1530 0.5427 0.853 0.61 0.50 SARE_SUB_ONLINE >This rule hits 3% of all spam here, but also 0.5% of ham, and so its S/O >is too low to warrant inclusion in the distribution set at this time. >It's not a rule that would be appropriate for all or possibly most >systems. But those that can be a little more aggressive can benefit from >this rule. This is one type of rule that I see has a permanent home in >SARE. Yep, I think you're right. There will always be some that are not quite at the threshold we require for the "core" ruleset, or may have some other reason they wouldn't be appropriate for that. However if it would be possible to get the rules that would be *useful* to have in the default ruleset, into that set, that should be a goal IMO. (There's quite a few of those, I'd think.) I think that the SARE ruleset is probably the best "first deployment" area for rules -- but I also think that getting some of those rules into the SpamAssassin distro would be nice ;) >..... >>> - SpamAssassin is not being well-maintained to integrate these rules >>> efficiently and with low overlap, so speed and efficiency suffer. >I'm not sure what you mean here. The huge majority of rules we develop >are extremely simple, phrases or variations on phrases, easily tested by >regex, and not the sort of thing I'd expect to require any tuning you >haven't already done. > >The exceptions would be rulesets like backhair, weeks, tripwire, where >I expect we'd be better off with well built eval capabilities rather than >multiple regexes, but we don't have the ability (yet) to create those >eval capabilities (or equivalent). 3.0.0 will be useful then ;) I think Dan's talking about just this. Multiple regexes just won't be as high-performance as a well-written eval test in these kinds of cases. >>>I'm not saying that I want SARE to go away! SARE does a better job >>>tracking new rule sets than was possible before, but we need to avoid >>>falling to a non-optimal pattern of where effort is going. Developers >>>come and go and we've maintained a strong core team for the Perl code >>>in SpamAssassin, but the number of people actively working on rules is >>>lower now (since January, about 2/3 of SA 3.0 test rule work is the >>>work of one person, 94% is two people). > >Actually, part of the reason SARE is growing and strengthening is because >during the development of version 3.0 the core developers needed to >concentrate on code changes and not so much on rules. There was even a >comment to that effect on one or both lists a few months ago. > >Justin posted a request for rules volunteers a couple of months back, and >I was real tempted to step up for that, but just don't have the time. >Anti-spam is a sideline for me, and my primary activities demand that I >don't put any more time into SA than I already do. Hopefully one or two >others in SARE who can call this part of their actual job (or who have >more spare time than I do) can step forward. I hope so too ;) >..... >>>and the big one: >>> >>> - Shift from using maintenance releases for rule updates to automated >>> official rule updates for stable SpamAssassin releases (think: cron >>> job that you can trust). >If I understand what you're saying here, this would improve the quality >of the rules, and would also slow down the release of rule updates. I >think there's a place for the quick supply of rules which aren't quite GA >quality, but have been tested through multiple corpi and are reasonably >scored. Yes, I would like to see our best rules folded into formal SA >releases (and we're developing naming conventions for rules and files to >try to support this), but we need to maintain the ability to add rules >quickly to that section of the user community that wants them. This is true. hmm. >>> - There are a number of killer rules in SA 3.0 SVN that have been >>> through extensive QA and would require minimum development to test. >>> Those could have been deployed in general-release quality for 2.6x, >>> I'd like to see something set up now for 3.0 SVN. >This can work both ways. Not only can we feed the best rules to SVN, but >those rules within SVN which don't require new code can be released >through SARE, making them available to those who run 2.6x or 2.5x. I'd >like to see this happen. yep! >What we really need is someone who can work through the current SVN >rules, compare them to our better SARE rules, and submit those that >are worth while but not yet in the SVN queue. Again, I don't have the >time for this. Hopefully someone else will. /me crosses fingers ;) - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Exmh CVS iD8DBQFAlv7zQTcbUG5Y7woRAiaqAJ91E7NUK5XK7Ts2Imwyq0xSy+HzEwCdEC2K 2t6nP3NMcGbyYJd2yNQp9OU= =s9h9 -----END PGP SIGNATURE-----
