6.9. Mail Access

After you have built a mail architecture to send and receive mail, you need to provide a way for users to access it. Securing mail access has already been partially addressed by architecture: if you place your mail storage within a protected internal network, external attackers are unable to access it directly. Nevertheless, because most successful attacks originate from within, you must take steps to secure the software that provides this service.

6.9.1. Guidelines for Securing Mail Access Internally

The key protocols involved in mail access are POP and IMAP. The former allows users to download and (by default) remove mail from the mail server, and the latter allows users to view and manipulate messages on the server. The most popular software suites that provide this functionality include Courier, WU-IMAP, Qpopper, Cyrus-IMAP, and Binc IMAP. While we cannot explore in detail the installation, configuration and security options of each of these pieces of software, there are some general configuration guidelines which apply.

Authentication and logging

Ensure that all mail access sessions with your mail server are authenticated and that connections, and subsequent authentication attempts (successes and failures), are logged. Try to avoid using plain-text authentication if you do not need to support MUAs that require it. Enforce strong password policies so that users have good passwords that rotate frequently enough to keep from having stale passwords but infrequently enough to keep users from writing their passwords down on a Post-It note attached to their keyboards.

Encryption

Most mail access software supports encryption and you should enable it wherever possible. This helps ensure that passwords are not exposed and potentially sensitive information in mail messages is not being transmitted in the clear over the local network.

Software security

Like all server software, mail access suites are prone to attack and vulnerabilities are disclosed with some regularity. Before choosing a software suite, examine its track record and determine whether you have the time required to keep your software up to date and patched.

Following these three guidelines will accomplish most of what is required in securing access to your message store. Additional security may be possible but will vary on the mail access software suite you have chosen to deploy.

6.9.2. Guidelines for Securing Mail Access Externally

So far, we have assumed that mail access originates on the internal network. Invariably organizations need to provide mail access to users outside the network, whether they are at home, at alternate work sites, or roaming. This problem is typically solved in one of two ways: VPNs and webmail. These two options are not mutually exclusive, and both are shown deployed in Figure 6-5.

Figure 6-5. VPN and webmail access

6.9.2.1 Virtual private networks (VPN)

Providing VPN access (as depicted in Figure 6-5) to your internal network for roaming users not only provides for secure mail access, but may generally provide secure access to whatever resources you wish to make available. VPN installations can be nontrivial to set up, but many support two-factor authentication, making them viable as a secure external access method. Once a user has connected to the local network over the VPN, he may check mail as he normally would. One major drawback is that VPNs often require the installation of client software, which makes their use from nonorganizationally owned systems more challenging.

6.9.2.2 Webmail

Many organizations provide some form of access to the internal mail storage using a webmail frontend. As shown in Figure 6-5, systems that provide webmail access often reside on a perimeter network and allow only HTTPS traffic to the server. The webmail server itself communicates with the internal mail server using traditional POP and IMAP protocols for mail retrieval. Mail is also submitted over HTTPS and sent to the internal mail server via SMTP. The options for providing webmail access are as diverse as for providing direct mail access: SquirrelMail, Imp, Open Webmail, and so on. Of course, general security guidelines apply. Remember that attacks against a webmail server can attempt to either exploit the webmail software and gain access to the webmail system, or use the webmail server as a means to attack the internal mail server.

Protect the server

Ensure the server on which your webmail application is running is locked down as much as possible. Traffic to the machine should be restricted to HTTPS and authentication should be mandatory and logged.

Encryption

Enforce the use of HTTPS, not HTTP, for access to the webmail application. All authentication should also happen over HTTPS. Of course, you may want to enable HTTP access to the server for the sole purpose of redirecting traffic to the HTTPS URL to make things easier for your users.

Software security

Remember that your webmail application is going to be some collection of scripts and/or binaries. Ensure that all software on which your webmail application relies is up to date. SquirrelMail for instance relies heavily on PHP, thus you should ensure that you have secured your PHP installation and that your PHP libraries are patched against all disclosed vulnerabilities.

Following these guidelines, and making effective use of webmail and VPN will go a long way to securing external access to internal mail.