Seven mail servers tested

Summary:Exchange might be the most popular but is it the best? We test the alternatives.


Contents
Introduction
Basic Mail Server Security
IBM Domino
Ipswitch iMail Server
Kerio MailServer
Microsoft Exchange
Novell Groupwise
Sendmail
SuSE Linux OpenExchange
Specifications
What to look for
Sample scenarios
Editor's choice
About RMIT

Basic Mail Server Security

Malicious content
The majority of virus and malicious content such as worms are still spread these days via the Internet e-mail system, therefore it would be advisable to evaluate and deploy a separate dedicated e-mail antivirus application, for more information see the review I performed in the April 2004 edition of T&B "Stop MyDoom being your doom".

Spam, spam, spam, glorious spam
Another e-mail borne nuisance is spam, this requires a fair bit more planning and evaluation once you have settled on a mail server platform you can start down that path. For more information see the three reviews we have performed in the past for T&B in the July 2003, October 2003, and December 2004 editions.

E-mail security gateways and services
Due to the fact that in some way, shape, or form e-mail servers need to be publicly accessible and online 24x7x365 then a definite consideration when looking at your e-mail systems security would be to consider a gateway device. Two that we have come across in the past are Ironport who provide robust network attached security appliances which process the network traffic prior to delivery and after messages have been sent. For a complete managed e-mail security solution in a similar vein then see the folks at Network Box they deliver, configure and remotely maintain and monitor an e-mail gateway server at your own premises.

Harden the servers O/S and batten down the perimeter
Next on the list is to ensure that the server's operating systems are correctly hardened, primarily by turning off or disabling all services, processes and ports that are running unnecessarily. Also it would be assumed that the network perimeter security is correctly setup and fire-walled, (see our firewall review in the March 2004 edition of T&B), to allow a certain level of port access, preferably with an adequate multi-homed firewall, not just a default de-militarised zone (DMZ).

Avoid the common mis-configuration traps
There are a couple of configuration items that some engineers commonly overlook or misconfigure when setting up an e-mail server. Mail servers must never be allowed to run open relays and ensure the domain name servers are correctly configured for reverse IP address lookups as well as forward name lookups.

Don't be a relay point for spammers
Firstly get your relaying correct, identify the public and private domains that the mail server will be responsible for handling and make sure that those and only those machines on those networks are explicitly allowed to relay e-mail even to the point of using individual IP addresses on your subnets in the configuration files. If relaying is not correctly setup then those with nefarious intentions, generally spammers, could discover the open-relay server and start using that mail server as the launching point for their spamming activities, this generally would result in that mail servers IP address being added to a registered black list (RBL) service and therefore subscribers to that service would no longer receive messages from that mail server even if they were legitimate. Not a good look if you are a high profile organisation. Plus it can sometimes be quite difficult and time consuming to discover which RBL your mail servers IP address has been added to and then have it removed.

Ensure name servers can resolve forwards as well as back
To ensure those with designs on taking over a domain name for their own purposes don't get their hands on it one must ensure that the company domain name servers are correctly configured to not only resolve from domain name to IP address but also reverse lookups from IP address to domain name. It is also critical to ensure that the secondary name server (which automatically updates its name databases from the primary server) is setup to only accept update data explicitly from the primary servers IP address this stops those with nefarious intentions from uploading a changed zone file to the secondary server and then crashing the primary server causing the secondary server to start feeding out the unauthorised server IP information for that domain name.

Topics: Browser, Broadband, Collaboration, Enterprise Software, Hardware, Microsoft, Servers

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Related Stories

The best of ZDNet, delivered

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
Subscription failed.