BrightMail Anti-Spam is one of an increasing number of packages that claims to bring spam prevention to corporate email servers. The package works, like most of these tools, by examining the context of the emails going through the server and interpreting it to decide whether or not the message could be spam. If something does seem to be amiss, the package can take action as dictated by the system manager. It runs on Windows servers (in our case Windows 2000 SP4) as well as Linux and Solaris.
There are three main components to the package. The server does the hard work of actually analysing messages and deciding what's spam and what isn't. The client component sits on the mail server(s) and provides the interface to the central BrightMail server. If, on a Windows installation, you have an Exchange 2000 server, the BrightMail client will interface directly to it; if you don't, you'll have to set up a machine with the standard Windows SMTP service and funnel incoming mail through that box as a ‘relay’ server. Finally, the administration component, an MMS snap-in, can sit on the system manager's desktop PC or on the same machine as the client/server program.
There are four main modules to the spam detection process. Each module is configured via a wizard within the admin application, which we found annoying at first but which we soon got used to as it's only a few screens long and doesn't really take much longer to work through than would be the case with a single tabbed dialog box. The layout of the four different wizards follow a similar flow, so it's dead easy to jump from one to another without having to think too much and thus lose your train of thought.
First is the Whitelist/Blacklist module, which allows you to define lists of senders that you definitely want to allow messages from (whitelist) or definitely want to block (blacklist). Senders can be specified by email address or by IP address/range, or you can point the system at one or more whitelist/blacklist database services that exist out there on the Internet.
Rules and more rules
Next is the BrightMail Rules module, whose criteria are defined entirely by BrightMail in a set of spam-detection rules they have devised, and which are downloaded automatically from BrightMail's own servers.
Third is the BrightMailAnti-Virus module, whose criteria are largely automated since they revolve around messages being passed to an AV scanner (which runs on Symantec's AV engine), which certifies each message as either acceptable or infected.
Finally we have the Custom Rules module, where you get to define, via a built-in Custom Rules Editor, your own anti-spam rules. These basically revolve around pattern-matching within fields in the message header or body – things like ‘Subject line begins with …’ or ‘Header field does not exist’. Each rule can have up to five clauses, and you can chain rules together using ‘and’ or ‘or’ criteria (e.g. ‘If rule X or rule Y applies, flag the message as spam’). As well as defining your own rules via the GUI, you can also tell the system to use a ‘sieve script’, which lets you do everything in a single file without the limitations the editor GUI puts on you. Although the default Sieve script is blank, you do get a small sample script as part of the package, and it's a pretty straightforward language to learn.
For each of the modules, you get to define what action to take in the event that a rule ‘fires’ (i.e. something appears to be spam). You generally get a choice of six actions: deliver the message normally, delete it, deliver it to a special ‘spam’ folder in the recipient's mailbox, quarantine it (see later), forward it to someone else (e.g. the ‘postmaster’ account or a spam-specific equivalent) or modify it. There are two types of modification you can make; you can add a new header line, or you can append/prepend a ‘this may be spam’ message to the subject line. For each module, you can also choose whether to apply the rules to both internal and external users, and if you choose to apply them to both, you can define different actions for internal and external addresses. The quarantine function can put suspect messages in one of two places: a special folder in the user's Exchange or Domino mail account (via the Exchange/Domino spam folder add-ins) if you're using one of these mail servers, or a Web quarantine folder that the user can access through a browser (if you don't have Exchange or Domino). If your users use Outlook as their desktop client, there's also a COM plug-in that adds spam-related buttons to Outlook that enable it to communicate with the BrightMail server to, for instance, tell it that something it thinks is spam is actually acceptable to that user.
The reporting side of the system is simplistic but adequate – because you'll generally find out in real time when spam is coming in by forwarding it to your admin account anyway, all you'll really need from reporting is some historical trend monitoring. There are two basic reports – one for spam and one for viruses – and you can select the start/end dates and the type of output you want for each run. There's also a real-time performance graph to show you how heavily loaded the BrightMail server is, and of course you can use the built-in Windows performance monitoring tools to check how much of the server CPU or memory the BrightMail service itself is using up.
For ease of use, you can't really fault BrightMail. The console screen is sparse and there's a lot of work done for you via the automated BrightMail Rules and BrightMail Anti-Virus modules. The only downside to all this automation is that you don't really get to see under the hood of the BrightMail rulesets, though whether there would be any need to do so other than to satisfy a rampant curiosity is open to question. The things that you do have to configure yourself are relatively straightforward, unless you want to get your hands dirty with sieve scripting, and although we're not keen on wizards, each one is only three or four screens so they don't become onerous.
Aside from these comments, the only thing that surprised us was the system requirements for the package – twin Intel or quad SPARC processors and 1GB RAM – though having tried it out on a single 1GHz PIII with 1GB RAM, we suspect that a less sizeable configuration would be acceptable for a small organisation.
When considering this type of product, check whether there are packages on the market that cater for some or all of your organisation's parameters; this product is has a useful Outlook plug-in, for example, which may be a bonus over the capabilities of other such products if you happen to be an Outlook house.
A new version of this product, version 5.5, has just been released by Brightmail. We will add to this review once this revised version has been assessed.