Depending on the country of the sender of the message, when someone replies or forward a message, the prefix on the subject changes. example, a reply in Portuguese reads “RES”; in english “RE”, in german “AW” and so on.
MS Outlook recognizes all these different headers a reply, regardless of the used language. as such, it correctly sorts the messages by subject. emClient, instead, sees these prefixes as real subjects. so, lets say we have message which subject is "Customer Support:
AW: Customer Support
RE: Customer Support
RES: Customer Support
point is if we sort the message list by subject, the german message will appear in the top of the list while the others will not be placed quite below in the list. the three should be part of the same thread instead!
why cant emclient show thi?
Unfortunately, what you described is a default setting of eM Client. I will now change this topic to Idea so other users can add their vote for this feature and it will be considered while developing the next updates.
I would like to add, that this problem could be easily avoided if Emclient properly use “References” and “In-Reply-To” headers set by other MUAs. Properly - i mean use it to find threads and build conversation view on this, not by using only “Subject” header (which is short sighted and simply wrong).
The same problem is when something change Subject, eg. some MUA clean multiple Fwd: Re: Odp: AW: in Subject (eg. Thunderbird with some addons) or user fix spelling error in Subject, then Emclient suddenly lose context (it sees these emails as different threads - which is wrong).
Maybe, but every mail which changed Subject more than remove/add Re: or Fwd: is seen as different thread.
Check it Yourself: Write email to yourself with Subject “Tets”, reply to it and change proposed Subject from “Re: Tets” to “Re: Test” - your own reply is not seen in conversation.
The same is when someone change Subject beyond some Emclient heuristics.
Proper working should be:
a) use References as base and when there is References header, then do not check further.
b) check In-Reply-To header, maybe some broken MUA set it, but did not set References,
c) if there are no References header, make some heuristics based on Subject (or other headers).
Now i do not see no signs of a) and b).
Contrary to popular belief the “RE:” is not prefix for “reply”. It comes from Latin for “in re”, or “in the matter of”. The relevant standard for this is RFC 5322, section 3.6.5.:
When used in a reply, the field body MAY start with the string "Re: " (an abbreviation of the Latin “in re”, meaning “in the matter of”) followed by the contents of the “Subject:” field body of the original message.
We recognize that this practice wasn’t properly followed by all email clients and that internationally different prefixes are used. We keep a list of the most common ones and treat them equally to “RE:” for the purpose of grouping conversations or cleaning subjects on reply. Our initial list came from a large data set of email, our localizations, and the same list in Thunderbird (http://kb.mozillazine.org/Reply_indicators). As of version 7.1, the list is the following: “re:”, “aw:”, “sv:” and “vs:”.
The details of our algorithm as subject to change, but we do take “References” and “In-Reply-To” into account.
However, we do also require the base subject (https://tools.ietf.org/html/rfc5256; subject stripped of all the mailing list headers, “re”, “fwd”, etc.) to be identical. This is a precaution to handle situations where people just blindly hit reply to write new emails to specific people. Unfortunately, that happens often enough throughout our datasets.
Secondly, we use heuristics similar to Gmail based on the subject and people involved in the email (From, To, …). We need to do this because often we don’t have full information about all the user’s emails. Typically this is the case when we only have the Inbox synchronized and Sent folder is not synchronized yet. In that case, the In-Reply-To header is basically useless since it references only the message we haven’t downloaded yet.
Yet Thunderbird use References to detect propert thread in first place: http://kb.mozillazine.org/Stop_threading_by_subject
By default Thunderbird tries to groups messages into threads in the following order:
Common reference in the References header
Common reference in the In-Reply-To header
Same Subject, and the Subject contains Re:
Same Subject
Check if the message is an ancestor of an already-threaded message.
There are several settings that manage threading that can be changed using the Config Editor at Tools -> Options -> Advanced -> General.
mail.thread_without_re will thread based on the subject even if there is no Re: in the subject. It defaults to false starting with Thunderbird 3.0.
mail.strict_threading disables threading based on the Subject and only uses the References/In-Reply-To headers headers to determine threads. It defaults to true starting with Thunderbird 3.0.
mail.correct_threading will thread messages correctly using the References/In-Reply-To headers regardless of the order the messages were added to the folder. It defaults to true starting with Thunderbird 3.0.
mailnews.localizedRe defines a comma-delimited list of alternative prefixes to “Re:”
PS. I appreciate all work, because Your client is one of the best in this market, but use of Subject only or mainly for threading is a serious bug for me and only stopper before buying personal license.
Thanks for response, but this sentence is wrong for me:
However, we do also require the base subject (https://tools.ietf.org/html/rfc5256; subject stripped of all the mailing list headers, “re”, “fwd”, etc.) to be identical.
You can never ever ensure the same message Subject from another person. This is basically wrong assumption.
And i could live with more emails in “wrong” (better word should be “old” or “original”) thread/conversations contrary to “lost” emails, which do not show in any conversation or split conversation at every Subject change. Of course this is my personal opinion.
But, there is a way for everyone happy, please make configuration option (checkbox to on/off or combobox with more options) to use References in first place and reindex database/conversations for this purpose.
Is there any work on this subject, any plans?
I receive many emails after some minor title change, which start new conversation, even when they have proper References: field (event that sent from Outlook nowadays have this field set properly).
I did not interpret Filip’s post to imply that ANY message with the same Subject would be grouped with the original thread. I read that he said it MUST be the same in order to be grouped - along with other requirements being met. Perhaps I got it wrong. But I for one would NOT want messages with a different subject appearing in the thread.
That said - I do agree with the last comment - configuration options are always best. But I have no idea how much time/effort/resources would be involved. And I’ll repeat it here - I have read a fair number of posts with features that IM[!]HO are much more “core” and should be handled before such advanced enhancements.
David, but it is what i observe. I’ve got two completely different emails from the same person, but the same Subject and emClient join them together which is wrong to me.
Email threading is crucial for serious communication which needs to not mix different threads because it cause mistakes - and i did because of wrong conversation view.
Situation is even worse with OP problem, when i’m discussing with people using polish localized clients which do not use Fwd/Re international prefixes but Pd , Prz or Przekazano (=Fwd) or Odp (=Re).
Every email from them goes as another thread/conversation and i’m lost at more than few of them. In this situation i have to use Thundebird (or another good working client) as backup to view proper thread, but this is very uncomfortable.
You absolutely make a valid point Sylwester! I didn’t realize EMC group messages like that, and IMHO that’s a bug and should be fixed immediately. However, I don’t personally think messages with different subjects should be grouped. But that’s a fairly UNinformed opinion on my part - I really shouldn’t have made my comment because the fact is my only experience with email topics like this goes back decades and involved configuring email on Unix systems - so I really don’t know what the email protocols define to provide the “reference” you mention. SO - my opinions are UNinformed and I truly regret posting. I don’t like it when others do it - and here I am doing the same. Sorry for that everyone.
I do hope EMC fixes the issue tho - and I honestly think if you can demonstrate the issue you mention that they would jump to fix it.
If you have paid for a license you should check with tech support and other channels, this is really only a peer-to-peer support forum. I see that employees do check in from time to time but honestly I doubt you will make a good case for yourself here. (just trying to help)
I understand, and I faced the same quandary! But every other MUA I evaluated had more serious issues, and less accessible support resources.
However, if I may offer another suggestion, that is to contact the sales department. I did this myself just a few weeks ago and I got a very quick reply with some good information. I also got some answers to questions which clearly had to come from the development department (and others). Which means the sales rep most likely can and will bring your question to development to see where they stand on the issue. Just a suggestion.
PS: I do not work for EMC and have no connection to them or the app. Also I am not an expert on anything and my advice should taken as personal opinion only!
It looks like one problem (not OP one) is solved. In newest version (7.1.32792.0) there are no signs of joining different (not referenced) messages with the same Subject. Thanks for Your work, I really appreciate it.
I have to take last “success” back.
In version 7.2.34711 i’ve got two different messages/threads with the same subject and emClient shows them as one conversation, which is very wrong.
It have to be fixed, even Microsoft goes back from their own threading and use References fields properly.