> 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
