From: Carl Worth <cworth@cworth.org>
To: Jameson Graef Rollins <jrollins@finestructure.net>,
 notmuch@notmuchmail.org
In-Reply-To: <20091126183105.GA8745@finestructure.net>
References: <20091123130009.GA31695@finestructure.net>
	<20091126060132.GA5875@finestructure.net>
	<87iqcxkbla.fsf@linux.vnet.ibm.com>
	<20091126183105.GA8745@finestructure.net>
Date: Thu, 26 Nov 2009 11:12:01 -0800
Message-ID: <87ws1dqewu.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [notmuch] OpenPGP support
Precedence: list

On Thu, 26 Nov 2009 13:31:05 -0500, Jameson Graef Rollins <jrollins@finestructure.net> wrote:
> So the issue now is verifying/decrypting signed/encrypted received
> mail.  Playing around with it a bit more, I've found a couple of
> interesting things.  If I'm viewing an encrypted message with
> notmuch-show, and if I type 'v' (notmuch-show-view-all-mime-parts), I
> get the full message view, and then a prompt to:
> 
> Decrypt (PGP) part? (y or n)
> 
> Typing 'y', I see that there is some communication with my gpg agent
> (I get a gpg agent password prompt), but then once the password is
> entered, nothing happens, ie. I don't see the decrypted part.

Our integration with the MIME pieces of emacs definitely leaves
something to be desired. What currently happens when you press 'v' is
that notmuch creates a new buffer with the raw message content, then
runs mm-dissect-buffer and mm-display-parts on the content.

This works quite well for non-text parts, (either a mailcap-configured
viewer will be launched, or else you will be prompted to save the
file). But for text parts, the mm code appears to just write into the
temporary buffer that notmuch ends up killing before you can see
anything. So we just need to work out something proper here.

One thing I experimented with, that seems to work quite well, is to
construct a minimal buffer that the mm code will interpret as a
MIME-encoded message with just a single part.

So that's just a MIME-Version header, the original Content-type header,
a blank line, and then the original MIME content with its boundary
markers. So if we write a notmuch command to return that, then we'll be
able to easily support viewing of a single MIME part, (and I think it
will be easy to detect whether any text content ended up getting added
to the intermediate buffer that the user wants to see).

Any help experimenting more with this stuff would be very appreciated.

-Carl