Hi Simon--

On 09/04/2013 06:01 PM, Simon Hirscher wrote:
> This is now the second time the following has happened to me:

 [ decryption failure until adding sender's key]

> Also, I should add that manually decrypting the message with gpg (i.e.
> without using notmuch) already worked *before* I added the sender's
> key (not shown above). Still, notmuch obviously doesn't like it when
> the sender is unknown.

I just tried to replicate this, and i do not see this misbehavior.  I'm
using notmuch 0.16-1 on a debian testing/unstable system.

using --format=json and piping the output through json_pp, i do see the
following part of the response indicating that i don't have the signer's
key:

                 "sigstatus" : [
                     {
                        "errors" : 2,
                        "keyid" : "CB07362E3294B49E",
                        "status" : "error"
                     }
                  ],


but the message body is correctly decrypted and passed through.

I'm confused by a few things in your example above:

 A) how does it know that there was a signature if the message was
encrypted?  normal PGP/MIME messages contain a single OpenPGP chunk that
contains signatures wrapped inside the encryption, so that an observer
can't tell whether there is a signature or not (or who made the signature)

 B) the date of the message is the unix epoch date (1970-01-01), and the
date of the signature appears to be the unix epoch date as well.  this
seems suspicious and likely to be false.  how are these messages being
generated?

 C) you appear to be using gnupg 2.0.17.  the latest version of the
2.0.x line of gpg is 2.0.21.  maybe you can upgrade your gpg
installation and try again?

 D) you have the mingw32 version of gpg.  Does this mean you're running
notmuch on windows?

 E) i'd be curious to see what printmimestructure looks like on the
message in question.  if you've got a decent shell and the notmuch
source code, you should be able to do:

 notmuch show --format=raw id:xyz@example.com | devel/printmimestructure

I'd expect to see output like this:

└┬╴multipart/encrypted 3309 bytes
 ├─╴application/pgp-encrypted 11 bytes
 └─╴application/octet-stream 1351 bytes


if you can clarify any of the above, i'd appreciate it.

Also, if you can, you're welcome to send a signed/encrypted message
using the same framework that generated the problematic message directly
to me (my OpenPGP fingerprint is
0EE5BE979282D80B9F7540F1CCD2ED94D21739E9), and i'd be happy to take a
look at it.

	--dkg