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.
--
Andrew Daviel
TRIUMF
_______________________________________________
Imap-uw mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-uw
