I want to check all my IMAP folders for new mail, so I use the user_pref("mail.check_all_imap_folders_for_new", true); entry in my prefs.js. I have an IMAP/SSL account which is checked for new mail regulary (every 10 minutes). Sent mail is put into another IMAP folder within the same account, like the following structure: Account |- INBOX (<-- new mail comes here) |- SentMail (<-- sent mail is put here) |- Another Folder... When I compose a new mail and sent it, I get a "Andreas.Buschka has 1 new mail" message the next time Mozilla checks for new mail. This did not happen with Mozilla 1.0+. This is pretty annoying since I have to open my mail & news window and go the SentMail folder to remove the icon the the windows tray bar.

Another problem: If you have specified a special folder within that IMAP account to which deleted messages should be moved, the following problem occurs: 1. Go to a random folder and delete some messages, say 10. 2. Wait for mozilla to check for new mail. Expected Result: No "Andreas.Buschka has new messages" message Actual Result: "Andreas.Buschka has 10 new messages".

which build are you using?

...already tried to create a new profile? (are you using your 1.0+ profile with your current build?)

I am using Mozilla 1.1 Beta (the beta release build, not a daily one). Yes, I have already tried a new profile.

I get this with 1.1 final release. 1.0 was fine. It makes the 'new mail' message, which was useful, meaningless. (I'm using Windows 2000, IMAP mail)

The same with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 As to profile it seems to came from previous time but IMAP account is freshly created. I use Cyrus IMAP server with alternative namespace, i.e. special folders such as 'Sent', 'Drafts' and 'Trash' reside at the same level of hierarchy as 'INBOX' do. On my opinion these spesial folders should be excluded from list of folders that are checked for updates.

One more obsevation. Deleting message (i.e. putting it into Trash), filing message in certain folder also couses new message notification. For example, I'm reading newsgroup and then store certain message in IMAP folder. And notification arises in spite of the fact that message is marked as read. It seems that during the check amount of messages or some other criteria are checked instead of checjing the read/unread status. So I believe that new message that comes as read should not make notifikation.

This happens when I delete mail (which automaticly moves it to the trash folder) or when I manually move mail between folders. MailNews will later report that there is new mail, place a green arrown on the account but fail to indicate in which folder to "new" mail resides. I've seen this for many weeks now but have been too lazy to file or find the bug report. I'm doing that now and have found several candidates. I sure I will be dup'ing this or several other bugs soon. I believe that although the complains and proposed remedies are different, the root cause of this bug and bug 156830 are the same. Bug 156830 suggests that MailNews should indicate which folder has "new" mail. (I dissagree) This bug suggests that no new mail notification should occur at all under such circumstances. (I agree) It would be best to argue the merits of both remedies under a single bug.

*** Bug 156830 has been marked as a duplicate of this bug. ***

*** Bug 158196 has been marked as a duplicate of this bug. ***

*** Bug 119647 has been marked as a duplicate of this bug. ***

*** Bug 165838 has been marked as a duplicate of this bug. ***

> This bug suggests that MailNews should indicate which folder > has "new" mail. (I dissagree) I have filters on my mail server that categorize email messages and store them into different folders. If MailNews didn't indicate which folder has new mail I would no longer be able to use it.

6e77a 70 6e 6e7a, From what I understand, the "mail.check_all_imap_folders_for_new" pref is now depricated. You can now achieve the same functionality through the UI: Just right clicking over each folder for which you want new mail notification. Select "Properties." In the "General Information" tab, chechmark the "Check this folder for new messages" option. MailNews will now indicate whether or not the folder has new mail. (Bug 156830 should have been resolved as invalid.) The real issue here is that new mail notification should only happen when truly new messages arrive ... but not when exsisting messages (read or unread) are moved from folder to folder. In your case the new mail notification should go off because the messages are truly new regardless of whether they are filered or not from the inbox to another folder. In my case, when I run a filter that move exsisting messages between folders, delete exsisting mail, or manually move exsisting mail from one folder to another, the new mail notification should *not* go off. I hope this clears thing up. If I'm mistaken, please let me know.

Okay, I've given some thought to this. The new/non-new status of mail needs to be calculated at the account level. Messages should be marked as "new" from the time they first arrive in the account to the first time they are read or marked as read. Note that "unread" does not equal "new"! A read message can be remarked as unread but it's non-new status should remain the same. This new/non-new status should be preserved even when the message is moved from folder to folder just as the read/unread status of messages is preserved. Folders should display the "contains new mail" indicator based only on the new/non-new status of the messages it contains regardless of whether any message happens to be new or not to the folder itself. Likewise, *new mail notification (biff: "<account name> has XX new messages") should only go off when "new/fresh/unseen-before" new-status mail arrives in the account.* For the most part, the above mirrors the current behavior of the read/unread status of messages and its corresponding folder indicators. Whatever logic (not "code" but "logic"!) is being used to manage the read/unread status should also be used to manage new/non-new status. Question's for spin-off bugs: 1) Per-folder biff's ("<account name> has XX new messages in <folder name>") If an RFE doesn't yet exist for this, I'm sure one will soon. Should this biff go off only when new status mail (new account-level mail) is moved into the folder or when any message that is new to the folder (new folder-level mail) appears? (I'm not confident in my gut feeling that the former should prevail since it preserves the read/unread status model I've been following but what about manual filter runs on existing mail???) 2) Moving messages between accounts Currently, read messages moved between accounts remain read. Following this model, should non-new messages remain non-new when moved between accounts? (Maybe the fact that read messages moved between accounts remain read should be considered a bug. If so, non-new messages should become new when moved between accounts.) Okay, that's my $12.99 analysis of the situation. I hope I haven't ticked off anyone ... just wanted to help.

