Version: (using KDE KDE 3.5.1) Installed from: Gentoo Packages Compiler: gcc version 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8) OS: Linux I've setup a few filtering rules, e.g. <X-Spam-Flag>: YES, and some of them move messages to other folders, e.g. Trash, on incoming messages. When I get new mail the filters are applied perfectly and moves the messages accordingly. However, in the process the filters also mark every message they have looked at as read. In some sense this is true since the messages have been read by the filters, but they should only be marked as read when _I_ have read them. I'm using IMAP, btw, if that's important.
Does it help adding another filter action to the filters like mark message as unread? But I agree the normal behaviour should be that the messages remain marked unread unless the filter is set to mark them as read.
Well, it helped somewhat. All messages that matched a filter are now marked as unread, but all messages that didn't match a filter are still marked as read. I tried creating a new empty filter that would match all messages and mark them as unread, but it doesn't seem to work. Is there a way to create such a filter? If so, that would be a good workaround.
*** Bug 126628 has been marked as a duplicate of this bug. ***
I have the same problem over here. Using kmail with disconnected IMAP, and several filters which move messages to folders based sender, subject, etc. Only messages which are not matched (e.g. stay in my inbox) are marked as "unread". When the mail first arrives, I can briefly see it as "unread" (for just a fraction of a second) in my inbox before the filter moves it to the corresponding folder, at which point it is marked "read". BTW I'm not using procmail or any other filtering program, just kmail. I have added the actions "Mark as Unread" and "Mark as New" after the rule which moves the message on a match, but it is still marked as read. This is a serious bug; without proper notification, messages are missed. I had to go through 20 different folders yesterday to catch up on 2 days worth of mail. This type of filtering is essential for my work, so until there is a fix I have no choice but to use a different email client. System info: Qt: 3.3.6 KDE: 3.5.2 KMail: 1.9.1 gcc version 4.1.1
I can confirm the exact same scenario as in comment 4, using dIMAP and no procmail. Needless to say, this is a huge problem for me. System info: Fedora Core 6 kdepim-3.5.5-0.3.fc6 Qt: 3.3.7 KDE: 3.5.5-1.6.fc6 KMail: 1.9.5 Pleas also see: Bug 56792 "cachedimap marks all mails as read" Bug 16204 "kmail marks unread as read upon filter transfer" Bug 99861 "kmail marks messages as read when syncing a dimap mail folder" Bug 104320 "status flags of messages of a DIMAP account get lost on synchronizing via check mail" Bug 112724 "Error reading message status (read/unread) in maildir folders" (this report propose a fix in the code. Nobody has yet tested this)
*** Bug 134638 has been marked as a duplicate of this bug. ***
I can also confirm the behavior on Gentoo (KDE 3.5.5 and 3.5.6, KMail 1.9.5 and 1.9.6) As the previous posters note, this is a _major_ problem an I'm also considering moving to another mail client.
I'm using filters on a disconnected IMAP account and I haven't seen any message marked as read after it has been filtered into another folder (local or another dIMAP folder). Can anybody please describe an exact scenario about how to reproduce this with KMail 1.9.6? What filter actions are been used? What accounts and folders are involved? It would help a lot if you can keep the number of folders and filters on a minimum needed to reproduce the problem.
More info on the kdepim-users mailinglist: "kmail makes no difference between new and unread" http://thread.gmane.org/gmane.comp.kde.users.pim/8518 I'm having alot of subfolder that I sort messages into, and have a slow internet connection - that's why I'm able to briefly see the messages marked as 'new' before they turn 'read'. Here's one testfilter I've tried that gives this behaviour (from ~/.kde/share/config/kmailrc): [Filter #2] Applicability=0 AutomaticName=false ConfigureShortcut=false ConfigureToolbar=false Icon= StopProcessingHere=true accounts-set= action-args-0=.1326281828.directory/.mail.directory/fedoraforum action-name-0=transfer actions=1 apply-on=check-mail,manual-filtering contentsA=filtertestXXYZ fieldA=Subject funcA=contains name=<Subject>:filtertestXXYZ operator=and rules=1
This problem seems to be solved in kdepim-3.5.6-6.fc6. After upgrading, KMail crashed severly and wiped my local dimap cache (this happened when I pressed Ctrl-J to filter the last collapsed thread of messages in my inbox). I backed up some stuff, and restarted KMail, had to re-enter all my IMAP folder subscriptions, and update all my filters (they pointed to non-existing folders with some numbers in them), but now - new messages are no longer automatically marked as read upon filtering :) There is one peculiarity though - after a message has been automatically filtered into a subfolder, I can (correctly) see a bold number next to the folder increase by one, e.g. showing "(1)", but then KMail "synchronize" the folder or something, and the new message disappears from the subfolder (the bold number also disappears), and then it comes back again (and so does the bold number). The new thing with KMail 3.5.6-6.fc6 is that it is still marked as new (as it should be). The scenario described here all happens within seconds depending on the connection speed. Another thing to notice, is that my folder structure in KMail has changed: in kdepim-3.5.6-6.fc6 all subfolders are directly under my "inbox" (which is nice) In the previous versions I have had a folder "mail" as the parent of all my subscribed subfolders. Also, I seem to recall that I had a file in my homedir on the IMAP server holding a list of all subscribed folders. I had some issues with folders starting with "~/" or not in that list. (that file is gone now, and I have forgot the name. But "grep name_of_subscribed_folder .*" should find it if you have it I think) Maybe this was the root to all the problems in the first place? Anyway, just wanted you to know the great news :)
Okey, it seems that this wasn't the kdepim update that solved my problems after all; the IMAP software was changed on the email server. For what it is worth, here is the reply from the admins when I asked for some technical details: "Your account was moved from a server with UW-IMAP, to a server with Courier IMAP. There is also a Perdition proxy between the clients and the two servers, in order to load balance the users." What kind of software are you other guys running on the server side? Could this be a UW-IMAP specific bug? (Personally I don't know what UW-IMAP is, nor do I know how to get info about the server. But the good thing for me is that my problem is solved ;))
I have the same problem as mentioned in comment #4 using KDE 3.5.6 on Kubuntu.
Similar issue here running KMail 1.9.6 on Kubuntu, difference is that in my case, unmatched messages are also being marked as read, as long as they go through the filter. Makes using mail really hard as I have to scour the recent threads every hour or so to make sure I haven't missed any new messages. :-(
*** This bug has been confirmed by popular vote. ***
I find that this issue happens when the currently viewed folder is the incoming mail folder. Essentially what is happening there, is that the e-mail is brought into the folder and whichever one ends up automatically being selected for display is marked as read, because technically, it was displayed. But, it was not actively selected or viewed. So whenever I have a filter that moves anything out of that folder, I have it marked as unread after it is moved. And, if you are performing filter operations in an incoming mail folder that can commonly be expected to display, you can expect messages to be marked as read. So, it may be best for KMail to not mark incoming messages as being read just because they are displayed. It should only mark them as being read when the user actively selects a message for display.
Regarding comment#15, is that problem a duplicate of 125743?
*** Bug 125743 has been marked as a duplicate of this bug. ***
ease report whether the problem still exists in KDE 4.3
I can't reproduce it in 4.3.4. It must have been fixed along the way. As the original reporter, I will close this as fixed. If somebody else is still bitten by it, feel free to open it again.
I experience the very same problem with Kmail 5.1.2. Problem: I used kmail 4.14.10-3.10 and had filter problems (filters vanished). I upgraded to 5.1.2. The problem with the filters remains valid but now I am hit by the very bug described here. I use pop with local folder to where the messages are filtered. The filtering works in 5.1.2 but the messages (signed by color code as unread) are not signed by darkening the folder name in which they are. Normally a number should be noted behind the folder to indicate the numbers of the unread messages. This does not happen. Also the tray does not indicate new messages. Now come the interesting part: you can now read (by searching manually) one of the new messages. The message will change color code to read, and now, magically but unfortunately only for that very folder, the number of all unread messages appears, the messages are also signed now correctly in the tray. But ONLY for that folder. All other messages in all other folders are seen as "read" even if inside the folder they are marked as unread. Setting to open. As this is a very old bug I can open a separate bug if desired. You will tell me.
I experience the very same problem with Kmail 5.1.2. Problem: I used kmail 4.14.10-3.10 and had filter problems (filters vanished). I upgraded to 5.1.2. The problem with the filters remains valid but now I am hit by the very bug described here. I use pop with local folder to where the messages are filtered. The filtering works in 5.1.2 but the messages (signed by color code as unread) are not signed by darkening the folder name in which they are. Normally a number should be noted behind the folder to indicate the numbers of the unread messages. This does not happen. Also the tray does not indicate new messages. Now come the interesting part: you can now read (by searching manually) one of the new messages. The message will change color code to read, and now, magically but unfortunately only for that very folder, the number of all unread messages appears, the messages are also signed now correctly in the tray. But ONLY for that folder. All other messages in all other folders are seen as "read" even if inside the folder they are marked as unread. Please reopen this bug, It seams I cannot do it as I am not the reporter. As this is a very old bug I can open a separate bug if desired. You will tell me.