You want to send and receive encrypted email conveniently with the MH mail handler.
To view an encrypted message:
show | gpg --decrypt | less
To encrypt and send a message, use the encryption features of your text editor, such as emacs [Recipe 8.1] or vim [Recipe 8.2]. Care must be taken so that only the message body, not the header, gets encrypted.
MH (or more likely found on Linux, nmh ) differs from most mailers in that each mail-handling command is invoked from the shell prompt and reads/writes standard input/output. Therefore, to decrypt a message normally displayed by the show command, pipe show through gpg, then optionally through a pager such as less.
Further instructions for integrating MH and GnuPG (and PGP) are at http://www.tac.nyc.ny.us/mail/mh and http://www.faqs.org/faqs/mail/mh-faq/part1/section-68.html.
SSL for Securing Mail
Most major mail clients (pine, mutt, etc.) support secure POP and IMAP using the Secure Sockets Layer (SSL) protocol (also known by its later, IETF-standards name, Transport Layer Security or TLS). Most commercial mail servers and ISPs, however, do not support SSL, which is highly annoying. But if you're lucky enough to find a mail server that does support it, or if you run your own server [Recipe 8.9], here's a brief introduction to how it works.
A mail server may support SSL in two ways, to protect your session against eavesdroppers:
STARTTLS is the more modern, preferred method (see RFC 2595 for reasoning), but both are common. Our recipes suggest that you try STARTTLS first, and if it's unsupported, fall back to SSL-port.
The most critical thing to protect in email sessions is, of course, your mail server password. The strong session protection provided by SSL is one approach, which protects not only the password but also all other data in the session. Another approach is strong authentication , which focuses on protecting the password (or other credential), as found in Kerberos [Recipe 4.16] for example. These two classes of protection are orthogonal: they can be used separately or together, as shown in Table 8-1.
Whatever happens, you don't want your password flying unprotected over the network, where hordes of dsniff-wielding script kiddies can snarf it up while barely lifting a finger. [Recipe 9.19] In most cases, protecting the content of the email over POP or IMAP is less critical, since it has already traversed the public network as plain text before delivery. (If this concerns you, encrypt your mail messages.)
Finally, as with any use of SSL, check your certificates; otherwise server authentication is meaningless. [Recipe 4.4]
 SSL can also perform user authentication, but we do not address it. Our recipes employ SSL to protect an interior protocol that performs its own user authentication.