Version: 1.11.90 (using 4.2.90 (KDE 4.2.90 (KDE 4.3 Beta2)), Kubuntu packages) Compiler: cc OS: Linux (x86_64) release 2.6.28-13-generic Checking for new mail / uploading changes made locally can be very slow using a disconnected imap account with many folders. I think is due to the fact that kontact compares for _all_ folders the local version and the version on the server; so if there are many folders, this can take quite some time. However, in many situations, this seems not to be necessary. In my use case, which I believe is a common one, I only have a very small number of folders which are inboxes, i.e. actually receive mails. So when checking for new mail it would be sufficient to look only in these folders and in all folders which have been changed locally since startup. That is, each folder in which a message was added/deleted/changed could be marked as "changed" and added to a list of folders to be updated on the server when the users hits Ctrl+L. When accessing the account from different machines, it would still be necessary to check all folders at startup, since they might have changed in interaction with a second computer. Or is there a way to store a "changed" tag for folders on the server? Anyway, this overall check would be necessary only once, in all subsequent comparisons it would be sufficient to check only inboxes and folders changed locally. I believe this would speed up using dimap a lot.
Should be a wish, shouldn't it? Personally I happen to use server side filtering, so all my folders will change any time without using kmail. So this would be the wrong thing for me. But maybe it could be implemented as an optional feature per account?
yes i agree, it would be a real spead up or a efficient way to update only the inbox. why diff all the other folders several times, over and over add a checkbox / or a folder list for updating
*** Bug 201066 has been marked as a duplicate of this bug. ***
*** Bug 218445 has been marked as a duplicate of this bug. ***
*** Bug 243420 has been marked as a duplicate of this bug. ***
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented. Thank you for your understanding.
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.