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)
Tracking
(Not tracked)
RESOLVED
EXPIRED
People
(Reporter: temporary1, Unassigned)
Details
Attachments
(1 file)
75.53 KB,
application/zip
|
Details |
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.
Comment 1•20 years ago
|
||
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?
Reporter | ||
Comment 2•20 years ago
|
||
(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.
Comment 3•20 years ago
|
||
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?
Comment 4•20 years ago
|
||
> 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
Comment 6•20 years ago
|
||
(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).
Comment 7•20 years ago
|
||
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
Comment 8•20 years ago
|
||
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.
Comment 9•19 years ago
|
||
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 10•19 years ago
|
||
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
Comment 11•16 years ago
|
||
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?
Comment 12•16 years ago
|
||
(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?
Comment 13•16 years ago
|
||
(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.
Comment 14•15 years ago
|
||
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
Comment 15•8 years ago
|
||
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.
Description
•