Bug 403795

Summary:	Messages with shared nonexistent In-Reply-To are not grouped
Product:	[Applications] kmail2	Reporter:	FeepingCreature <default_357-line>
Component:	message list	Assignee:	kdepim bugs <kdepim-bugs>
Status:	REPORTED ---
Severity:	normal	CC:	dag
Priority:	NOR
Version:	5.7.3
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:

Description FeepingCreature 2019-01-31 08:20:00 UTC

When using Atlassian Stash to manage a software project, we are delivered mails for every change made to a project. To make its work easier, Stash sends these emails with a shared In-Reply-To header that does not exist. As a result, the messages are not threaded.

Example:

First email:

Message-ID: <PROJECT-repo-1-1234@Bitbucket>
In-Reply-To: <PROJECT-repo-1@Bitbucket>

Second email:

Message-ID: <PROJECT-repo-1-5678@Bitbucket>
In-Reply-To: <PROJECT-repo-1@Bitbucket>

In case that a set of emails is found that reply to the same parent, but the parent does not exist, the earliest email of the set should be considered the parent.

I've had a look at messagelib:/messagelist/src/core/model.cpp, but it's very spaghetti-like and I'm scared to mess with it.

Comment 1 Christophe Marin 2019-01-31 12:01:36 UTC

Were the atlassian developers informed they don't follow the rfc822 spec?

Comment 2 FeepingCreature 2019-01-31 13:04:32 UTC

I very much doubt they care. In any case, I can only presume that some Email program out there groups emails by In-Reply-To even if the parent can not be found, since otherwise there would be no reason for them to do this.

Comment 3 Christophe Marin 2019-01-31 15:23:40 UTC

If they don't care, why should we add workarounds for this broken behaviour?

Comment 4 FeepingCreature 2019-01-31 17:26:36 UTC

To be fair, I don't think their approach is a *bad* one, though it violates the spec. The spec is aimed at conversations characterized by hierarchical replies, but that's not exactly the usecase - the usecase is a sequence of emails about a common topic, of which no single one is unambiguously the "first" (consider two people subscribing to a pull request at different times) but which are still semantically grouped.

That aside, I'm simply filing this bug here instead of with Atlassian because I feel it's more likely to be fixed here, and probably more easily. (Not to imply you're under some obligation to care.)