Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes: > If we see index options that ask us to decrypt when indexing a > message, and we encounter an encrypted part, we'll try to descend into > it. > > If we can decrypt, we tag the message with index-decrypted. > > If we can't decrypt (or recognize the encrypted type of mail), we tag > with decryption-failed. I have some mild reservations about hard-coding this tagging into the library layer, but I guess it's consistent with what is there already. I guess we can use indexopts to control automatic tagging later. One observation is that both index-decrypted and decryption-failed are properties of the database state and not the message, syncing them between machines will be a bit tricky. > +/* descend (if desired) into the cleartext part of an encrypted MIME > + * part while indexing. */ > +static void > +_index_encrypted_mime_part (notmuch_message_t *message, > + notmuch_indexopts_t *indexopts, > + GMimeContentType *content_type, > + GMimeMultipartEncrypted *encrypted_data) Is there a good reason not to propagate crypto errors back to the caller? It seems like it should be up to the top level caller to the library (e.g. the CLI) to decide to ignore such errors. I'm not very happy with tags as the only error reporting mechanism. I understand that _index_mime_part would need to return a status value, but that change doesn't look to disruptive? d