User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041217 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041217 The option mail.check_all_imap_folders_for_new, when set to true, is suppose to check all IMAP folders when Mozilla checks for new messages. This feature is unreliable for me. When I click the "Get Msgs" button, Mozilla frequently fails to notice some of my folders have new mail. The one thing that always works is if I select the folder in question. Then Mozilla checks for new mail and finds it. Manually selecting each folder to be checked is not an option. That is because I have a procmail filter running on my server that CREATES folders based on the contents of the To: line. For example, let's say my real address is email@example.com. I have my mail server configured so that all mail to firstname.lastname@example.org gets forwarded to email@example.com. Then I have a procmail filter that creates a subfolder called xxx (if it doesn't exist already), and puts the mail there. What this means is that if someone sends email to firstname.lastname@example.org, the folder yyy won't exist until I receive the email. I have dozens of email aliases like this, and they get dynamically created all the time. I also manually delete these folders when they're empty, but if I receive another email at that address, it gets created again. In other words, my list of IMAP folders changes every day, often in ways I can't predict. mail.check_all_imap_folders_for_new is VERY VERY important to me. Reproducible: Sometimes Steps to Reproduce:
Is it just the folders that don't exist when you start up that we don't check for new messages? Are you using IMAP subscription, and are you subscribed to those folders that don't exist? Or are you not using imap subscription? Are you expecting us to try to discover all new folders every time we check for new messages? We don't do that... An imap protocol log might help: http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
(In reply to comment #1) > Is it just the folders that don't exist when you start up that we don't check > for new messages? No, it's also folders that do exist that are not checked. > Are you using IMAP subscription, and are you subscribed to > those folders that don't exist? I'm not subscribed to any folders. I'm expecting mail.check_all_imap_folders_for_new to check all the folders, regardless as to whether I'm subscribed to them. > Are you > expecting us to try to discover all new folders every time we check for new > messages? We don't do that... I wish you would. After all, if a new folder is created, and it has a new message in it, then don't you think that "get messages" should find that new message, too? Right now, to discover new folders, I have to collapse and re-expand the Inbox folder. All the dynamically-created folders are subfolders to Inbox. > An imap protocol log might help: I'll try getting the log tonight.
Timur: did you get the imap protocol log?
I haven't been able to reproduce this problem in a while, so I'll just close it. It still would be nice if "Get Msgs" would check for new folders.
I was able to recreate this problem, but unfortunately, I can't get the IMAP log to work with Mac OS X. I followed the instructions at http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap, but it just doesn't seem to work. When I take the text and drag it to the Mozilla icon, it will only accept it if the file has an extension, like .txt or .log. When I do drop it, Mozilla launches and it displays the file. After checking my email, I can't find the log file anywhere.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This problem still exists on 1.7.12 on Mac OS X.
there are a lot of fixes that aren't in 1.7.12 - we can only leave this bug open if it still exists in Thunderbird 1.5beta2 or Seamonkey 1.0a nightly builds.
I haven't been able to reproduce this with recent nightlies, so for now I'll consider it fixed. What is the policy for resolving bugs that no longer happen? Is that considered FIXED or WORKSFORME?