[Dovecot] Thunderbird Problem - What causes this?

[Adam McDougall]

Marc Perkel wrote:
> OK - I didn't know that I might be reporting something new. Here's 
> some more details. I leave my computer on at might (Windows XP) and 
> it's worse in the morning when I wake up. Thunderbird's checks the 
> email every 1 minute and it's set up to check several IMAP folders. 
> I'm running the latest Thunderbird release as will as the latest 
> Dovecot (not the beta versions).
>
> In the morning it is as if it can't access dovecot at all. I get an 
> hour glass as if it is waiting for something that's never going to 
> respond. But if I shut down Thunderbird and restart it then everything 
> works normal for a while.
>
A summary of below: make sure you are actually still connected to your 
original session in dovecot before you suspect it:

Try running a script to run 'netstat' frequently, say once a minute, and 
log the port numbers from the connection, example:
  TCP    reinheitsgebot:3482    mail.egr.msu.edu:993  ESTABLISHED
  TCP    reinheitsgebot:3485    mail.egr.msu.edu:993  ESTABLISHED

You probably want to do this on the server side as well as the client 
side, just to check that if a connection is dropped,
it happens on both at the same time (if not, something sounds odd!).  
I'm not sure if your problem happens if you only
have thunderbird check the inbox, but I would expect at least one 
connection (inbox) to stay connected constantly
without disruption.  If the client side port number changes (eg. 3482), 
it got disconnected for some reason.  For the
most part, Thunderbird tries to make disconnections invisible to the 
user, which is nice when it works right, but misleading
when something goes wrong, such as when thunderbird acts obstinant about 
loading messages but works when you restart.

The reason I suggest this, and even if it might be a simpler case for 
you but similar symptoms/effect, I had a load balancer
situation where connections would get dropped on the client side from a 
cause outside of the load balancer or server, and
thunderbird would not always reconnect nicely when that happened.  
Literally the fault was not in the load balancer or server,
but another server that stuck its nose in and effectively tried to steal 
the connection, making the client run into a brick wall
and disconnect.  The same happened to https connections. 

You might also try a different client such as mutt, which will make it 
painfully obvious if you get disconnected overnight,
because it won't try to reconnect.

Now on the other hand, if you can verify a single connection does stay 
open using the same source/dst port pair,
you could start zeroing in on what is actually happening inside that 
connection, if it takes tcpdump on both side
plus nonssl imap, etc.