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