Your editor's review of graphical email
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
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
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
- 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
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
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 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
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
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
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
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 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 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
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.
Moreso than some other subjects reviewed by your editor, this one boils down
well to a summary table. So, here it is:
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,
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
to post comments)