Below is a patch for full rfc3156 (pgp signing/encryption) support for
balsa 2.0.9 (cvs version of 2003/Mar/06).


Installation
------------

To use this patch, you need gpgme 0.3.14 (see http://www.gnupg.org). The
upcoming version 0.4.0 (still marked as unstable) may not work, as there
were some api changes. Of course, you need gpg and all the necessary keys...

After applying the patch, you must rerun autogen.sh. Be sure that aclocal
finds gnupg.m4 and libxml.m4 (you could add them to balsa's aclocal.m4).
RFC3156 support is activated using the "--enable-gpgme" with configure.


How it works
------------

When sending a message which shall be signed/encrypted, the crypo stuff is
run from libbalsa_create_msg() (libbalsa/send.c) after the complete chain
of mutt bodies has been assembled. If successful, the chain is replaced by
a new one, otherwise the routine fails (I introduces a new enum for that)
with an error and the user can continue editing the message, including the
decision to send it unencrypted/unsigned.

To be able to force a specific subtype for a message or multipart, I had to
make small patches to libmutt and add two fiels to the LibBalsaMessage
struct. Furthermore, the patch takes care that text bodies in signed
messages are always sent as quoted-printable as requested by rfc3156.

Received signed/encrypted messages are handled in balsa_message_set()
(src/balsa-message.c). If a signature is detected, it is checked and the
result put into a struct I added to LibBalsaMessageBody.

Encrypted messages are more tricky, as I had to replace the encrypted
message stream by the decrypted one. Instead of hacking a new mailbox type,
I just save the decrypted stuff to a temp file. LibBalsaMessageBody has an
additional field indicating that the data comes from this file and not from
the mailbox stream. Due to this method, it is *not* possible to have the
unencrypted and the encrypted version open simultaneously, as the encrypted
bodies are unref'd after a successful decrypt operation. It is always
possible to see the original stream in the source viewer.


Changed Files
-------------

* libmutt/protos.h (mutt_make_multipart takes a forced subtype as 2nd
parameter)
* libmutt/sendlib.c (ditto)
* libbalsa/body.[hc] (add two fields to the structure, and be sure to
allocate/release them)
* libbalsa/message.[hc] (changed prototypes, add fields for gpg_mode,
parameters and message subtype to the struct, take care uf unlinking a
decrypted stream)
* libbalsa/send.c (inplement calling the sign/encrypt stuff at the right place)
* src/balsa-message.c (call check signature/decrypt at the right place, add
method to nicely display the signature)
* src/main.c (init the gpgme lib)
* src/sendmsg-window.c (new send options)
* balsa-rfc3156/libbalsa/rfc3156.[hc] (new, the meat of it...)
* configure.in (added checks for gpgme and libxml)
* libbalsa/Makefile.am (added rfc3156.[hc])


TODO's + Questions
------------------

(an unsorted list...)

* Laurent Cheylus reported multithreading probles with gpgme (unfortunately
he was not very specific there) when using his patch for balsa 1.4.2. I
could not see any crash, but maybe other users?

* Encrypting mails with multiple recipients does not make sense, as their
public keys will (should) be different. We could send multiple messages,
but they will be different (message id, maybe time...).

* Encrypted messages are stored in the sentbox as they are sent. This is
correct, but the user will never be able to read them again, as (s)he does
(should) not know the recipient's private key. Maybe we should add an
option to store them unencrypted to sentbox (fccbox)?

* When sending a message, the user should have the option to select a key
if there is more than one matching the sender's (sign) or recipient's
(encrypt) address.

* If decrypting a message failed or was cancelled, it can only be encrypted
by deselecting and reselecting it. There should be a button for that...

* The temp decrypted message stream is simply unlinked when the message is
unref'd. If we are paranoid 8are we?), we should wipe the file with random
data first.

* Checking a signature and decryption of a big message may take a while, so
we might want to display a progress bar.

* Printing of signature info's.