The Grumpy Editor, graphical mail clients, and GPG

This article is part of the LWN Grumpy Editor series.

Your editor's review of graphical email clients drew a couple of complaints for having neglected to look at how those clients handle message encryption and authentication. There is a confession to be made here: your editor, despite having been an enthusiastic cypherpunks participant many years ago, despite believing that email should be encrypted whenever possible ("why communicate via postcards" and all that), and despite having pulled down copies of PGP back in the days when it really was important to get as many copies in circulation as possible, has made very little use of tools like PGP and (later) GPG. The need has not been pressing, and the hassle factor has been just a little too high.

Encrypted communications remain important, however. Perhaps, thinks your editor, the current crop of graphical email clients will have made life easier for those who want to use cryptographic technologies with mail. Thus this article, which examines the quality of crypto support in graphical email applications. Your editor has not forgotten his promise to look at non-graphical clients as well; that article will come before too long. Honest.

Email crypto overview

To properly set the context for a review of crypto support, it's necessary to cover some background material. Those experienced with using GPG with mail, and who don't feel inclined to heckle, can probably skip the following material.

There are two fundamental tasks which must be performed by a mail client which supports crypto:

• Encryption: encoding the contents of a message so that only the designated recipient(s) can read it. Naturally, the client must also support decryption of incoming encrypted messages.

• Authentication: confirming that a given message was really sent by the person it claims to be from. On the sending side, the client must be able to "sign" a message with an encrypted hash of its contents; the recipient must be able to decrypt the hash, confirm that it matches the message's contents and that it was encrypted with the sender's private key. If everything checks out, the recipient can have a high degree of confidence that the message was sent by the owner of the private key, and that it was not modified in transit.

These two functions are completely independent of each other. Plain-text messages can be (and often are) signed for authentication, while encrypted messages need not carry a signature.

There are various other functions the client can provide to help with cryptographic communications. At the top of the list, perhaps, is making it easy to send a public key to a correspondent, and to add a key received from elsewhere to the key ring.

There is another issue which must be kept in mind when dealing with cryptography and email: how the mail is to be formatted. There are two mechanisms in common use:

• Inline "ascii armor" encoding. In this mode, GPG formats the message with some surrounding header information and the whole assembly is transmitted as a simple, text/plain message. This is how PGP did things back in the day when you had to download your copy from the bleeding-edge FIDO network; some mail clients still do things that way now.

• MIME format, as described in RFC 3156. This format creates a multipart message, one of which contains the entire encrypted message (which can be a multipart MIME message in its own right).

In the modern world, one would think that the MIME format would be the way to go. As it turns out, however, different clients support different formats, and they do not all support both. As a result, you need to know which format your recipient expects if you want to exchange cryptographic messages. The more helpful mail clients can track that information for you.

Finally, it is worth mentioning the S/MIME specification, as found in RFC 2633. S/MIME uses X.509 PKIX certificates for key management; it does not use GPG. There is a certain amount of commercial pressure behind S/MIME; certainly the companies in the digital certificate business like the idea. In the free software community, at least, GPG usage appears to exceed S/MIME usage in a big way. This review will not concern itself with S/MIME other than mentioning it in passing.

Thunderbird

Thunderbird 0.7, out of the box, supports only S/MIME. The user who digs through the menus in search of GPG options will come up empty-handed.

When dealing with missing features in Thunderbird, the first response should always be "look for an extension." The relevant extension in this case is Enigmail; it provides what is, arguably, the best crypto support found in any free graphical application.

By default, Enigmail uses inline encoding for outgoing messages (except for those carrying attachments); that behavior can be changed on a per-message or permanent basis, however. Per-recipient preferences are supported; indeed, Enigmail can be configured to automatically sign and/or encrypt messages to specific recipients, and to use specific keys and formats. Keys can be obtained from public keyservers if desired. There is an operation for including a public key in an outgoing message. In general, Enigmail makes sending encrypted mail easy.

On the receiving side, things work just as nicely. Signed messages are automatically validated and marked as such. Decryption works as expected, though (by default), the user often has to explicitly ask it to download a full message from an IMAP server so that decryption can take place. Public keys can be extracted from incoming mail and saved to the keyring. The "import key" functionality is a little brittle, however; if the message containing the key has been signed, Enigmail will not be able to import it.

Enigmail will optionally remember a passphrase for a configurable period of time, and can be told to forget the passphrase. It also has an operation for the generation of keys within the client; this operation may make life easier for users who are completely unfamiliar with GPG, but, perhaps, it goes a little beyond what a mail client should be providing. There is a "view console" operation for advanced users who want to see exactly what GPG is saying.

Overall, Thunderbird with the Enigmail provides outstanding cryptographic support. One wonders why Thunderbird comes with S/MIME support built in, when the (presumably much more heavily used) GPG support must be added separately.

Sylpheed

Sylpheed has GPG support, though some distributions (e.g. Fedora) do not enable that support. The essential functionality is there, but the edges are rougher than with some other clients.

By default, Sylpheed will send in MIME format. It can be configured to use the inline format on a per-account basis, but there is no way to specify the encoding for an individual message, or on a per-user basis. Sylpheed encrypts outgoing mail for the recipient only; most other mail clients also encrypt for the sender, so that people can read their own mail.

