dovecot - Aug 2009 - Very long establishment time for secondary connections

Hello,

I'm currently on Dovecot 1.1.17 and I have a user that runs into a
problem quite a lot. She's using Thunderbird on a Mac.

When she sends mail, Thunderbird is set up to save sent mail to her
Sent folder. Often (usually when she has not sent another mail for a
long while) when she sends mail, Thunderbird sits there saying
"Copying message to Sent folder" for about thirty seconds.

My best guess, after looking at dovecot messages in syslog related to
her login, is that Thunderbird is using a secondary imap process to do
this copying and this connection times out due to inactivity, so that
when she sends mail it has to reestablish itself. For some reason this
reestablishment seems to take a very long time, even though her
initial login/connection when she opens Thunderbird is very fast.

I looked for a way to increase the inactivity time in dovecot.conf but
didn't see one.

I don't know of any other user that has this problem, which makes me
suspicious of her client rather than Dovecot. Pretty much everyone is
using Thunderbird, although she's the only one using it on a Mac. Is
it possible/likely that it takes so long because for some reason
Thunderbird on a Mac doesn't notice that the second connection has
died and is taking a long time trying to use the first invalid
connection before reestablishment? Or is it likely that this is a
Dovecot problem and I simply haven't figured out what's going on, yet?

All help very much appreciated.

Thanks,
Jeff

On Aug 14, 2009, at 8:53 AM, Jeff Mitchell wrote:
> My best guess, after looking at dovecot messages in syslog related to
> her login, is that Thunderbird is using a secondary imap process to do
> this copying and this connection times out due to inactivity, so that
> when she sends mail it has to reestablish itself. For some reason this
> reestablishment seems to take a very long time, even though her
> initial login/connection when she opens Thunderbird is very fast.
My guess: Some router/NAT in the middle drops this connection and then  
when TB tries to send the message the packets get just dropped,  
instead of being rejected.