[bug]: notmuch-emacs: notmuch-show: "c F" shows same file name for different instances of duplicate messages

[bug]: notmuch-emacs: notmuch-show: "c F" shows same file name for different instances of duplicate messages

[Gregor Zattler]

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

Dear notmuch developers,

the new feature of showing different instances of emails
with same Message-Id is great and very helpful.

But in notmuch-emacs, when hitting "c F" in notmuch show
always stashes the very same filename, in my case the one
fitting the search term.

Also hitting "V" in notmuch-show shows the very same raw
email.


Due to my (sloppy) procmail rules I do have a few instances
each of many emails and I would like to act on them.  For me
the whole point of this new feature is to act on the
different instances of these seemingly identical emails,
e.g. deleting some of the files.


See attached a simple maildir with three different
minimalistic emails featuring the very same Message-Id.

Since the emails in this test case differ in Subjects they
reveal another problem with showing different instances of
seemingly same emails: While cycling through the three
emails in notmuch show the Subject line is duly showed as
"one", "two", "three", but the very first grey line every
time shows "one".  I don't know if that is a bug or not.


Ciao; Gregor
--
  -... --- .-. . -.. ..--.. ...-.-



[-- Attachment #2: same-mid.tar --]
[-- Type: application/x-tar, Size: 10240 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: [bug]: notmuch-emacs: notmuch-show: "c F" shows same file name for different instances of duplicate messages

[David Bremner]

Gregor Zattler <telegraph@gmx.net> writes:

> Dear notmuch developers,
>
> the new feature of showing different instances of emails
> with same Message-Id is great and very helpful.
>
> But in notmuch-emacs, when hitting "c F" in notmuch show
> always stashes the very same filename, in my case the one
> fitting the search term.
>
> Also hitting "V" in notmuch-show shows the very same raw
> email.

As you probably saw, I sent patches to the list for these two issues.

> Since the emails in this test case differ in Subjects they
> reveal another problem with showing different instances of
> seemingly same emails: While cycling through the three
> emails in notmuch show the Subject line is duly showed as
> "one", "two", "three", but the very first grey line every
> time shows "one".  I don't know if that is a bug or not.

I'll have to think about this a bit more, both whether it's a bug or a
feature and how hard it is to change.

Re: [bug]: notmuch-emacs: notmuch-show: "c F" shows same file name for different instances of duplicate messages

[David Bremner]

David Bremner <david@tethera.net> writes:

> Gregor Zattler <telegraph@gmx.net> writes:
>
>> Since the emails in this test case differ in Subjects they
>> reveal another problem with showing different instances of
>> seemingly same emails: While cycling through the three
>> emails in notmuch show the Subject line is duly showed as
>> "one", "two", "three", but the very first grey line every
>> time shows "one".  I don't know if that is a bug or not.
>
> I'll have to think about this a bit more, both whether it's a bug or a
> feature and how hard it is to change.

For those following along at home, I think Gregor refers to the "thread
subject" as shown by e.g. "notmuch search". This might or might not be
related to the message being replaced by a different duplicate.

d

Re: [bug]: notmuch-emacs: notmuch-show: "c F" shows same file name for different instances of duplicate messages

[Gregor Zattler]

Hi David,
* David Bremner <david@tethera.net> [2022-08-04; 18:58]:
> For those following along at home, I think Gregor refers to the "thread
> subject" as shown by e.g. "notmuch search". This might or might not be
> related to the message being replaced by a different duplicate.

actually I referred to the very first line in a notmuch-show
buffer.  I see, it's difficult to impossible to decide which
Subject to choose for the thread if there are different
Subject: headers in the files which host the Message-Id of
the first message of the thread.


But since you mentioned it there is another glitch: If one
searches for my test case like so:

from:telegraph@gmx.net AND to:telegraph@gmx.net AND subject:one

the test case shows up.

In my particular case the notmuch-search buffer shows two
lines for two matching threads one of which stands out
because its date is 1970-01-01 because I was too lazy to
provide Date: headers in the test case's messages.

In my particular case the Subject: shown on this very line
for the test case is "two".  But if I place the cursor on
this line and hit RET, the "first" of the three messages is
shown, which in my particular case happens to be the one
with Subject: "one".  Correspondingly the very first line of
this notmuch-show buffer reads "one".

Even if it's not possible to decide which of the messages is
the "right" one, I think it would be less surprising, if the
subject shown in the notmuch-search buffer would be the one
from the "first" message shown in the notmuch-show buffer.
In most/normal cases this will be the "right" one or at
least the one the user is content with.



Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-

Subjects for messages with multiple files

[David Bremner]

Gregor Zattler <telegraph@gmx.net> writes:

> In my particular case the notmuch-search buffer shows two
> lines for two matching threads one of which stands out
> because its date is 1970-01-01 because I was too lazy to
> provide Date: headers in the test case's messages.
>
> In my particular case the Subject: shown on this very line
> for the test case is "two".  But if I place the cursor on
> this line and hit RET, the "first" of the three messages is
> shown, which in my particular case happens to be the one
> with Subject: "one".  Correspondingly the very first line of
> this notmuch-show buffer reads "one".

The underlying issue here is a bit tricky. Each message-id has a subject
value [1] associated with it. This is used to decide what to display
from notmuch search (i.e. it's used to construct the subject threads)
and it is used by the regex search.  Currently (since 2017) we make some
effort to maintain that as the subject of the first file indexed. The
numbering of duplicates on the other hand is by lexicographic order of
the filenames [2].  Probably we want to keep a list of subjects, but
then the question is how to make the order match. Ordering the files by
discovery order could be done (although not as trivially as you might
expect) or ordering the subjects by alphabetical order of filename could
be done. The latter probably requires less intrusive changes to the
database, but the question, for those who made it this far is we care
about keeping track of what the first indexed file is.  I had a quick
look back at the previous discussion [3] and I see some vague reference
to that being desirable as mitigation for some duplicate message-id
attacks, but I'm not sure how convincing that is.

[1]: actually a Xapian value slot, for those familiar with Xapian.

[2]: something like that anyway. The main point is that the database
     doesn't know anything about the order files are indexed
     (discovered).

[3]: see e.g. https://nmbug.notmuchmail.org/nmweb/search/id%3A87378dny3d.fsf%40qmul.ac.uk

Re: [bug]: notmuch-emacs: notmuch-show: "c F" shows same file name for different instances of duplicate messages

[Gregor Zattler]

Hi David,
* David Bremner <david@tethera.net> [2022-08-04; 18:47]:
> Gregor Zattler <telegraph@gmx.net> writes:
>> the new feature of showing different instances of emails
>> with same Message-Id is great and very helpful.
>>
>> But in notmuch-emacs, when hitting "c F" in notmuch show
>> always stashes the very same filename, in my case the one
>> fitting the search term.
>>
>> Also hitting "V" in notmuch-show shows the very same raw
>> email.
>
> As you probably saw, I sent patches to the list for these two issues.

I confirm, "c F" no stashes the right file name, "V" shows
the right raw message.

Thanks for the quick response, Gregor