Spammers catching on

[Zack Brown]

On Tue, Dec 17, 2002 at 10:47:29PM -0500, Gyepi SAM wrote:
> On Tue, Dec 17, 2002 at 12:51:24PM -0800, Zack Brown wrote:
> > On Tue, Dec 17, 2002 at 03:45:35PM -0500, Gyepi SAM wrote:
> > > On Tue, Dec 17, 2002 at 12:36:09PM -0700, Matt Armstrong wrote:
> 
> > > I would, however, be interested in a pre-processing tool that could determine
> > > that the two colors are the same and add the information to the email.
> > > Essentially the tool would analyze the message for certain properties,
> > > perhaps based on SpamAssassin (like) rules and encode the results
> > > as tokens in the message itself, perhaps in the header. Note that we would not be using
> > > SpamAssassin scores here, just names of possible spammy properties.
> > 
> > Why avoid spamassassin? If you need a wheel, use a wheel, right? If
> > spamassassin can be modified to be of more use to bogofilter, without
> > degrading its performance in other ways, I'm sure the spamassassin folks
> > would take patches.
> 
> SpamAssassin has a long list of requirements that makes
> installation an interesting exercise for some and a daunting task for others.
> Furthermore, some of the required modules require perl > 5.005x, which is probably
> still the most common version.
> 
> I prefer to reduce bogofilter's dependencies to a small,
> and ideally common and therefore already installed, set.

Whatever you have in mind may *seem* like it will have less dependencies, but
my experience is that such projects *always* grow into much the same thing
(warts and all) as what they were intending to replace. If spamassassin has
too many dependencies, and is difficult to install, it seems like the thing
to do is submit patches to ease up those dependencies and make it easier
to install. I'm sure they'd appreciate the help. If you find the developers
unwilling to take your patches, *then* a fork or competing project might be
warranted. But if you just go ahead and start a competing project for no
reason, you'll probably end up with a mess:

1) new developers will be confused as to which project, yours or
spamassassin, they should work on

2) existing spamassassin developers will resent you for not contributing to
their project, and there will be bad blood (which, AFAIK, is not
currently the case between spamassassin and bogofilter)

3) you will almost certainly not produce a better spam filter than
spamassassin

4) you will almost certainly grow a dependency set similar to
spamassassin, as you attempt to deal with the hard problems.

You *might* be able to solve 4 to some extent, but would it be worth
living with 1, 2, and 3?

Be well,
Zack

> 
> -Gyepi

-- 
Zack Brown