I've just gone through the process of creating a new user to get a fresh kmail2 database (because of a different problem). i loaded up kmail 5.4.1 to start the process and added all the folder names and email accounts i previously used on the old user account and it repopulated fine from the ISP accounts. I then looked at the new local email database (called akonadi_maildir_resource_0 for some unknown reason) and i checked all the folders and i was surprised to see old emails from this and last year (that have all been read) sitting in the "new" folder instead of "cur". Does this not go against maildir standards or do i misunderstand the process?
I have explored this problem. Moving messages between local accounts always leave them in the new folder. Once you read or mark as unread the message, they move to the cur folder. Not sure if this is the correct behavior or not.
Have this problem also . Just two days ago I manually moved the (old) new emails into the cur accounts. Do this already for the last 6 month's. It is one of the problems I face but I do not know if this behaviour has any influence on the other more problematic kmail problems like a broken duplicate handling etc. etc. opensuse:tumbleweed:20170620 Qt: 5.9.0 KDE Frameworks: 5.34.0 kf5-config: 1.0 KDE Plasma: 5.10.2 plasmashell 5.10.2 Kernel: 4.11.6-1-default
Please note that if you move messages manually, you will lose tags.
I'm seeing the same problem. Marking mails as read does not always move them from 'new' to 'cur'. The mails as shown as having been read in KMail but on disk they are still stored in 'new'. I'm using KMail 5.9.0 with KDE Frameworks 5.49.0 on Linux. The mails are retrieved via pop and store in a maildir. KMail reports that it is a valid Maildir.
Selecting the mails in kmail and doing ctrl-u to mark them unread and then ctrl-r to mark them as read sometimes moves them from 'new' to 'cur'. Selecting all mail in a folder (ctrl-a) and doing the same does not move any mails, but it does leave quite some mails in the unread state. Those mails are then *not* moved to 'new'.
*** Bug 405353 has been marked as a duplicate of this bug. ***