Many of us Microsoft Exchange Server administrators have learned to ignore a simple fact: Most email is easily read in transit. You've no doubt heard the chestnut that sending SMTP email is equivalent to sending a postcard; anyone who can access the postcard can read its contents (thus leading to fascinating historical artifacts such as the stamp code for concealing amorous messages in plain sight).
How did this insecure transport method come about? The engineers who originally designed SMTP were working from a very different set of assumptions about how email would be used, who would use it, and how the Internet would be operated and maintained.
Related: Securing SMTP Email Traffic
Various proposals have been offered to update the security of SMTP traffic by changing, extending, or even replacing basic SMTP to provide authentication, nonrepudiation, and confidentiality. However, SMTP deployment worldwide has reached critical mass; it's very unlikely that the protocol itself will be superseded by something more secure. In order to preserve confidentiality and nonrepudiation, then, we need to focus on methods that work within the confines of existing SMTP deployments.
One solution is to encrypt mail on the client so that it's protected before it's ever seen by an SMTP server. That's exactly what S/MIME does. However, S/MIME deployment can be complex. In exchange for its complexity, it gives us end-to-end protection that can include sender authentication, confidentiality, and nonrepudiation. For many sites, though, S/MIME is overkill; it would be great if there were a way to easily enable encryption for message transport only. This level of protection would be enough to prevent eavesdroppers, even those with access to a target network, from reading messages in transit between servers.
As it happens, there is a way to provide exactly this protection. Exchange Server and many other email servers support the use of Transport Layer Security (TLS) encryption along with SMTP. Just as you can use SSL (a close relative of TLS) to protect an HTTP session, you can use TLS with SMTP to provide both confidentiality and authentication for email traffic.
When you configure a server to both offer and accept, but not require, TLS for SMTP, it's known as opportunistic TLS. Exchange 2003 didn't support opportunistic TLS, but Exchange 2007, Exchange 2010, and Microsoft Office 365 all do. In fact, you can enable this protection even if you have only the default set of self-signed certificates, although you'll find that many servers won't accept them. For that reason, it's a good idea to obtain certificates from a commercial CA for use with SMTP.
See also: Configuring SSL/TLS
The setup process for enabling TLS with SMTP is simple: Obtain a suitable certificate, then install it using the Exchange certificate wizard or the Enable-ExchangeCertificate cmdlet. As soon as you've done so, Exchange will start accepting TLS requests, as signaled by the presence of the STARTTLS SMTP verb, as well as sending STARTTLS itself when communicating with other TLS-capable servers.
Because this is such a simple change to make, and because it provides an immediate privacy benefit, I encourage you to do it sooner rather than later. There's no downside.
