Anti-Spam SMTP Proxy Server

Shame about missing bugtracker. Per-month mailing list archives are so 1980s

This review is for the 1.x version as the 2.x version requirements are too high for someone running a personal server. Wow, where can a begin. I'd like to say I thank the developers for their hard work and time, donating both for little or no return. Because they are not getting anything back, I don't want to say anything bad about them. But when the way they do things can cause such huge amounts of damage, it's difficult to be thankful. First, let me say a few things about the project as a whole. It is run very poorly. I've no idea if anyone involved has ever worked on a commercial software product but it appears that they haven't. For instance, there is no archive of released versions (it's called the "stable" trunk but it is anything but that). So when a bug appears at a certain point, no diffs can be done to the code to see what changed and caused the bug. It makes finding bugs near impossible, which is why ASSP is so full of bugs. The "stable" versions get released with nearly no testing, which can cause users to lose a lot of mail, but apparently that's not important enough to do a bit of testing before "release" or to keep old versions around... I thought that was a major point of sourceforge including access to CVS. The version numbering doesn't seem to mean much. Major changes will happen on a super minor version number increase, and sometimes a very large version numnber increase will have only a few lines of changes, or even just changes to descriptive text in the configuration console. How many version numbers do we really need? 1.8.1.7(1.0.04) is the number as of this review, but most other software projects get by with three digits (Firefox = 3.6.25). What used to seem like one possible numbering scheme, the first number after the parenthesis indicating 1=stable, 0=development, was negated when a stable version was released with a (0.0.06) version. Today a version without a closing parenthesis was released. Sure these all are minor examples, but they really show the sloppiness that leads to major nightmares and your mail being lost. The product itself has tons of configuration options. So many, and the result of "feature creep", that some of the features replicate the abilities of two or three already existing features with minor changes. Some changes are so minor that just the way you configure a newer version of a feature could easily take the place of the other similar features. The downside is that these features are so poorly (or not even) documented that the features just seem the same. Then there are the configuration options that don't even do anything. They are usually the ones with a variable and a single line description that is very cryptic. But if you search through the code you'll find they do nothing. Having to spend so much time maintaining the system, tweaking the configuration and checking to make sure it is not blocking good mail has ended up taking way more time than just letting all the spam through and deleting it manually. I gave ASSP a 9-month run and even now I still review all the spam I get to make sure it's nothing important, unfortunately I can't see mail that was lost by rejected connections. I think I've been more than fair in trying to get it working. I've MANY years of experience as a UNIX + mail admin and PERL programmer, as well as worked on several commercial software products, so my level of expertise and expectations is probably very high. It's too bad that at this time I have no other solution recommendations for those who may be evaluating a spam filtering solution. Maybe later on someone will take up the cause and produce a simple, powerful solution that is actually maintained in a useful manner, but in the meantime I suggest people look anywhere else for a solution.