On 3/6/11 6:30 PM, Ed W wrote:
No, only the "OK Still here" notifications are timed like that. If you have inotify/dnotify/kqueue enabled, Dovecot sends the actual mailbox changes to clients immediately when they happen.
OK, but following that thought, it still seems possible for three connections behind a NAT to end up with one of them becoming disconnected due to a NAT timeout if the other connections aren't making changes which cause anything to trigger on the IDLE background process? (for ref, router is an Airport Extreme. Believed to have around a 30 min NAT timeout?)
Someone "doing stuff" would cause the "OK Still here" to get backed up for all clients behind the NAT. The NAT will timeout outbound connections individually, so one user keeping their outbound connection alive could cause other connections to die due to backed up "Still here" to that IP?
I guess I could try patching the hash to be less granular - would you be kind enough to remind me where in the code that hash is please?
I'm reasonably sure there is a problem here, just not debugged it enough to capture the problem... It's been a longstanding pain in the arse, just not got serious enough vs the debugging effort that I've tried to tackle it...
Note, in my case I have two machines with TB condstore disabled and they don't show problems, my machine enables condstore and I only believe the problem is on my machine. Hence I think condstore is part of the problem (but that seems consistent with the above theory). Also I only notice the problem when I have not used email for some time, but the other two folks have been... Nat?
In my case, yes, both clients (iPhone and Thunderbird) are behind NAT from the perspective of the mail server.
That said, I've been testing Timo's imap_capabilities suggestion for about the past 45mins, and it seems to solve the problem for me, at least so far.
-Dave-- Dave McGuire Port Charlotte, FL