What is the best way to encrypt emails sent from a server running Windows 2008 R2?

I need to be able to send encrypted emails from our server running Windows 2008 R2 to remote users.

Remote Users will be using a RemoteApp via RDP gateway to connect to one of our servers and will create and save  txt files on the server that will need to be emailed to them. Some of these txt files will contain sensitive data and will need to be encrypted.  What is the best way to accomplish this?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Best way to encrypt email is via Public Key Encryption Certificates.

See: http://www.comodo.com/home/email-security/free-email-certificate.php

Comodo offers free secure email certificates that are easily installed into most email client programs (like Outlook, Netscape, etc.)  
If you need to prove the identity of the sender, you will need to get an SSL Certificate verified by either Comodo, Thawte, Equifax or Verisign. There are multiple providers and you can choose your pick.

You can also use GnuPG or PGP to do the same task, if you just need to encrypt email and do not need to legally prove identities when sending email. See http://www.gnupg.org, http://www.pgp.com for more information.
Dave HoweSoftware and Hardware EngineerCommented:
Ok, this is a big subject (with a lot of money riding on it in the market, as you can imagine :)

There are multiple methods of doing this. the first is classic, PKI based crypto - s/mime (the comodo solution mentioned above) and pgp (aka openpgp or gpg) are examples that use this technology.

the downside of classic pki is that it requires the recipient to already have a key, and to deliver that key reliably to the sender (not secretly, as this is not required, but reliably in that the sender has it and can verify that it is valid and it hasn't been given a fake)

There are multiple ways this is done; s/mime and pgp use the concept of a trusted signer - a authority that certifies that the key given is valid for the user listed; they do it in slightly different ways, but the concept is the same (we can get into the usual argument that the CAs are not worth the money they cost, and explicitly disclaim any liability even for paid, EV certs, but that doesn't matter as the choice is made by the recipient, not the sender). If you want to go down this route, you will need to get each potential recipient to obtain a key, or alternatively, you will want to create the keys yourself and issue them already created to the recipients. As n2fc points out, s/mime is built into most major email solutions, so it is simply a case of getting the key to them (and better yet, in a exchange environment you can have your keys auto-issued by the exchange server and pushed to the clients)

this will then only leave you with the task of encrypting the messages to send.

Second option, surprisingly viable for this sort of scenario, is that the website on receipt of the request (via https, presumably) issues a randomly generated passphrase, which the recipient will then be required to copy locally (you can of course store them on the site for later recovery). You then use standard compression software to compress and encrypt the data (modern compression software such as rar, winzip and 7z use secure encryption, usually AES@256 bit) and send those to the recipient, who then uses his random key with the archive to unlock it.  THis is much less effort for the developers than getting a pki up and running, but more effort to the users (s/mime will just decrypt stuff for them right in the mail client)

Third option - don't bother sending them at all - instead, mail them a "your download is ready" mail with a https link - they can then sign into your website and pull the data. This is surprisingly easy to code, and easy to make secure.

Final (and expensive) option is actually easiest to implement - there is a system of pki based crypto called "oracle based cryptography" - instead of the end user having to create their key, a trusted authority holds and issues keys, even if the recipient does not yet have one, and in such cases the recipient is sent a link to go to their website and set up a (free for them) end user account. The encrypted body of the mail then causes a applet to be downloaded from the site (to decrypt the attachment) or alternatively, the encrypted attachment to be uploaded to the site and the decrypted version viewed or downloaded (this allows the technology to be used with mobile devices too)

note this is functionally equivalent to the third option,  but with the mechanics managed by a trusted third party - for the Ironport solution (for example) the hosted component is an appliance that sits between the sending server and the internet, and acts as a mail proxy, encrypting the data before it is sent out.  This makes implementation trivial (you just set the IP of the appliance as a smarthost) but would be prohibitively expensive unless you also used it for the rest of its functionality (the Ironport can do a wide range of other email related security tasks, including supporting encrypted mail for your own lan users, antivirus/trojan/phishing, policy based rules, and DLP inspection of outgoing traffic looking for sensitive data (such as customer lists and CC numbers) - Zixmail offer a similar appliance that is more reasonably priced, but comes without the big name tags (so the Ironport has the Cisco name, plus major AV vendors) and is not quite as configurable in its rulebase.

if I were doing this, I would use route #3, make sure the passwords were good (and https mandatory) and just let commonly-accepted-as-secure browser encryption take care of it.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
PDSWSSAuthor Commented:

Thanks for your in depth response to my question.

Didn't think of route #3. Since we already have a Sharepoint Site that would greatly simplify
the process.   Thanks for saving me a lot of time by bringing solution #3 to my attention.
PDSWSSAuthor Commented:
Great answer. Thank you.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.