287059 - mail.check_all_imap_folders_for_new is not reliable

Status: RESOLVED WORKSFORME

(SeaMonkey :: MailNews: Message Display, defect)

Description

[TT]

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
[e-mail].  I have my mail server configured so that all mail to
[e-mail] gets forwarded to [e-mail].  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 [e-mail], 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:

Comment 1

[David :Bienvenu]

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

Comment 2

[TT]

(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.

Comment 3

[Andrew Schultz]

Timur: did you get the imap protocol log?

Comment 4

[TT]

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.

Comment 5

[TT]

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.

Comment 6

[Gervase Markham [:gerv]]

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/

Comment 7

[TT]

This problem still exists on 1.7.12 on Mac OS X.

Comment 8

[David :Bienvenu]

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.

Comment 9

[TT]

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?