I very much agree. Messages having a common sender and subject is very common for things like order confirmations and invoices, but they are distinct messages and shouldn't be grouped together. However, I don't want to disable conversation group since it's a very valuable feature for actual conversations.

I'd hope that there is a way to group conversations using more unique values, perhaps in the message headers. At a minimum, have options to put an age limit on grouped conversations or allow the ability to exclude items in Trash from being grouped.

Yes please implement this. Current implementation of conversation grouping is pretty useless for me or even more an annoyance than helping with anything. Also let me allow to define if new messages should be on top or bottom.

After my import from gmail completed, I discovered that a large amount of my existing conversation threads were disconnected from each other, making it unusable for me. I love so many things about Proton, but unfortunately I will not be able to fully switch over until this is addressed.

After testing for a month, this drove me away from using Proton. It defies belief that people have explained in clear and simple terms how to do the product correctly (i.e., how every other email provider does it) and Proton have done nothing about it. They surely use their own product so they must see how annoying conversations are. Until now they didn't have much competition in the E2EE space but now they do, and the competitor handles conversations the correct way.

"I concur. When using email services for business purposes, you often receive (and send) emails with similar subjects that are otherwise unrelated. This is especially true if you do sales via email. In my case, I send approximately 10-20 emails a day to different clients, all with the same subject.

Right now I am forced to use a third-party email client (and Mail Bridge) to be able to differentiate conversations easily, which in several ways disrupts my workflow.

I understand that the reason for Proton's handling of conversation grouping is that you don't read the body of the emails (as stated here: https://proton.me/support/disable-conversation-view).

However, this shouldn't prevent the addition of an option in Settings to restrict the grouping to conversations that have both the subject and the sender/receivers in common.

Please add this feature.

Conversation grouping should also be able to handle replies. They are prefixed with "RE: <SUBJECT>". This makes Proton very difficult to use at the first reply to a conversation creates a new grouping.

yes yes yes. grouping should only be for messages that are directly related to the other by a reply. It should not group all messages that simply have the same subject.

The lack of this feature is the only thing that keeps me from switching to proton since years. :(

The actual implementation of conversation groupping is buggy with presented with mailing lists that modify the subject, like:

[Python-Dev] Python multithreading without the GIL
and
[Python-Dev] Re: Python multithreading without the GIL

making it very frustrating if not unusable.

Protonmail support tells me: « this is indeed how the conversation grouping feature works ».

I'm infuriated.

+3 to this. My dilemma is either I miss emails in conversation view, or my inbox is a mess in linear view. This will drive me away too, eventually.

I completely agree. The lack of this feature is what will ultimately drive me away from PM.

+1 to this one. Threading is severely lacking. Is there a shortcut to jump to the next message within that grouping? I couldn't even find that.

This fix would really clean up my inbox. Right now, I'm having to search through each email individually to see who I've replied to, where our conversation left off... it's really getting messy and the folders only help to a point (I'm basically building my own threads through folders - not fun). "Conversation Threading" would help immensely.

Also, because I have people emailing me from my website, they all have the same subject line. I need to be able to organized the conversations by the sender at the very least. For example, I have 100 emails from 50 different people mixed under one thread. It makes it hard work to organize.

If this got sorted, I would move my gmail to Proton mail.

For a really good description of what is wanted, scroll down to the section titled "Why use Mutt?" on this LWN article: https://lwn.net/Articles/837960/

I'll note that in my experience Thunderbird also correctly displays threaded conversations.

I fully agree.

Conversation threading should indeed use the "In-Reply-To" header as aggregation key. Alternatively:
1) folder/label should be added to subject and sender/recipient as grouping criteria
2) we should be able to edit subjects (https://protonmail.uservoice.com/forums/284483-feedback/suggestions/34117900-ability-to-change-subject-of-received-mails)

I agree. I really miss this feature. Just having "dumb" filtering on sender and subject is not producing the desired result. Examples:

Invoices sent with subject "Invoice from *name of club* " will be grouped as a single thread, making it very difficult to find the latest invoice (especially when combined with a search function that does separate trashed messages in the result (https://protonmail.uservoice.com/forums/284483-feedback/suggestions/39908797-filter-out-exclude-trashed-emails-from-searches))

My kids teacher sends out weekly reports on what's the class has been up to. The subject is (translated) "Weekly letter #24". The current filter will group the new message with the one, completely unrelated, sent one year ago.

I really agree with this!! I'm new on ProtonMail and I really miss this feature!

This is definitely a huge pain point, urgent enhancement needed!!!

If mails are grouped, only those should be grouped that a) mention / quote another mail OR b) if the mails arrived within x minutes.

Because as it is at present with me mails are grouped which were sent years(!) after each other. They also have nothing at all to do with each other. Only because both have the same title.