Spam defenses get shot in the arm from Immunity 2.0

Most of the anti-spam products I've reviewed recently have been appliances. Although appliances are simple to install and set up, it's often less expensive to buy anti-spam software and install it on existing systems.

For larger organizations that already have SQL servers and either sendmail/Postfix servers on Linux or Exchange servers on Windows, products such as Cloudmark's Immunity 2.0 offer considerable financial advantage. Immunity comes in at about $1.50 per user per month for 1,000 users, compared to an average appliance's cost of $3,000 and up, depending on the number of users.

Immunity 2.0 requires both an SMTP e-mail server and a SQL server. There are specialized versions for Windows and Linux; I received the Red Hat ES (Enterprise Server) 3.0 version. Immunity performed well, stopping almost 95 percent of spam with zero critical false-positives and a noncritical false-positive rate of 1.5 percent.

Config Questions

Installation preliminaries caused me more headaches than the installation of Immunity itself. For some reason, Red Hat no longer includes the MySQL server with its ES release (despite it being included with ES 2.1 and Red Hat Linux 9), so I was stuck without one of the required elements.

Thankfully, after I got sendmail properly installed, along with an appropriate version of MySQL, everything went smoothly and quickly. Immunity's basic configuration is straightforward, with few options other than the Exchange plug-in.

Immunity uses a data collection and distribution network (SpamNet) to collect data from thousands of organizations and classifies messages according to a spectrum of parameters including originating server, domain, subject, content, and more. SpamNet is available from multiple vendors, and some other anti-spam vendors, such as Brightmail, offer similar networks.

The quarantine option holds suspected spam on the Immunity server. (It's actually stored on the SQL server, which may or may not be the same server as the Immunity server.) With the Exchange plug-in, e-mail is delivered to a spam folder in each user's e-mail directory. Users release incorrectly classified messages by dragging them to the inbox and classify missed spam by dragging it to the spam folder.

Either action adds the e-mail to the Immunity filter's classification engine, not as a simple whitelist entry, but as a more sophisticated entry that considers the originating domain and sender, subject, message contents, and more. Messages from a given domain may still be filtered out if they meet other spam criteria, even if some previous messages from that domain have been approved.

Immunity evaluates whether the scope of the user feedback should apply to only the individual or to the entire organization. By default, the software is conservative and applies the feedback only to the particular user who released the message from quarantine or added it to the spam folder. But once enough feedback has come in from multiple users, it's applied organizationwide -- an extremely useful feature I haven't seen in other anti-spam solutions.

Clearly, the directory plays a big part in all this. Immunity can use LDAP to connect to existing directories (including Active Directory), or it can create a new LDAP server to hold user information. Either option allows individuals in organizations not using Exchange to access their quarantined messages via a Web browser. It would be nice if you could save quarantine search criteria, too.