On the receiving side, Sylpheed only understands MIME-format messages. If you send an inline-encoded, encrypted message to yourself with Sylpheed, it will be unable to read its own output. Sylpheed verifies signatures automatically, but does not make the result immediately apparent; see the screen shot for an example of what Sylpheed does when the signature does not check out. This client can be configured to pop up a window with result of each signature validation; it does make these results more evident, but requires the user to be forever dismissing popups. If you receive an encrypted message, the only way to know will be the passphrase prompt which pops up - Sylpheed does not mark the message as having been encrypted.

Sylpheed does not remember passphrases by default, but can be configured to do so, with a configurable timeout. It lacks a "forget the passphrase" operation, however. There is no provision for sending keys, or for importing keys from an incoming message.

In summary: Sylpheed has the features needed for cryptographic communications, but they could be a little better developed. The biggest shortcoming, probably, is the inability to receive inline-encoded messages from correspondents.

KMail

KMail has reasonably good GPG support built into it, with (as of version 1.6.2) one glaring omission: it cannot create or understand MIME-encoded, encrypted mail. When it receives such a message, it recognizes the problem and tells the user about it, but that is not entirely satisfying. KMail does have a special plugin mechanism for cryptographic plugins, and a PGP/MIME plugin does exist. The procedure for installing that plugin is seriously daunting, however, and one would guess that relatively few users go to that degree of trouble. Grabbing, configuring, and building half a dozen new libraries and reconfiguring GPG is an entirely different process than installing a Thunderbird extension. So, for the time being, for the majority of users, it must be said that KMail does not support PGP/MIME. KMail does, however, have support for old versions of PGP (as opposed to GPG), should that still be useful for anybody.

The composition interface works well, with the usual "encrypt" and "sign" options available from the toolbar. KMail has a nice option to "encrypt whenever possible," which means anytime it can find keys corresponding to the recipients. It is not quite as nice as per-recipient preferences, but probably does the right thing most of the time. Since KMail does not support PGP/MIME, it sends attachments in the clear - even if the message itself is supposed to be encrypted.

The receiving side works as it should. Signed and encrypted messages are marked in an impressively garish manner (see the screenshot); fortunately, it is possible to change the colors used.

If configured to do so, KMail will remember passphrases, but with no timeout and no "forget" operation. There is no mechanism to send or import keys. Your editor was also able to crash KMail several times while exercising the crypto operations, which is not a generally good thing. In general, KMail's GPG support gives the impression of being a work in progress. Once things stabilize and the new MIME code is integrated, KMail should have crypto support which is second to none.

Evolution

Evolution 1.5.9 comes with GPG support, though one has to dig a bit to set it up. The "settings" dialog makes no mention of it; one has to go into the edit screen for an individual mail account. S/MIME support can also be turned on in this way. Unlike the other mail clients reviewed here, Evolution requires the user to explicitly supply a key ID before it will work with GPG, and there is no nice widget for the selection of that ID.

Evolution only works with MIME-encoded messages; it cannot create or understand the inline format. Composition works as expected; there is no provision for per-recipient preferences or automatic encryption. Received mail is automatically verified and decrypted, and the results displayed prominently. There is also a button for obtaining detailed information, including the output from gpg (shown in the screenshot).

Evolution will, when told to do so, remember a passphrase "until the end of the session." Selecting "forget passwords" on the "Actions" menu will cause it to forget the passphrase. There is no provision for sending or importing public keys. All told, Evolution has all of the features one really needs to use GPG with email, and not a whole lot more.

Balsa

Balsa comes with reasonably complete GPG support. It understands both MIME and inline format; it creates encrypted and signed mail in MIME format by default, but that can be changed on a per-message basis. There is no provision for per-recipient preferences.

Composition works as usual. If you attempt to send an encrypted message with attachments in inline format, Balsa will warn you that the attachments will be sent in the clear. There is an "always encrypt" option which causes the send to fail if no public key exists in the keyring for the recipient; there is no keyserver capability.

Decryption and signature verification are performed automatically. Encrypted messages are not marked as such. Signature information, instead, is appended to the text of the message. If signature verification fails, a popup window alerts the user to the fact.

Balsa does not remember passphrases, so the user must get used to typing it in often.

Overall, Balsa provides the functionality that one really needs. As is generally the case with Balsa, it feels less slick than with some of the other graphical mailers, but the necessary capabilities are there.

Summary

Moreso than some other subjects reviewed by your editor, this one boils down well to a summary table. So, here it is:

Client	Send		Receive		Recip.	Import	Auto	Passphrase
	Inline	MIME	Inline	MIME	prefs	key	encrypt	Keep	Forget	S/MIME
Balsa	Y	Y	Y	Y	n	n	Y	n	n	n
Evolution	n	Y	n	Y	n	n	n	Y	Y	Y
KMail	Y	n	Y	n	n	n	Y	Y	n	n
Sylpheed	Y	Y	n	Y	n	n	n	Y	n	n
Thunderbird	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y

Looking at the table, it is evident that all of the graphical mail clients reviewed have implemented support for GPG-encrypted and signed messages. That is a good start. The sad thing is that, due the the existence of two different standards, these clients cannot all interoperate with each other. Given the history of the old format, and the clear superiority of the new format (which is more flexible, less dependent on GPG in particular, and can encrypt attachments), it really seems that a proper client should, at this time, support both.

These issues will eventually be worked out. Even before then, however, relatively transparent and easy encryption and authentication have been put into the hands of millions of users worldwide. That can only be a good thing.

---

(Log in to post comments)