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.
Were the atlassian developers informed they don't follow the rfc822 spec?
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.
If they don't care, why should we add workarounds for this broken behaviour?
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.)