Mark Constable writes:
On 26/05/14 00:00, Sam Varshavchik wrote: > Or, turn off IMAPENHANCEDIDLE, to see if that makes a difference.Ah right, I see, it's IMAP_ENHANCEDIDLE. It was 0 so I just flipped it to 1 with IMAP_USELOCKS=1 and see what happens. Then I'll set them both to 0 as
Well, turn off means 0, so keeping it at 0 would've kept things at their simplest.
I rarely if ever use shared folders... and I don't think any clients even know of the possibility of using shard folders. Just now when clicking on a Junk folder, imaplog.dat showed... [...] 11 OK FETCH completed. WRITE: * BYE Disconnected for inactivity. WRITE: * BYE Disconnected for inactivity. [... long wait ...] WRITE: * BYE Disconnected for inactivity. [... shorter wait ...] WRITE: 3 OK LOGIN Ok. [...] etc, then the folder view in TB was suddenly refreshed on a new login. So something about being "disconnected for inactivity" then taking so long for a new login. I thought if I used IDLE then my connection would persist and re-logins, or at least not so many, would be the order of the day.
Not quite. The default IMAP timeout is 30 minutes. IDLE eliminates periodic polling from the client for new mail, the server will notify the client when there's new mail. IMAP_ENHANCEDIDLE does not turn idle on, or off, it only enabled using FAM or Gamin for this, instead of the server polling internally.
You indicate that imaplog.dat did not log the receipt of DONE from the client. This points to a network connection problem.
Many cheap, consumer-grade NATing routers use very short timeouts to clear inactive NAT connections. My wireless router had a tendency to drop inactive ssh sessions after around 10 minutes, until I fiddled with ssh server's keepalive settings. With an IMAP client that uses IDLE, a persistent connection with no traffic of any kind on it, would've certainly gotten dropped. When the client, unaware that an intermediate router dropped the connection, tries to write something to it, if it's lucky it would get an an immediate connection RSET, and know that the connection is gone; but having the written data getting dropped quietly floor is certainly a plausible scenario. That's what it looks to me.
So, the likeliest scenario here is that Thunderbird issues IDLE; not a byte crosses the persistent connection, in either direction, for 15-20 minutes, an intermediate NATting router drops the connection; Thunderbird wakes up, writes "DONE"; the same router just drops this rudely on the floor, since it no longer has any record of this connection, without sending back an RSET, Thunderbird spins for a minute and times out; on the server side, after 30 minutes have elapsed, the server logs that the client got disconnected for inactivity (the server also gets no indication that the connection was broken).
Removing "IDLE" from the IMAP_CAPABILITY setting in the imapd configuration file will keep the server from advertising support for the IDLE extension altogether; that would be a rather crude way to work around this breakage.
pgp6r1MDjcq51.pgp
Description: PGP signature
------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs
_______________________________________________ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
