Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc3.2.2 OS: Linux i use the cachedimap mode. when i get the messages kmail correctly syncs with the imap server and the new mails are marked as unread. but when i get my mails again, then when kmail syncs with a folder, it sets all the already-downloaded/synced mails as read. so basically if you click two times on the get-new-mail icon, all your mails are marked as read.
This is probably a "feature" of your IMAP server. Maybe this server marks all messages which have been read by a client automatically as read. As during the synchronization KMail reads all new messages they would be marked as read by the server. And then when you synchronize again KMail notices that those messages are now marked as read and therefore also marks the local copies of the messages as read. Of course this is just a guess. It might as well be that there is a bug in KMail. Which IMAP server are you using?
UW IMAP version 2001a. i made some tests: i removed the cachedimap account and added a normal imap. let's say i have the folder 'python' where procmail on the server sorts all the mails dealing with python. i check for new mail and kmail shows me that i have 3 new mails in the python folder ( there's '(3)' written next to the name of the folder) so i click on the folder, and i see that the 3 last messages are colored in red. (i don't select any of those 3) now i select a different imap folder. and the '(3)' vanishes. as if there won't be any new mail in the python folder. i click on the python folder and those 3 red mails turned into blue ones. when i click again on the getmail icon, the "(3)" comes back to python. if i enter the folder and then enter a different one, the "(3)" vanishes and i can loop like this forever :) i don't know if this is a bug or not. and btw. i can click on that mail and read it ( that means i fetch that mail from imap ), and if i didn't read it long enough it won't get marked as read. (works as i want ). so i don't think my imap server automatically marks mails as read.
Subject: Re: cachedimap marks all mails as read On Thursday 03 April 2003 19:11, gabor wrote: > UW IMAP version 2001a. > > i made some tests: > i removed the cachedimap account and added a normal imap. > > let's say i have the folder 'python' where procmail on the server sorts all > the mails dealing with python. > > i check for new mail and kmail shows me that i have 3 new mails in the > python folder ( there's '(3)' written next to the name of the folder) > > so i click on the folder, and i see that the 3 last messages are colored in > red. OK, these are recent (not seen). > (i don't select any of those 3) > > now i select a different imap folder. > > and the '(3)' vanishes. as if there won't be any new mail in the python > folder. i click on the python folder and those 3 red mails turned into blue > ones. The color is ok since blue means unread. Don't you see a '(3)' behind the foldername if the folder is selected? > when i click again on the getmail icon, the "(3)" comes back to python. if > i enter the folder and then enter a different one, the "(3)" vanishes and i > can loop like this forever > > :) > > i don't know if this is a bug or not. > > and btw. i can click on that mail and read it ( that means i fetch that > mail from imap ), and if i didn't read it long enough it won't get marked > as read. (works as i want ). so i don't think my imap server automatically > marks mails as read. I do neither.
>> i check for new mail and kmail shows me that i have 3 new mails in the >> python folder ( there's '(3)' written next to the name of the folder) >> >> so i click on the folder, and i see that the 3 last messages are colored in >> red. > >OK, these are recent (not seen). > > > (i don't select any of those 3) > > > > now i select a different imap folder. > > > > and the '(3)' vanishes. as if there won't be any new mail in the python > > folder. i click on the python folder and those 3 red mails turned into blue > > ones. > > The color is ok since blue means unread. Don't you see a '(3)' behind the > foldername if the folder is selected? > no. i don't see it. btw. i have trouble reproducing it.. my 'python' folder behaves as i told, but for example my 'mplayer' folder behaves correctly :( btw. about this bug. are there people using cachedimap ? is it working correctly for them ( i mean the read/unread flag behaviour )
I have the same problem with cachedimap at MIT whenever there is a new check mail all the unread messages are marked as read
Subject: Re: Same here. kmail 1.5.9 (CVS) debian package version 4:3.2.0-0+cvs20030529+orth uw-imapd IMAP4rev1 2000.287 debian package version 6:2003debian0.0304182231-1
I can confirm this bug, same symptoms as described above. It's very annoying and it's among the few things that stops KMail from being a great offline IMAP reader. KMail 1.5.9 (CVS) (debian package version: 4:3.2.0-0+cvs20030708+orth) Cyrus v2.something IMAP server
Cached imap probably comes from the Kolab development? If so we also have a report in our internal bug tracker: http://intevation.de/roundup/roundup.cgi/kroupware/issue320
I'm not sure if I'm reading it right, but that Kolab bug seems to be discussing the server side. I'm convinced this is a client bug, because there are IMAP synching tools (offlineimap, isync, mailsync, etc) that do what KMail's cached imap mode does and they handle flags the right way. Therefore, there must be something KMail doesn't do, or does wrong, that messes up the flag handling.
The bug in the kroupware issue tracker _is_ a client bug Check the "topic" entry. :) So the bug is in the KMail kroupware_branch, too.
the same error is in kde3.2 beta1 (suse 9.0 rpm)
Same problem here with disconnected IMAP. normal IMAP works well. Bug 65005 may be a duplicate of this bug.
I can reproduce this problem also with CourierIMAP 0.37 (Debian woody version). Here it's clear that the (first) synchronization marks the mail as read. (You can see it moving from new/ to cur/ because CourierIMAP utilizes Maildir). Therefore on the next synchronization it's correctly flagged as already read which is incorrect :-). The question now is: Is this courier's or kmail's fault?
Subject: Re: cachedimap marks all mails as read
Yes, I agree. I also tested with evolution and it keeps the messages unread even though CourierIMAP moved them to "cur/". So kmail has to keep the read state for the message itself.
*** Bug has been marked as fixed ***.
After I fixed another bug, this is now back :-(
And now it should finally be fixed.
I have this problem still. Using DIMAP, filtering emails works correctly: I can filter on e.g. a given subject into an imap folder, set the "unread" (or "new") status, and the correct number of unread mails in the filtered folders are shown in parantheses, but upon next mail check, all folders that are synchronized will be reset to include only read mail. I have tried both using the "new" and the "unread" flag. The original bug is from 2004 - should this be filed as a new bug? I don't know how to check the imap version on the server - what command should I use? (I have ssh access to the server and can run pine there) KMail: Version 1.9.1, Fedora Core 5 kdepim-3.5.2-2.0.fc5.kde
Well, this bug is still in kdepim-3.5.4-1.1.fc5.kde, and this bug report is still marked "FIXED" even though it is not.
Maybe the code given in Bug 112724 will solve this? Also see Bug 16204.
Should I mention that I actually STILL have this bug in kdepim-3.5.5-0.3.fc6. (Normal IMAP still works just fine -> not a server "feature"). Could anyone maybe confirm/disprove that the code suggested in Bug 112724 is implemented?