DynaComm i:mail

The vendors recommend placing the software on a separate server in the DMZ, routing back email traffic through the firewall and into the internal email server. As with other products on the test, we put the application on the same physical network as the email server, but it is good advice.

Installation took a while to complete. We then had to fire up a console to configure the filter to act as an intermediary between the box sending the suspect mail and the email server software. We had problems with this, however, as the initial console was confusing. It was difficult to discern which parts of the configuration did what. A call to support helped, and we were ready to send spam to our test server.

The console, aside from the configuration page, is well laid-out and everything is in one place. Items such as connection filtering, rule filtering and reports are in a tree structure that is easy to navigate.

We set up a rule to check for spam by heuristic analysis and Bayesian filtering. The system can notify an administrator when spam arrives, but this is probably not something many administrators would want it to do.

The reporting function is noteworthy. We found it particularly intuitive and not only could reports be tailored to the whims of the administrator, they could also be looked at on the console or emailed as a PDF. Looking at the reports generated could allow administrators to further refine the filters to block spam more effectively.

After it was set to run all mail through heuristic and Bayesian analysis the machine took a while to get through the deluge we sent it. However, it was not the slowest in the test and with further configuration it could probably be sped up. The Bayesian filter also hit a couple of false positives but it could be trained out of doing so with further effort from the administrator.