On 11-Feb-19 13:01, Abhilash Raj wrote:
On Mon, Feb 11, 2019, at 9:55 AM, Marvin Gülker wrote:
Hi,
Am 11. Februar 2019 um 19:47 Uhr +0200 schrieb Danil Smirnov:
What could be a reason of HyperKitty failing to create a thread from chained emails?
For example, see "RECENTLY ACTIVE DISCUSSIONS" on page https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/
"Openvpn and Network mapping" discussion displayed as five threads instead of only one... This looks exactly like the problem I have been experiencing, see <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/C...>
Any ideas how to improve HyperKitty ability to detect threaded messages? Sadly, no. Let's hope the problem gets resolved. Please create a bug report at https://gitlab.com/mailman/hyperkitty/issues with the affected messages.
It would help us recreate the problem if you could attach a raw messages in the issue. I am assuming the messages aren't sensitive since the archive are open. Otherwise, feel free to omit any sensitive information.
I haven't looked at the threading code in HK since a long time, but my impression is that it looks at the 'In-Reply-To' header to figure out if the current email is a response to a previous email that it received.
In some cases, the order of the incoming messages can cause this to break, like when the reply comes in first and the original messages comes in later. I am not sure exactly what is happening here, but looking at the raw messages should help us reproduce and possibly fix the issue.
I believe that for threading to work more or less reliably, the thing to do is to look at the 'References' header.
That should give you the thread in order, and allow any message received out of sequence to be put in the proper location in your display.
'References' should be a superset of Reply-To (which is at most 1 Message-ID), so you only need Reply-To if there is no References - or to handle a client that doesn't obey the RFCs.
See https://tools.ietf.org/html/rfc5537#page-15 & https://tools.ietf.org/html/rfc5322#section-3.6.4