Broken threading of community notification emails

[Steffen Opel _Utoolity_]

Thanks to the great work of the community team I'm meanwhile pretty happy with the monitoring, filtering and notification options for community content!

The one thing that would yield a significant improvement still is proper threading in my email client (I'm using Thunderbird), i.e. the Atlassian community is pretty much the only forum where emails do not automatically sort themselves into a thread based on the originating question or discussion.

This considerably increases the time to skim through new responses, and more importantly, reduces the chance to timely respond to those where I've posted an answer and someone asks for additional feedback, because I cannot mark/watch the resp. thread.

I'm not an expert on how email correlation for threading purposes works in detail. Does anyone have a tip on how to eventually achieve this already, maybe I'm overlooking something? Would the community team consider to implement the likely required email metadata changes otherwise?

[Nic Brough -Adaptavist-]

My main client does some threading, so there's definitely something that allows it (in the picture, the boxed number shows all the items in the thread, but it doesn't do it the way I'd like, as an expansion, it takes you to a new list)

But it doesn't thread properly - new-question and edited-same-question emails can arrive together, but it won't link them together. 

My guess is that the "type" is in the way, and the client doesn't know it should ignore [answer] [reply] [etc]

1.  The client itself fails on expanding threads

[carolyn french]

Email threading on the original discussion/question is working for me in Gmail. It is really, really helpful to have this. Just returned from a vacation, and weeding through emails didn't take as long as I suspected it might, phew. Hopefully improvements can be made for other clients to do this properly.

[Monique vdB]

@Steffen Opel _Utoolity_ thank you for raising this! 

The "type" might be the culprit here, that would make sense it would confuse an email client.  You may remember we've had to adjust the subject lines in our email templates a bunch of times.  

I'll file a ticket to take a look at them again and see what we can do!

[LarryBrock]

Hi @Monique vdB - any news or update on this?  I just returned from a two week vacation and this certainly would have helped me sift through all the email that arrived in my absence.

And, in case nobody has said it lately - Thank you for all the hard work you do to make this community flourish!

[Kevan Lin]

@LarryBrock which email client are you using?

[LarryBrock]

Hi Kevan, I use Thunderbird on Linux and Mac OS.

[Kevan Lin]

Thanks for the client information. When we look into threading, i'll be sure to include this as part of our 'client test list'. 

[Steffen Opel _Utoolity_]

This is really slowing me down a lot (and seemingly other Thunderbird users), so I've had another look and found the related MailNews:Message Threading docs - the resp. 'E-mail Threading Primer' paragraph seems to confirm that while Lithium does add the fundamental message ID to each mail, it simply does not use the common 'In-Reply-To' or 'References' headers for RFC compliant threading:

Well behaved mail clients like to put the following headers in, but they are not required:

• Message-ID: A (sorta) globally unique identifier for the message.
• In-Reply-To: Contains the Message-ID(s) of the message(s) this messages is in reply to, assuming the message(s) actually had a Message-ID. (Omitted if the parent didn't have a Message-ID).
• References: Contains the contents of the "References" for the message(s) being replied to, followed by the Message-ID of the message(s) being replied to. If there is no "References", try again with "In-Reply-To" (followed by the Message-ID). Omitted if the fields are missing.

See RFC 2822 for details.

I've been hopeful for a second that reverting my client to the legacy settings listed in Stop threading by subject might help, but unfortunately this didn't work either (would have explained that there is some level of threading in some clients, possibly based on this subject correlation alone).

@Monique vdB, @Test User KL - could you eventually take another look based on the referenced info, maybe that's a comparatively simple setting once one knows what to search for? Given the scope and audience of the platform, and the seemingly straight forward and commonly implemented RFC, I'm frankly surprised that Lithium doesn't seem to do the right thing here by default (based on my still limited understanding of course).

Many thanks!