Security, Anti-Relay, and Anti-Spam Features
Enterprise and ISP admins alike must look for strong security features in a mail server. IMail doesn't disappoint.

IMail's SMTP server includes anti-relay features that help prevent outsiders from using your server to send spam (right). Relay can be limited to users on hosts within your own domain(s), users in the IMail database, or to systems within a specified address range. An SMTP "kill file" can filter out known offenders by user/host, and an "accept file" can over-ride relay limits. For example, travelers who require SMTP access on the road can be added to the

IMail can protect itself against hacker exploits by denying access to any IP address that sends more than 512 characters in a command other than SMTP DATA, and by disabling SMTP VRFY to reduce spoofing. The WELCOME message returned by SMTPD, POP3, and IMAP4 servers can be changed in the NT registry to help avoid exploits that are server- and version-specific.

IMail can also limit the number of recipients per outgoing message to curb internally-generated spam at the source. For incoming spam, IMail's hierarchical processing rules provide a first line of defense. Once spammers make themselves known, kill files can be used to "black list" IP addresses, domains, or individuals.

Another way to "batten down the hatches" is to require client authentication and encrypt passwords. IMail's SMTP, POP3, and IMAP4 servers can be configured to require SMTP AUTH, APOP, and CRAM-MD5 authentication, respectively. Web Messaging users can be mutually-authenticated and their entire session encrypted using Secure Sockets Layer (SSL) v3. And remote administration privileges can be configured per client login.

Before enabling SSL, the administrator must run the "SSL Config Utility". Once you supply the IMail SSL registry path, this utility sets up a digital certificate that identifies the server. Third-party certificates issued by a CA can be imported, or you may create a self-signed certificate and public/private key pair. Next, select authentication and encryption algorithms that you'll support and indicate whether client-side certificates are required. Finally, enable SSL from the IMail Administrator and specify the SSL port.

At first, I had a terrible time enabling SSL: after I created a new self-signed certificate, Web Messaging would never run again (with or without SSL enabled). I re-installed IMail and discovered that I'd shot myself in the foot by over-writing the server key and certificate files created during installation. When I created a self-signed certificate with another filename, Web Messaging ran smoothly. Users can choose whether to protect their Web Messaging session with SSL by clicking on a URL at the bottom of each page. For example, a user might enter "secure mode" when making administrative updates. Note that SSL only protects traffic between the client and server: it does not encrypt mail messages sent to others through SMTP.