Bug in notmuch-emacs: inconsistent rendering for messages with multiple From: headers

I'm experimenting with e-mail messages with multiple addresses in the From: line. i know, it's dirty, but e-mail is a dirty world. I noticed that notmuch-emacs renders such messages differently depending on the order of the recipients, and whether or not they are an addr-spec or a mail-addr (see

BUG: emacs: fcc duplicates messages with variant bodies due to mml security

I'm concerned that notmuch-emacs is causing variant messages of encrypted/signed messages to be generated. In particular, if notmuch-fcc-dirs is not nil, two variants of the message bodies will be created: one will be sent through "notmuch insert" and the other will be sent to sendmail. the mml s

[PATCH] NEWS: document notmuch reindex

Describe the introduction of the "reindex" subcommand. This blurb acknowledges Subject: instability under reindexing when multiple copies exist (suggesting that this is something that needn't necessarily hold up a release). --- NEWS | 13 + 1 file changed, 13 insertions(+) diff --git

Re: [PATCH] NEWS: cleartext indexing

Daniel Kahn Gillmor writes: > give a short summary of cleartext indexing of encrypted e-mail > messages. That's fine and I've pushed it, but as written reindex will need it's own NEWS item. We also need to decide if the instability of subjects under reindex (see one of the currently broken test

[PATCH] NEWS: cleartext indexing

give a short summary of cleartext indexing of encrypted e-mail messages. --- NEWS | 18 ++ 1 file changed, 18 insertions(+) diff --git a/NEWS b/NEWS index c2ebb644..895b7627 100644 --- a/NEWS +++ b/NEWS @@ -11,6 +11,24 @@ Out-of-tree builds has been dropped. The same can now be

Re: [PATCH] NEWS: test suite out-of-tree builds

Jani Nikula writes: > Out-of-tree builds now work and supersede --root option. > --- pushed, d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch

Re: web interface to notmuch

On Sat 2017-10-21 23:00:00 +0300, Jani Nikula wrote: > For the list archive, we could restrict to displaying text/plain only. and text/x-diff, surely :) But yeah, good point. Brian, what do you think about such a constraint? would that make your implementation safe enough to put on the public I

Re: nmbug backtrace due to .mailmap

On Mon, 16 Oct 2017, "W. Trevor King" wrote: > b. Comment out the ‘_insist_committed()’ line in nmbug's ‘pull’ >definition and try again. Make sure you restore the check after >the successful pull. FWIW this fixed it for me, thanks. BR, Jani.