May be it would be a good idea to update the documentation: https://confluence.atlassian.com/adminjiraserver070/creating-issues-and-comments-from-email-749383405.html Now there is nothing about References header in it.

Added slightly improved patch version.

I'm attaching patch to file jira\src\java\com\atlassian\jira\mail\MailThreadManagerImpl.java which adds native support for References email header and fixes this issue.

Please note that I'm not Java developer, so probably patch can be improved. But it works and solves my problem.

I hope this patch to be applied to official JIRA.

I wonder why this issue marked as minor and did not fixed for more than three years! This bugs brokes JIRA email integration with one of most popular email client – MS Outlook.

We've had similar experiences with Exchange, which strips out ALL pertinent headers--both In-Reply-To and References. We were able to build a "database" of sorts that correlated message ids and Exchange's Thread-Topic header, however, and that allows us to add the appropriate headers to properly "thread" messages.

While I suppose in general it is going to be difficult to produce a system that can handle legitimate emails, I think that JIRA could probably be improved in this regard, especially since it doesn't need to use a full-fledge threading algorithm to properly affix comments to tickets.

See also this blog post:

http://wintertech.blogspot.com/2006/10/bug-tracking.html

In order to work around this, and to better filter some of our email, we ended up setting up fetchmail, postfix, and procmail on our installation machine. We created a procmail recipe to add the In-Reply-To header if References was present and it was not, which has more or less solved this problem.

Using this pipeline has other benefits, since procmail's regex matching lets us dump mail into different projects based on common subject headers. (We use FileService instead of PopService now.)

I would still recommend using References: instead of In-Reply-To: as the key header for threading email. Our solution is too platform specific to be widely applicable, and the current behavior of JIRA isn't very standards-compliant.

Another quick aside is that Outlook (not OE) seems to include the In-Reply-To: header. So really the only offending MTA is Outlook Express. I guess the other problem that we'll face here, however, is that many of our customers will be using OE--so if this bug isn't fixed, their emails to us will cause the same problem.

Headers provided in an example email from Outlook Express. These headers do not include "In-Reply-To:" so a new issue was created, even though it is in response to a current issue.

MTAs handle message creation differently. Outlook Express, for example, does not generate an In-Reply-To: header at all. See attachment OE_Headers.png. Instead, OE uses References: to help thread messages. We also use Opera's M2 mailer and Thunderbird. Thunderbird includes both references and in-reply-to (the In-Reply-To: header is the same as the final Reference), and Opera does the same.

It's also worth pointing out that the In-Reply-To: header is not constrained; it could be a person's name, email address, or nothing. The References: header was (I believe) designed specifically for message-threading in Usenet, and therefore has a well-defined format.

The result of OE's behavior is that every time a response to an issue is made by email with a sanitized header (i.e., no ticket information is included), a new issue is created in our database. This can be somewhat frustrating, especially since we are hoping to transition to using Jira without alerting our customers immediately.