I wish Thunderbird Threading behaviours was easier to set but it is not, you need to use below variables to do so...
All core threading logic currently lives in
mailnews/db/msgdb/src/nsMsgDatabase.cpp. It is controlled by the
following preferences:
- mail.thread_without_re : Thread by subject even when there is no "Re:" in the subject; default False in 3.0, used to be true in 2.0.
- mail.strict_threading : Don't thread by subject; default True for 3.0, used to be False in 2.0.
- mail.correct_threading : Thread things correctly (using References/In-Reply-To) regardless of the order in which messages are added to a folder; default false. Requires extra memory and some extra processing once a folder (nsMsgDatabase) has new messages added to it. If you turn this on, you really should turn on strict_threading too.
mail.thread_without_re
mail.thread_without_re (gThreadWithoutRe/ThreadBySubjectWithoutRe)
defaults to False in Thunderbird 3.0, used to default to True in 2.0.
If mail.thread_without_re is True, the subject does not have to
start with "Re:" (or variants or localized variants) for threading to
occur. If it's false, it does have to start with "Re:"/variants.
mail.strict_threading
mail.strict_threading (gStrictThreading/UseStrictThreading) defaults to True in 3.0, used to be False in 2.0.
If mail.strict_threading is True, subject-threading is disabled
entirely. Messages sent by clients that do not generate
"References"/"In-Reply-To" headers (or responding to clients that do not
generate "Message-ID" headers) will not be threaded.
If mail.strict_threading is False, then we will attempt to thread
using the subject. Whether we require the subject to start with "Re:"
(or variants) depends on the "mail.thread_without_re" setting.
mail.correct_threading
mail.correct_threading (gCorrectThreading/UseCorrectThreading) defaults to True in 3.0. Implemented by bug 181446, only available in 3.0 releases and later (never on the 2.0.0.x branch).
If mail.correct_threading is True, the references stored on every
nsIMsgDBHdr are used to populate a hashtable mapping every Message-ID
we have heard about for a thread to that thread's thread id. For
example, if message D with Message-ID: D and thread id of 42
"References:" C, B, and A, the hashtable will map C, B, and A to 42.
Having this mapping allows us to do two things we could not
otherwise do (as things are implemented...) in order to thread messages
correctly regardless of the order in which they are added:
- Thread messages together with common, but missing (not in the folder), ancestors. Otherwise, they would end up in different threads.
- When we process one of those missing ancestors, detect it and properly add the message to the existing thread. (At least as long as there are less than 1000 messages in the thread.)
The hashtable is an in-memory-only structure, and is populated by
processing all of the existing messages the first time access to the
structure is required. This means that the overhead of traversing the
messages and extra memory usage should only happen when adding new
messages to an nsMsgDatabase.
nsParseMailbox.cpp sets the references via
nsIMsgDBHdr::SetReferences using the "References" header as a first
choice, and the "In-Reply-To" header as a second choice.
(nsNNTPNewsgroupList.cpp and various compose pieces of functionality
also call SetReferences, but they are not processing incoming e-mail.)