IDLETIMER and slow/buggy networks

Recently we had some users in one office who were unable to send mail 
attachments with Thunderbird - they sent OK with SMTP, but when 
Thunderbird tried to save a copy in the user's Sent folder, the operation 
failed.

When I looked on the wire, I could see something like this:

20 IDLE
+ Waiting for DONE
DONE
20 OK IDLE completed
21 append "Sent" (\Seen) {820767+}
Message-ID: <blahblah...
.. lots of base-64 text ..
i3X00+ZAg/gDi* BYE Autologout (idle for too long)
The logfile on the server I think logs "imapd[n]: Unexpected client disconnect.."

In that office, it looks like we have a real network problem - there are 
lots of TCP retransmits on larger packets, so the transaction is running 
afoul of IDLETIMER which is hardcoded at one minute in imapd.c.
But that's making mail fail, rather than just running real slow like, for 
example, scp.

Since it seems to me that imapd is waiting for "DONE", not just network 
activity, I was wondering if it ever times out on a non-broken network - 
one that's just naturally slow, for instance.
E.g. our sendmail has a byte limit of some 60Mb (some servers have no 
limit), so I could conceviably send a 50Mb attachment from home on my 
feeble 400kbps uplink, which would take much longer than 1 minute to 
write to Sent (I've yet to actually try that).

I do see quite a few "Unexpected client disconnect" messages in syslog in 
general, but have not yet joined all the dots together - I'm not sure if 
it's a general imapd issue, or an interaction with Thunderbird.


I was wondering if my interpretation of this is correct, and whether 
increasing IDLETIMER might be a good idea.