Unfortunately I can only reply 3 times to a post here hence a new post:
I have now transferred the postbox responses to EM Client manuell
Here are a few things that are still missing or bugs that I have noticed:
for the “Quick actions” it would be helpful to have an “Action” = “Determine sender address”. Reply address alone does not always help.
if i send a mail to several recipients (even if one of them is only CC) with the variable “Full Name”, eM Client wants to split these mails. I would like to have an option to set that only “To” is taken into account for the variable. CC is usually only an info, the recipient does not have to be addressed by name.
i want assign file extensions to certain programs. For example, I don’t want .ics to be opened in eM Client, but in Apple Calendar.
i still have the problem that conversations are summarized incorrectly (see attachment).
So apparently not all important parameters are taken into account. How can we solve this, but I cannot provide you with privacy-problematic mails for viewing?
an option to delete not only spam after XX days, but also the trash would be very helpful.
a shortcut for “Show source text” and “Mark all messages as read” would be helpful
“Expand all” and “Hide all” for the folders: It would be helpful if i could only do this for each mailbox/main folder not for all folder on the right side.
the “Deferred” folder disappears with every restart, so it has to be reactivated under “Show”.
I’m sure I’ll notice a few more things, so I’ll let you know
@Michal_Burger And can it be that the filter rules are only applied to the mails that come into the inbox?
I use filters to move mails to different folders directly at my mail provider and then mark it with labels and/or as read in the respective folders via Postbox. It worked without any problems in Postbox!
In eM Client, however, nothing happens with the filter rules. 2 examples:
Can it be that the filter rules are only applied to the mails that come into the inbox ?
Yes normally rules in eM Client only automatically apply on new emails arriving in the Inbox. So you can then setup and automatic rule to move to folder on arrival and set a label / tag to that rule.
Note: Currently for rules to work automatically, they “have to be unread messages in your Inbox”, but that might change in future versions as I know there is users who want rules to automatically work even if already read by another device. @Michal_Burger can advise on that.
@Michal_Burger This is currently the most serious problem and is a major hindrance to work. It is actually not usable. It worked in Postbox for 10 years without any problems!
As you can see from the screenshot, almost 1860 conversations are summarized here, but they do not belong together (different sender/recipient, subject, etc.).
I still have several examples of this, EM Client does not seem to separate the conversations properly here. This was never a problem with Postbox.
You did not provide any reasonable information to diagnose the isse. Screenshot with a number is not something we can use to diagnose the issue. I would suggest trying to repair folders where the messages you see in the huge conversations are located:
On servers that natively implement conversation threading we always rely on the information sent by the server. This includes Gmail, Microsoft Exchange (and Microsoft 365), and IMAP servers implementing the OBJECTID extension (RFC 8474). In those cases we will use the grouping done by the server since it has the most accurate information and we want to match how the conversations are presented in webmail and other email clients.
For servers that don’t natively report conversations, we do not group messages with the same base subject into the same conversation, so we would need to see the headers of at least two messages that got grouped together and that you think should not be grouped.
The base subject is loosely based on the definition from RFC 5256. It’s stripping any prefixes like Re:, Fwd:, Re[5]:, but also anything that looks like a mailing list name in front of the actual subject enclosed in [/] brackets (eg. Re: [Tinycc-devel] Tinycc-devel Digest, Vol 134, Issue 18 has a base subject Tinycc-devel Digest, Vol 134, Issue 18).
The part of the algorithm that strips the mailing list names is unfortunately prone to also strip some prefixes created by ticketing systems that include the ticket number as prefix like [666], [!666], [*666], [EM-666] or similar. This is problematic case that’s non-trivial to detect and handle because it goes against the established email subject format recommendations.
We also don’t group JUST by the base subject, it is only one of the criterias but a necessary one, ie. if the base subject does NOT match we never group it. Other criteria include the sender/recipient (which also often happens to match for the ticketing systems), email threading headers and other heuristics.
hence a new post:
