(I'm not sure if this subject has been discussed before, as i'm not following the list all the time)
How about separating the rules from the SpamAssassin distribution itself, and offer them as a separate package? This would be similar to the way intrusion detection systems (Snort, etc.) and antivirus applications work. It looks like there's a lot of similarities between SpamAssassin on one hand, and IDS and antivir. on the other. There's an engine performing the actual work, and a set of rules/signatures that are used to identify the bad stuff (malicious traffic, virus, spam). As long as some compatibility is maintained, these things can evolve separately. Especially in the case of the Snort IDS, this model seems to work pretty well. They offer the engine as a separate tarball/package, which is updated moderately often (just like any other piece of software). They also offer daily tarballs with updated sets of rules, both for the "stable" branch of their software, and for the "development" one. The rules are updated all the time, they have a mailing list dedicated to that, people contribute with new rules and/or updated ones, etc. This way, the developers can afford to let the engine go at its own pace, and update it only when it's really necessary, and yet offer a _very_ up-to-date intrusion detection tool to the users. I could be wrong, but it seems to me like the same thing might work for SpamAssassin as well. Just my 0.02$... -- Florin Andrei I updated my website: http://florin.myip.org/ ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
