Closed Bug 244386 Opened 20 years ago Closed 19 years ago

The IDLE command in IMAP: Thunderbid loses the connection

Categories

(MailNews Core :: Networking: IMAP, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED EXPIRED

People

(Reporter: temporary1, Unassigned)

Details

Attachments

(1 file)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 In the Account Settings, I've checked the "Use IDLE command if the server supports it" button and deactivated automatic checking every X minutes. When I open Thunderbird, I check for new mail once and then rely on the IDLE function to fetch new mail. It works - but only for a half hour or so - then Thunderbird seems to close the connection - and it doesn't re-establish the connection and re-issue the IDLE command, which means I have to check manually after a half hour. Reproducible: Always Steps to Reproduce: 1. Check the "Use IDLE command if the server supports it" button in the Account Settings. 2. Open Thunderbird and check for mail once. 3. Wait an hour or so. Actual Results: New mail will not arrive automatically anymore unless you manually push the "Get mail" button (and thereby re-establish the connection) Expected Results: AFAIK, when using the IDLE command, the mail client should close the connection after a half hour, then automatically re-establish the connection and re-issue the IDLE command so that the user never has to check for mail manually (or activate automatic checking every X minute) once he/she has opened the mail client.
It's the server that is closing the connection here. Can't you work around it by having Thunderbird check for new mail every 30 minutes or so?
(In reply to comment #1) > It's the server that is closing the connection here. Are you sure? I'm using UW IMAP, and by http://www.washington.edu/imap/IMAP-FAQs/index.html#7.37, it doesn't seem like the IMAP server closes the connection. I might be wrong, of course - I'm just trying to figure out what the problem is.
Yes, I think it's the server that's closing the connection. This is the relevant part of RFC 2177: The server MAY consider a client inactive if it has an IDLE command running, and if such a server has an inactivity timeout it MAY log the client off implicitly at the end of its timeout period. Because of that, clients using IDLE are advised to terminate the IDLE and re-issue it at least every 29 minutes to avoid being logged off. The UW-imap FAQ says that this "requires" clients to poll every few minutes: Unfortunately, Outlook Express overlooks the part in the IDLE specification which requires that a client terminate and restart the IDLE before the IMAP 30 minute inactivity autologout timer triggers. but it seems more like a suggestion than a requirement to me. In any case, you can work around this by setting TB to poll for new mail every 29 minutes or something like that. Or do you have a better suggestion?
> In any case, you can work around this by setting TB to poll for new mail every > 29 minutes or something like that. Or do you have a better suggestion? I have this problem too. I'm running Thunderbird 0.8 on Windows XP Home SP1. I have "Check for new messages" ticked with interval of 10 minutes. But this setting does not have any effect - the IDLE connection can disconnect and remain disconnected for several hours. Sometimes I can go a whole evening with IDLE remaining connected and working fine, then another evening it may disconnect a couple of times and never reestablish the connection until I hit the Get Mail button. I have a friend that has the same setup and the same problem - Windows XP, Thunderbird 0.8, Mailsnare Email provider, IMAP with SSL turned on.
i'm not having this issue have been running with IDLE-only, since it was introduced in TB.6 running Courier-IMAP 1.7.2 and TB.6, .7, .8, .9
(In reply to comment #4) > I have this problem too. I'm running Thunderbird 0.8 on Windows XP Home SP1. Quick follow up to my own post here. I mentioned several months ago that I have this IDLE issue. The issue has remained with Thunderbird 0.9 and now 1.0. I really do hope this is resolved in Thunderbird 1.1 because this is completely spoiling any benefits that IMAP/IDLE support promised in Thunderbird for me. This is not a quirk with my setup because a friend has exactly the same issue with Thunderbird. We both use WinXP, Thunderbird, Mailsnare mail provider and both use a WiFi Netgear router. Both from UK but I'm on cable while friend uses ADSL. The main commonalities here looks like the Mailsnare mail provider and the Netgear router (different models - mine is used with cable modem and so doesnt have builtin ADSL modem). It looks like some mail providers close the IDLE connection, which is fine, but Thunderbird doesnt seem to reestablished the connection, even though I have the "Check for new messages every [3] minutes" option enabled. I promose a bug fix where this option still takes effect even when IMAP/IDLE option is enabled, and can be as simple as equivalent to a user clicking the "Get Mail" button, which reestablishes the IDLE connection if it was previously lost. Even better would be for Thunderbird to check if the IDLE connection is still active on a regular basis (independant of above setting) and reconnect when needed - perhaps some IMAP servers fail to let the client know when they're being disconnected? Could this be the cause of this bug? Perhaps Thunderbird does reconnect but only if it receives a "disconnected" message from the server. Just speculating. But let's assume this is a provider/hardware issue - it would still desirable for Thunderbird to be robust enough to cope. It seems to me that the reason some people experience this issue while others dont is down to whether their mail provider ever drops the IDLE connection. But a server is "allowed" to drop the connection when it wants, and so the blame may still be with Thunderbird because it doesnt reconnect. i.e. just because a subset of people experience this issue doesnt mean that Thunderbird is free of blame. I'm happy to investigate further if anyone has any ideas. PS someone set the OS to "Linux" for this bug. I'm using Windows XP so I propose this is changed to "All" (I'm unable to change this myself).
Anthony, are you talking about the IDLE connection to the INBOX? If so, the automatic check for new mail should re-establish the connection to the inbox, check for new mail, and then go back into IDLE. If you could generate a protocol log and attach it to the bug or e-mail it to me, that would be helpful: http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
Attached file IMAP logfile
I see exactly the same issue. I use only IDLE checking and have "automatic check every x minutes" disabled. IDLE stops retrieving messages if I leave it running for ~1 hour. IMAP server: Microsoft Exchange IMAP4rev1 server version 5.5.2657.85 I'm attaching my IMAP logfile.
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 bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
Thunderbird 3.0b2 still does not re-issue the idle command after 29 minutes. The option "Check for new messages every [29] minutes" is not the rfc-correct behavior for this.
Flags: wanted-thunderbird3?
(In reply to comment #11) > Thunderbird 3.0b2 still does not re-issue the idle command after 29 minutes. > > The option "Check for new messages every [29] minutes" is not the rfc-correct > behavior for this. please do your request on one of the open bugs we have concerning imap and IDLE : https://bugzilla.mozilla.org/buglist.cgi?quicksearch=Imap+idle
Flags: wanted-thunderbird3?
(In reply to comment #12) > please do your request on one of the open bugs we have concerning imap and IDLE: It's similar to Bug 468490. It's not the same problem, but the solution coule be the same.
Sven, do you still see a problem if using version 3? And if there is no bug covering the issue we could reopen this.
Assignee: mscott → nobody
Component: General → Networking: IMAP
Product: Thunderbird → MailNews Core
QA Contact: networking.imap
This problem still exists in TB 45. A working IDLE implementation requires the client to periodically notify the server of its existence. It seems Thunderbird does not do that. As a result, unless TB is set to check for new messages at some interval, IDLE only works for 29 minutes (at most) after the last interaction with the server has concluded. Bug 468490 is very much related: since TB never spontaneously re-issues the IDLE command, it never realizes a dropped connection is dead. Implementing the missing keepalive would likely automatically resolve 468490. Importantly, making the keepalive period configurable would prevent dropped connection issues from arising in the first place, as users could set the timeout to a small enough value to satisfy their network equipment / server config. There is a pref called "mail.server.server#.timeout", but in my testing it does nothing useful. Interestingly, bug 468490, comment 32 claims that the pref governs the very functionality that is being requested in this bug. So, either that statement is incorrect or the keepalive logic actually exists and is simply broken for some users. It would be lovely to know which one it is.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: