Re: viewing duplicate messages

2019-05-30 Thread Jorge P . de Morais Neto
"Rollins, Jameson" writes: > It would be nice to have an easy way in notmuch-emacs-show to know if > there are multiple messages with the same message-id in the store, and > to cycle through viewing each individually. That would be useful to me too. I have a Dell laptop and I subscribed to

Re: [FEATURE] indexing arbitrary headers

2019-05-30 Thread Daniel Kahn Gillmor
On Sat 2017-06-03 13:28:46 -0300, David Bremner wrote: > Ɓukasz Stelmach writes: > >> I'd like to ask for a new feature: indexing of arbitrary headers. Not >> all headers but a few selected by users. >> >> For example, I get a lot of mails from a Gerrit system. I'd like to keep >> them for a

Re: [FEATURE] indexing arbitrary headers

2019-05-30 Thread Carl Worth
On Thu, May 30 2019, Daniel Kahn Gillmor wrote: > I just wanted to point out that this specific request has now been added > to notmuch, thanks to David Bremner! It will hopefully be part of the > forthcoming 0.29 release: Woo-hoo! Thanks so much!! This has been on my

Re: Safe and useful handling of "Mixed Up" mangled messages

2019-05-30 Thread Daniel Kahn Gillmor
On Thu 2019-05-30 02:21:02 +, Rollins, Jameson wrote: > The way he handles the repair seems reasonable to me (modulo > a couple minor comments in reply). I've responded to jamie's review here with v2 of this series, which can be found at id:20190530172707.10378-1-...@fifthhorseman.net. If

Re: viewing duplicate messages

2019-05-30 Thread Rollins, Jameson
On Thu, May 30 2019, Jorge P. de Morais Neto wrote: > That would be useful to me too. I have a Dell laptop and I subscribed > to email notifications about firmware updates. It turns out that Dell > sends all such notifications (which obviously have different content) > with the same message-id.

Re: [FEATURE] indexing arbitrary headers

2019-05-30 Thread Ralph Seichter
* Daniel Kahn Gillmor: > I just wanted to point out that this specific request has now been > added to notmuch, thanks to David Bremner! Thanks indeed! I am very much looking forward to this feature. -Ralph ___ notmuch mailing list

[PATCH] mime-node: be clearer about decryption

2019-05-30 Thread Daniel Kahn Gillmor
Part 0 of a multipart/encrypted object is GMIME_MULTIPART_ENCRYPTED_VERSION; part 1 is GMIME_MULTIPART_ENCRYPTED_CONTENT. Using the name for what we want describes our intent more clearly than using a magic number in the code. Signed-off-by: Daniel Kahn Gillmor --- mime-node.c | 2 +- 1 file

Re: viewing duplicate messages

2019-05-30 Thread Daniel Kahn Gillmor
On Thu 2019-05-30 19:11:22 -0300, Jorge P. de Morais Neto wrote: > I have a Dell laptop and I subscribed to email notifications about > firmware updates. It turns out that Dell sends all such notifications > (which obviously have different content) with the same message-id. Have you reported

[PATCH 4/6] mime-node: split out _mime_node_set_up_part

2019-05-30 Thread Daniel Kahn Gillmor
This is a code reorganization that should have no functional effect, but will make future changes simpler, because a future commit will reuse the _mime_node_set_up_part functionality. In the course of splitting out this function, I noticed a comment in the codebase that referred to the original

[PATCH 1/6] test: avoid showing legacy-display parts

2019-05-30 Thread Daniel Kahn Gillmor
Enigmail generates a "legacy-display" part when it sends encrypted mail with a protected Subject: header. This part is intended to display the Subject for mail user agents that are capable of decryption, but do not know how to deal with embedded protected headers. This part is the first child of

[PATCH 6/6] index: avoid indexing legacy-display parts

2019-05-30 Thread Daniel Kahn Gillmor
When we notice a legacy-display part during indexing, it makes more sense to avoid indexing it as part of the message body. Given that the protected subject will already be indexed, there is no need to index this part at all, so we skip over it. Signed-off-by: Daniel Kahn Gillmor ---

[PATCH 3/6] util/crypto: add _notmuch_crypto_payload_skip_legacy_display

2019-05-30 Thread Daniel Kahn Gillmor
This is a utility function designed to make it easier to "fast-forward" past a legacy-display part associated with a cryptographic envelope, and show the user the intended message body. The bulk of the ugliness in here is in the test function _notmuch_crypto_payload_has_legacy_display, which

[PATCH 2/6] util/crypto: make _n_m_crypto_potential_payload whether part is a payload

2019-05-30 Thread Daniel Kahn Gillmor
_notmuch_message_crypto_potential_payload could only return a failure if bad arguments were passed to it. It is an internal function, so if that happens it's an entirely internal bug for notmuch. It will be more useful for this function to return whether or not the part is in fact a

[PATCH 5/6] cli/{show,reply}: skip over legacy-display parts

2019-05-30 Thread Daniel Kahn Gillmor
Make use of the previous changes to fast-forward past any legacy-display parts during "notmuch show" and "notmuch reply". Signed-off-by: Daniel Kahn Gillmor --- mime-node.c| 9 - test/T356-protected-headers.sh | 2 -- 2 files changed, 8 insertions(+), 3 deletions(-)

Hiding legacy-display parts

2019-05-30 Thread Daniel Kahn Gillmor
Now that notmuch can handle and interpret protected subject lines, it should also avoid forcing the user to look at "legacy display" parts that some MUAs (notably enigmail) copies of the protected headers that are intended to be rendered only by legacy clients -- clients capable of decryption but

Re: [PATCH 4/6] mime-node: split out _mime_node_set_up_part

