This may by a dup of bug 35085; I wasn't sure so I thought I'd report it anyway. When an IMAP message is filtered into another folder, and the IMAP delete model is set to Mark as Deleted, the message appears in the Inbox as deleted and unread. This means that clicking Next will read the message in the Inbox. Further, if Mozilla has to download the IMAP headers again, it will filter the delted unread message again. This means that the other folder now contains two copies, one of which is deleted. I know that Communicator leaves filtered messages as deleted and unread so perhaps this behaviour is correct, in which case filters and the Next button should ignore deleted messages.
future. Not fixing this for 6.0
adding mail3 keyword
I don't suppose changing lines 2008/9 and 2051 of nsImapProtocol.cpp would help? - Store(messageIdString, "+FLAGS (\\Deleted)",bMessageIdsAreUids); + Store(messageIdString, "+FLAGS (\\Deleted \\Seen)",bMessageIdsAreUids); Once the message is "read" it won't get filtered again.
hmm, that's a possibility, though I think we'd only want to do that if we were using the imap delete model. The other possibility is to ignore /deleted messages when applying filters, as you say, which I believe is what 4.x did. It depends on what users of the imap delete model would want. Marking them read would fix the next unread problem as well.
marking nsbeta1+ and moving to mozilla0.8
moving to mozilla0.9
marking nsbeta1- and moving to future milestone.
It's been a while since this has been looked at. Is anyone still seeing messages getting filtered more than once?
I've strenuously avoided by compacting folders whenever possible...
No, no more duplicate filtering, but the unread message problem in the inbox is the same.
I don't see that the unread thing is a bug, per se - you haven't read it, and that's the way 4.x worked anyway. Sure, it would be nice to mark it read, but it's a different bug.
Current behavior (20010827, yes I will upgrade soon) when you have "Mark it as deleted" for IMAP delete behavior is to move the messages, mark them as deleted, then remove them from the UI. The next time INBOX goes looking for messages, all the filtered messages come flooding back (I think bug 67172 addresses this). But I never get dup moves. Doesn't that mean this bug is resolved, given the path it has taken recently?
Matt, try this: 1. wait for a message to be filtered. will be unread deleted, yes? 2. quit mozilla and zap your inbox.msf 3. restart mozilla. mozilla refilters the message. n.b. the copy is also "deleted"!
Perhaps after filtering you should do an expunge, or perhaps allow the option for auto expunge after filtering. After a mozilla crash, I always wind up filtering multiple multiple copies into the same folder. *Heavy traffic mailing lists are hairy enough as it is...*
I've just had occasion to create a "delete" filter. Usefully the deleted message is also marked as read. So please can I see the same behaviour for a "move"?
Neil, are you still seeing the deleted copy of the filtered msg left Unread? This WFM with TB0.7 on fastmail.fm.
marking wfm - this was fixed as part of other changes...