Bug 331891

Summary: Broken references-chain (email header) leads to new Thread
Product: [Applications] kmail2 Reporter: Bernhard Scheirle <bernhard+kde>
Component: message listAssignee: kdepim bugs <kdepim-bugs>
Status: CONFIRMED ---    
Severity: normal CC: ahartmetz, charlemagnelasse, kde
Priority: NOR    
Version First Reported In: 5.21.1   
Target Milestone: ---   
Platform: Neon   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Bernhard Scheirle 2014-03-08 20:35:08 UTC
Asume we have two emails with the following headers:
header 1:
Message-ID: <first@host>

header 2:
Message-ID: <third@host>
In-Reply-To: <second@host>
References: <first@host> <second@host>

Now shouldn't these two emails be in the same thread regardless where the email with the Message-ID <second@host> is (especially if <second@host> isn't present)?

Reproducible: Always

Steps to Reproduce:
1. Send an email to yourself
2. Reply to that email
3. Reply to the reply
3. Delete the second email
Actual Results:  
Now the first and third email are in separate threads.

Expected Results:  
The first and third email should still be in the same thread.

You have to enable threads in your messages list:
View -> Message List -> Aggregation -> Default Message List
Comment 1 Denis Kurz 2016-09-24 17:55:22 UTC
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present?

If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months.
Comment 2 Bernhard Scheirle 2016-09-24 18:06:56 UTC
This is still present / reproducible in KMail 5.3.0.

KDE Neon
KDE Frameworks 5.26.0
Qt 5.7.0 (kompiliert gegen 5.7.0)
Das xcb Fenstersystem

[I updated the bug report to 5.2.1 since 5.3.0 is not present in the drop down menu]
Comment 3 Matt Whitlock 2016-12-23 22:21:30 UTC
Still reproducible in KMail 5.4.0 too.

Quite annoying, as this breaks the most common threading scenario: Bob emails me, I reply back, Bob replies to my reply. Bob's reply is not threaded under Bob's original message, as the intervening message (my reply) is in my Sent box, not in my Inbox. Threading should consider *all* of the message IDs given in the "References" header if a message identified by the "In-Reply-To" header is not found.
Comment 4 Justin Zobel 2022-10-27 02:48:58 UTC
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Comment 5 Bernhard Scheirle 2022-10-29 10:32:04 UTC
Still reproducible with kmail2 5.21.1 (22.08.1)
Comment 6 Andreas Hartmetz 2025-07-16 11:02:40 UTC
The threading code has been changed to always use the first entry of of the "References:" list, commit 1cd2d0ba525ec23de4087e3299c21a6285a263ce in messagelib. Please close if that is good enough. (You probably don't want any messages to appear in several threads in the same folder. I guess the most sophisticated and slowest solution would be to try all entries of "References:" and see if any matches a thread, but the first is probably best if only trying one of them.)
Comment 7 Andreas Hartmetz 2025-07-16 11:09:58 UTC
*** Bug 401997 has been marked as a duplicate of this bug. ***
Comment 8 Andreas Hartmetz 2025-07-16 11:12:46 UTC
Copy of the commit message for convenience:

Fix threading of Jira e-mail notifications
    
Jira e-mail notifications coming from https://issues.redhat.com are
semi-randomly split into two separate threads for each Jira key because
the `References:` e-mail header contains multiple values but only the
first value can be used to reliably construct the threads.
    
This commit makes messagelib use the first value in the `References:`
header instead of the last one to make the threading work as expected
for Jira e-mail notifications.  I have been using this patch for two
years without observing any unexpected side effects.