Recipe 8.8 Encrypted Mail with MH

8.8.1 Problem

You want to send and receive encrypted email conveniently with the MH mail handler.

8.8.2 Solution

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.

8.8.3 Discussion

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.

8.8.4 See Also

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: The mail server listens on the normal service port for unsecured connections, such as 110 for POP3 or 143 for IMAP, and permits a client to "turn on" SSL after the fact. The IMAP command for this is STARTTLS; the POP command, STLS; we will refer to this approach generically as STARTTLS.
SSL-port: The mail server listens on a separate port, such as 995 for POP3 or 993 for IMAP, and requires that SSL be negotiated on that port before speaking to the mail protocol.

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.^[1] 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]

^[1] 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.