Because the SMTP standard sends email without using encryption or authentication, every message you send is exposed to view. Client-side solutions such as Secure MIME (S/MIME) or pretty good privacy (PGP) can solve this problem, but they require your users' involvement. A better place to focus your security efforts is on securing SMTP traffic. If you can secure SMTP, you'll go a long way toward providing 100 percent security for mail traffic that originates or terminates at one of your servers.
Microsoft Exchange Server offers several tools for securing email traffic. One way to secure SMTP is to require the use of Secure Sockets Layer (SSL) for SMTP connections. However, that approach raises a problem. By default, all SMTP servers use port 25. But if you use SSL on port 25, non-SSL servers won't be able to connect through that port. And if you use a nonstandard port number, other servers won't be able to find your servers.
You can work around this problem. The STARTTLS verb (part of the Extended SMTP—ESMTP—command set) lets an SMTP client and server negotiate the use of Transport Layer Security (TLS) for an SMTP connection. Each end of the connection can choose to authenticate the other, or the TLS connection can be used purely for privacy. Either way, this approach offers three important advantages.
- It doesn't interfere with other servers and clients. Clients that support STARTTLS can use it; those that don't can continue to use unencrypted SMTP.
- It's opportunistic. When you enable the use of TLS with SMTP, your server automatically requests TLS when communicating with other servers, and it accepts TLS connections when requested. Assuming the other server completes the negotiation process, mail flow is automatically protected. (You'll generally need to tell your users to enable SSL/TLS in their Internet mail clients, though.)
- TLS-encrypting the SMTP stream also protects message headers, giving you an additional degree of protection against traffic analysis, which can tell network intruders who you're communicating with, and how often.
You must remember one important caveat, however: TLS doesn't protect messages from end to end. In other words, it doesn't protect messages that are in storage or traveling from client to server (unless the client also supports TLS). TLS protects the message only as it passes between two servers that both support TLS.
Requesting an SSL Certificate
Before you can begin to use TLS with SMTP, you must obtain and install a certificate for your SMTP server. If you've already set up your own certificate authority (CA), you'll find that requesting an SSL certificate is quite simple; if not, you'll need to save the certificate request to a file and deliver it to your preferred CA. (For a detailed explanation of how to set up and use the Microsoft CA or how to use an external CA for your public key infrastructure—PKI—see the Certificate Services topic in Windows Server Help.) I assume that you have access to a CA of some sort and want to request and install an SSL certificate for use with Microsoft Outlook Web Access (OWA), IMAP, POP, or SMTP.
The basic mechanics of certificate issuance are the same for all these protocols, although I deal with only SMTP here. You initiate the certificate request process from Exchange System Manager (ESM). In ESM's treeview pane, navigate to your server, then to Protocols. Select SMTP, then right-click the virtual server and select Properties. On the Access tab, you'll see the Certificate button, which is enabled whenever you run ESM on an Exchange server. Because the private key associated with the certificate is generated on the local machine, generating a certificate from your administrative workstation doesn't make sense.
You can use Internet Services Manager (ISM) 5.0 to request a certificate for use with OWA. However, using ESM to request POP and IMAP certificates is easier because you can request them from the virtual server Properties dialog box, so that's what we do here. To request a certificate, simply click Certificate.