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
