scheidell at secnap
Sep 14, 2008, 6:32 AM
Post #17 of 35
(2020 views)
Permalink
|
> At 09:44 12-09-2008, Jesse Stroik wrote:
> There is SpamAssassin the project and SpamAssassin the software. The
> project, under the aegis of the Apache Software Foundation, provides
> a framework to support open source software development to deliver an
> enterprise-grade, freely available software product for the public benefit.
>
> SpamAssassin, the software, is a mail filter to identify spam. It is
> designed for easy integration into any email system. The cost to
> develop such a software is estimated to be around US $1.1 million.
And many, if not the large majority of commercial systems use it somewhere.
A commercial product that does not understand spam, or if their team has not
had lots of experience with spam, will make those mistakes.
As the maintainer of the freebsd port of Spamassassin, I have to look at any
user contributed 'fixes' or scripts to see if they are keeping with the
overall SA design, or if they are freebsd only, do they cover, or will they
work with ALL freebsd users (commercial systems, hobby, or home grown).
As the maintainer, I have rejected several scripts that are mostly site or
company specific, reminding the author that SA has to be made generic, and
the Freebsd port of SA has to remain generic. I also remind them 'this is
open source', you are ENCOURAGED to make custom, site specific changes.
That said, as my second role as the CTO of one of the many companies that
uses SA, thanks to the team, community, and users for creating a generic,
'one site fits all' system, but, it does need lots of work to make it a
viable system to be used by 'users'. Remember users ;-)? If SA is used by
YOU, and YOU are totally in charge of what gets whitelisted, blacklisted,
etc, then YOU can maintain all the cf files and you can (eventually) get a
pretty stable, accurate system.
If, however, you are trying to create something easy to set up, and easy for
users to use without your constant tweaking, yes, its VERY hard.
As much time as our engineers spend on optimizations and minor customer
custom requests, I think most of their time is spend trying to balance the
spam capture rate and the false positive rate.
(you really need a team :-).
Examples of problems include ISP's who have clients that actually subscribe
to those 'free crap in your email box', vs commercial companies who don't
want their users using their email address for 'free porn' and such.
Take one of the reputation filters as an example: DCC.
DCC is great for identifying sources of BULK EMAIL. The commercial version
also lets you get a bulk/non bulk percentage value on the sending IP. The
free system allows you to take checksums of the spam and get a 'bulk/non
bulk' judgment on the email. Remember, this is BULK EMAIL, not spam. It
would trigger FP's on every truly double opt-in mailing list.
Bayes: if you are an ISP, and not using user based bayes, then your plastic
surgeons will be sending and receiving enlargement type emails that are
legit, but that a mortgage company would want to block.
HABEAS/SENDERBASE, more examples: for ISP/ generic use, maybe letting in
commercial bulk email from companies who pay to certify their bulk email is
he right thing to do. For a commercial business, maybe not.
However, that said, it is possible to build a commercial system that is easy
to install, will (out of the box) be about 99% accurate, allows users and it
administrators access to reporting and configs, without creating a burden.
(no, we don't allow individuals access to ~user/local.cf files ;-), but we
do allow admins to turn on and off specific plugins, and users to set their
own spam threshold values.
Bottom line: same argument for any commercial vs custom system.
A 'drop in place, open source' product isn't a product, its a framework. It
will be less accurate, because it wasn't tweaked.
A custom product will harder to build, but will be (eventually) what the
company needs (for 1.1mm ;-). Also, consider the ongoing need to continue
to track spam, new spam types and upgrades.
A COTS product should offer good support, enough customizations that it will
work for your company.
I support SA efforts and will continue to since I understand the value of
building and working with an open source community. That is why I volunteer
my time to maintain the freebsd SA port. If you are trying to block spam
for one server, or one company, and you don't want to spend a large amount
of time, get a pre-build, supported product. Not a framework. If however,
your needs are so unique that a COTS product won't work, then hire a team,
build a custom solution.
Your choice.
(sorry, off my soap box now)
--
Michael Scheidell, CTO
>|SECNAP Network Security
|
1