I really like the approach described in comment #15. If done correctly, it might also fix bug 174395 -- "Folder has new messages" mark should survive restart (or crash).

*** Bug 191978 has been marked as a duplicate of this bug. ***

#183377 is a duplicate of this bug The summary is quite complicated, not easy to find.

*** Bug 183377 has been marked as a duplicate of this bug. ***

Hi All, I've given my tupence worth in bug 183377, but I'd like to add something here. Ian, In comment 15, you talk about moving message between accounts. I would suggest that a read email in one account should not be considered read or new when moved to another account. This is something I do every day (I have work and home IMAP accounts, but sometimes emails get misdirected (usually due to me picking the wrong account when sending!!!) and need to be moved about. Also, I have a procmail system to filter my regular contacts such that the email for them goes into their own folder. This rule applies to incoming and outgoing emails that I've BCC'ed to myself. When these BCC'ed emails appear in the contacts folder (or by default into the Sent folder if no matching contact is found by procmail), this triggers a new mail notification. The folder is not highlighted as procmail marks the BCC'ed messages as read (the folder indicator is really just "how many unread messages in this folder, right?). So the folder indicator and the new mail indicator (the green icon in the mozilla quick launch area (bottom left) and the system tray under windows) are not as tandom as you seem to make out. Perhaps I'm missing something. But anyway, my BCC'ed mails that come in, in my opinion, should not trigger a new mail notification, regardless of which folder they go into (i.e. don't treat Sent as a special case, as it could be *any* folder). I think I see the need for some new account-prefs. [ ] Treat incoming but read mail as new. And new general mail prefs [ ] Preserve read status between accounts. If the former option above is implemented, how do you mark which folder that message is in? As I said above, the folder marker is (AFAIK) just an indicator of how may *unread* messages are in a folder. If an incoming mail is marked as read (by procmail), how do you flag the folder. Perhaps Mozilla should automatically mark it as unread? But thinking about it, when Moz borks on a folder and redownloads the headers, this may have the effect of marking them all as unread, which is obviously not desired. Having written the above and thought about it, I'm increasingly of the opinion that if a message is marked as unread, then just ignore it.... For what it's worth, I think the Unread mail indicator is useful as it stands. If this were replaced by a new/un-new indicator, I think that would be a step backwards (have I understood you wrong in comment 14 Ian, where you say <QUOTE>Folders should display the "contains new mail" indicator based only on the new/non-new status of the messages it contains regardless of whether any message happens to be new or not to the folder itself.</QUOTE> - besides, I disagree with this due to my BCC self setup - I don't want to be told 5 mins after I send a mail that I have a new message, I /know/ I'll have a new message, but I want to ignore it!!) Hope this helps the discussion. I may be inaccurate in several areas, or have too custom a setup to be helpful, but hopefully not! Col.

Collin, I'm not sure if you quite understand what I'm suggestion. Right now there are *two* separate indicators in mozilla mailnews and thunderbird, one for unread mail and another for new mail. Using the Modern theme in the latest build of Mozilla and the classic theme in thunderbird, the unread mail indicator takes the form of bolded folder names and message headers while the new mail indicator takes the form of a green down arrow (Mozilla) or orange star (thunderbird) superimposed over folder and envelope icons. I'm not suggesting that the new mail indicator should replace the unread mail indicator or that the unread indicator should be changed in anyway. I agree with you that the unread indicator is perfectly fine as it stands. It the green arrows and orange stars that are not behaving as many would expect and it is only that behaviour and the accompanying new mail notification that I would like to see refined. I can appreciate how my suggestion might cause you some pain considering the way you use bbc, however, I believe yours is a special case that would be best addressed in a new bug. IMHO, new mail is new mail even if it is a self-bbc'd or marked-as-read-by-server. Maybe a hidden pref like the one you suggested or a mail extension could suppress new mail notification for such messages if the user desires. I'm an IMAP mail user and that may have influenced me to suggest that mail moved between accounts should be marked as new. With IMAP, mail stays on the server and each mail account can reside on different IMAP server. In this environment, dragging a message from one mail accounts to another will literally move the message from one server to another and is a near equivalent of emailing the message to the destination account. Couple this with the fact that IMAP accounts can be simultaneously shared by several user and one persons actions can be seen by many. For instance, if a co-worker drags a message into my public IMAP account, I'd like that message marked as new. This is *not* to say that it should be marked as *unread*, only that is should be marked as new and I should receive a new mail notification. Similarly, if a third party were to drag a message into a co-worker's public account that I am sharing, I'd expect the message to be marked as new and be notified of its arrival. (Whether the messages should also be marked as unread is debatable. At the moment, I'd say "no".) I think that with an addition bug report, both your and my expectations can be accommodated.

Isn't this bug a duplicate of bug 226885? Or at least related to it?

Hi! How can you test which folders are marked as "Check this folder for new messages"? How does Mozilla record this? There is obviously no entry in the pref.js file.

for #23: right-click on folder, Properties..., checkbox for "Check this folder for new messages"

For #24: OK, that's the GUI way. I should have mentioned that I wanted to examine the user profile's files to check if a folder is marked or not. I do not want to go to a user and have him check all his folders manually if that flag is set.

Regarding what this bug has ostensibly become about, per the summary: I see "wrong" notification in two cases: 1) when a client-side filter moves a message into a checked folder. In that case, I'm notified when the message arrives, and then again when I click on the destination folder; that second notification is unnecessary. 2) when a client-side filter marks a message read and moves it into a folder. In all cases, the destination folder gets a New flag (bug 230805), and it is bolded and its unread count incremented, despite the message having been marked read. In Mozilla 1.7/1.8, this also causes a notification if the deletion model is Mark As Deleted and the destination is another folder in the IMAP account -- this is bug 257573. (There are a couple of other oddball behaviors here, e.g. bug 254589.) As for what this bug was originally about, I am not getting notifications on messages placed into the remote Sent folder, even if that folder has explicitly been configured with "check for new messages." (In reply to comment #15) > This new/non-new status should be preserved even when the message > is moved from folder to folder just as the read/unread status of > messages is preserved. "New" in Mozilla means "this message (or folder, or account) is (or contains) mail of which the user is not yet aware." Mozilla does this imperfectly, but: if you've moved a message via a UI action, you're "aware" of its existence and it should no longer be New. (If the message was moved with a filter, it remains New.) I'd say this should be true even in the case of moving between multiple IMAP accounts. The New flag is intended to be ephemeral: it should trigger notification and help you find the new mail after you've become aware of the notification. It is not intended to persist. There are cases where the action taken to "become aware" of the message is not really intuitive (esp bug 174395, which is blocked by this bug, incorrectly IMO), and there are also some bugs in the implementation, but that is the model. (In reply to comment #21) > I agree with [Collin] that the unread indicator is perfectly fine as it > stands. It [is] the green arrows and orange stars that are not behaving as > many would expect You mean, "as I would expect," of course. I presume you haven't taken a survey to justify that "many." > I believe [Collin's self-BCC scheme] is a special case that would be best > addressed in a new bug. IMHO, new mail is new mail even if it is a self-bbc'd > or marked-as-read-by-server. It may be new, but it's not worth being notified about. There are quite a few bugs about suppressing notification in cases that people don't care about: Junk (bug 189289), mail that's been filtered to the trash (bug 91498) or marked read (bug 206050), and items put into the Sent folder (the original symptom of this bug). Also bug 11040 is about putting direct control of the notification into the filter mechanism. > Couple this with the fact that IMAP > accounts can be simultaneously shared by several user and one persons actions > can be seen by many. For instance, if a co-worker drags a message into my > public IMAP account, I'd like that message marked as new... and I > should receive a new mail notification. This is a reasonable expectation. I don't know what the technical details are (specifically, I don't know exactly how or whether Mozilla's New and Unread states are mapped to IMAP's /RECENT and /SEEN); but for this to work as desired, Mozilla's New state needs to be decoupled from the server's message state. At any rate, if Mozilla/TB do not do what you expect in this case (I can't test, having only one completely private IMAP account), then you should open a new bug for this issue.

I'm seeing this issue (or a similar issue?) as well, but I can't really distinguish between items 1 and 2 in Mike's comment. Let me describe what I'm seeing: I'm using Gmail IMAP. I have a client-side filter on a mail client moving messages between folders - but not on my machine, on a different one. On the machine on which I'm seeing this issue, the folders with 'check for new messages' get emboldened when new messages arrive, but also on every subsequent check - repeatedly, regardless of whether there are new messages or not.

potential complication to doing bug 289208