2019-05-30 Thread Daniel Kahn Gillmor
On Fri 2019-05-31 00:28:23 -0400, Daniel Kahn Gillmor wrote: > This is a code reorganization that should have no functional effect, > but will make future changes simpler, because a future commit will > reuse the _mime_node_set_up_part functionality. This particular re-organization has a slight

[PATCH] append _unused to the expression defined using unused() macro

2019-05-30 Thread Tomi Ollila
This way if variables defined using unused() macro are actually used then code will not compile... - removed unused usage around one argc and one argv since those were used - changed one unused (char *argv[]) to unused (char **argv) to work with modified unused() macro definition ---

Re: Using Xapian synonyms with notmuch

2019-05-30 Thread David Bremner
Xu Wang writes: > I have some contacts who go by several names (mostly people who use > their native name in addition to sometimes using a name easier to > pronounce for others; but also some secret agents). I often want to do > something like "from:James" and where notmuch gives me back results

Using Xapian synonyms with notmuch

2019-05-30 Thread Xu Wang
I have some contacts who go by several names (mostly people who use their native name in addition to sometimes using a name easier to pronounce for others; but also some secret agents). I often want to do something like "from:James" and where notmuch gives me back results with emails from "James",

viewing duplicate messages

2019-05-30 Thread Rollins, Jameson
This is essentially a wishlist report... It would be nice to have an easy way in notmuch-emacs-show to know if there are multiple messages with the same message-id in the store, and to cycle through viewing each individually. It's possible (even likely) that one has multiple messages with the

Re: [PATCH 2/4] util/crypto: identify and repair "Mixed Up" mangled messages

2019-05-30 Thread Daniel Kahn Gillmor
On Thu 2019-05-30 02:18:57 +, Rollins, Jameson wrote: > I understand that this fix is for multipart/encrypted messages, but I'm > not sure I would call the repair function itself a "crypto function". > Given that I can imagine more repair functions in the future, would it > make sense to break

Re: [PATCH 2/4] util/crypto: identify and repair "Mixed Up" mangled messages

2019-05-30 Thread Rollins, Jameson
On Thu, May 30 2019, Daniel Kahn Gillmor wrote: > I agree that this technically isn't a "crypto function", and as such > might not belong where i've put it. What would you think about > util/repair.{c,h} or util/demangling.{c,h} ? I guess "repair" is maybe clearer? No strong opinion. jamie.

Re: v2 of Safe and useful handling of "Mixed Up" mangled messages

2019-05-30 Thread Rollins, Jameson
On Thu, May 30 2019, Daniel Kahn Gillmor wrote: > This is the second revision of the series initially posted at > id:20190528225452.17550-1-...@fifthhorseman.net. > > The changes in this series from v1 are in response to the helpful > review by jrollins. In particular: > > * test to ensure that

Re: [PATCH 4/4] cli/show: show repaired form of "Mixed Up" mangled messages

2019-05-30 Thread Daniel Kahn Gillmor
On Thu 2019-05-30 02:09:47 +, Rollins, Jameson wrote: > On Wed, May 29 2019, Jameson Graef Rollins wrote: >> On Tue, May 28 2019, Daniel Kahn Gillmor wrote: >>> When showing a message that has been mangled in transit by an MTA in >>> the "Mixed up" way, "notmuch show" should instead show the

Re: [PATCH 4/4] cli/show: show repaired form of "Mixed Up" mangled messages

2019-05-30 Thread Rollins, Jameson
On Thu, May 30 2019, Daniel Kahn Gillmor wrote: > Yes, it does fix notmuch reply as well. Do you think that we should > augment the test suite to include 'notmuch reply' too? I mean, more tests don't hurt, but I don't see it as critical. I think it could be as simple as (please verify):

[PATCH v2 2/4] util/repair: identify and repair "Mixed Up" mangled messages

2019-05-30 Thread Daniel Kahn Gillmor
This patch implements a functional identification and repair process for "Mixed Up" MIME messages as described in https://tools.ietf.org/html/draft-dkg-openpgp-pgpmime-message-mangling-00#section-4.1 The detection test is not entirely complete, in that it does not verify the contents of the

[PATCH v2 1/4] test: add test for "Mixed-Up Mime" message mangling

2019-05-30 Thread Daniel Kahn Gillmor
Some MTAs mangle e-mail messages in transit in ways that are repairable. Microsoft Exchange (in particular, the version running today on Office365's mailservers) appears to mangle multipart/encrypted messages in a way that makes them undecryptable by the recipient. I've documented this in

[PATCH v2 3/4] index: repair "Mixed Up" messages before indexing.

2019-05-30 Thread Daniel Kahn Gillmor
When encountering a message that has been mangled in the "mixed up" way by an intermediate MTA, notmuch should instead repair it and index the repaired form. When it does this, it also associates the index.repaired=mixedup property with the message. If a problem is found with this repair

v2 of Safe and useful handling of "Mixed Up" mangled messages

2019-05-30 Thread Daniel Kahn Gillmor
This is the second revision of the series initially posted at id:20190528225452.17550-1-...@fifthhorseman.net. The changes in this series from v1 are in response to the helpful review by jrollins. In particular: * test to ensure that 'notmuch reply' is fixed as well * the repair

[PATCH v2 4/4] cli/{show, reply}: use repaired form of "Mixed Up" mangled messages

2019-05-30 Thread Daniel Kahn Gillmor
When showing or replying to a message that has been mangled in transit by an MTA in the "Mixed up" way, notmuch should instead use the repaired form of the message. Tracking the repaired GMimeObject for the lifetime of the mime_node so that it is cleaned up properly is probably the trickiest part