Benjamin Franklin said, "Three may keep a secret, if two of them are dead." That's probably not an option for maintaining email security. Sometimes email is the best way to distribute confidential or sensitive information, but as soon as you do so, you increase the risk that the information will find its way into the wrong hands. There are several ways to reduce this risk; the most commonly used method is email encryption. In truth, there are many different methods of email encryption, but the most widely deployed and standardized is S/MIME, the Secure Multipurpose Internet Mail Extensions protocol.
S/MIME is a set of standards that describe how compliant clients can create, manipulate, receive, and read messages that have been protected with digital signatures, message encryption, or both. S/MIME is a mature standard, and it's widely available on a variety of clients and platforms. For example, Microsoft Outlook has supported S/MIME since Outlook 97; it's been supported in Eudora for about the same length of time and is also used with Mozilla Thunderbird. In theory (and mostly in practice), any two S/MIME-compatible clients should be able to exchange messages without problems.
The biggest requirement for S/MIME is that you have a means of issuing X.509 digital certificates to any users who need to send or receive protected mail. Certificate management has long been a stumbling block to S/MIME deployment because the mechanics of setting up a public key infrastructure (PKI) can be daunting. Microsoft has tried to make it easier by providing tools in Windows Server that can automatically issue S/MIME-compatible certificates to users when their Active Directory (AD) accounts are created. That helps with part of the problem, but the other part is just as hard: ensuring that users have access to other users' certificates.
For example, let's say that Alice and Bob want to exchange encrypted messages. If their accounts are both in the Global Address List (GAL), and they both have had certificates published to AD, you have no problem. On the other hand, if Alice is a vice president at the company and Bob is an outside attorney, there's a problem: How do Alice and Bob securely exchange certificates? There are several solutions, most of which revolve around ensuring that Alice and Bob (or, more precisely, their organizations) have either a common trusted path to a root Certificate Authority (CA) or that they cross-certify each other's trust hierarchies.
In most cases, the mail server itself has little to do with S/MIME; the server's responsibility is limited to not mangling encrypted or signed messages and thus causing them to fail signature verification. However, for OWA and Windows Mobile clients, Exchange is intimately involved in providing S/MIME support. In both cases, you need two things: a way for the client to securely retrieve and check certificates, and a way to use a local certificate to send and verify encrypted messages. The Exchange 2007 SP1 versions of OWA and Exchange ActiveSync provide these features, and next week I'll go into more depth on how they work.