spamassassin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Duncan Findlay <du...@debian.org>
Subject Re: PROPOSAL: create "SpamAssassin Rules Project"
Date Wed, 20 Jul 2005 04:41:48 GMT
On Tue, Jul 19, 2005 at 03:32:27PM -0700, Daniel Quinlan wrote:
> In other words, this solves the main part of our "rules problem" -- the
> hurdle of getting rules "over the wall".  No longer will we need
> individual bugs for rule submissions, or need to go to 3 different sites
> to look for rule ideas, etc.  Many of our best rules have come from SARE
> and the Wiki.  Also, it's expected that many of the rules will never go
> into the main rules body -- someone may write rules for a specific type
> of annoying mail (not even necessarily spam), or maybe someone will be
> focused on super-aggressive rules for the brave folks out there.  We can
> even produce multiple "output rule sets" in the long run: conservative,
> aggressive, sub-areas: bounces, drug rules, etc.
> 
> What's beyond the sandbox?  We can figure it out later.  I think the
> project will largely self-organize and Subversion makes it easy to move
> stuff around later.

SpamAssassin is not as effective as it could be because of the rules
that are being used to detect spam. There are two problems here:

 * The "not enough rules" problem: SpamAssassin does not have enough
high quality spam-catching rules. Anecdotally, our FN ratio seems to
be much higher with 3.1 than with 3.0 (we won't know for sure until
the mass-checks are done). There may be a variety of reasons for this:

   - The SpamAssassin committers are not spending much time writing
rules. Attempts to recruit people to become committers to write rules
have been somewhat unsuccessful. We could always use more committers
and contributors; what can we do to encourage more contribution?

   - People that do write rules for their own use are not willing to
go through the fairly elaborate process in order to submit them to
SpamAssassin (this currently requires rules to go through bugzilla and
then through 70_testing.cf and eventually into our distribution). What
can we do to make this process easier and more inviting?

 * The "release cycle" problem: Any high quality rules that are
incorporated into SpamAssassin are not distributed until the next
release. Since rules and code are tied together, the release cycle for
rules is too long. Submitted rules are not distributed while they are
most effective, and rules lose their effectiveness too quickly.


Am I missing anything?

The "release cycle" problem should be able to be solved by the
sa-update script that will be included with SpamAssassin 3.1.0. In
theory, we will be able to distribute rules more frequently, and rules
releases won't be tied to code releases.

I think the first point is the bigger one. Ultimately, Dan's sandbox
proposal may solve part of the "not enough rules" problem by making it
easier for people to contribute rules. But I'd like to hear from
potential rule submitters -- would this be a step in the right
direction? Is this something that you would be on board with? Would
you be more inclined to contribute rules?

Any project designed to increase participation from the community is
destined to fail if it is pushed through without hearing from the
community. So, I urge all the rule writers out there to please let us
know what you think!

Thanks,
-- 
Duncan Findlay

Mime
View raw message