...

symptoms:

1. Coming back to the idle client, and clicking on a newly arrived message, often a long delay (seems like minutes, sometimes) will occur before the message loads from the server.
2. Sending messages, as often as not, the client will stall, sometimes indefinitely, on "copying message to sent folder".

Does this happen when using a client which is on the same LAN as the server? This kind of behavior looks like a network issue.

You called it. We access the server over the Internet. How did I forget to provide that small detail? However, that's not the slowness I speak of. Perhaps a better term is long delay, like waiting on some timeout, before message loadding (in symptom 1., above).

So are there parameters to tune, that will make dovecot behave nicer? I do not believe this to be connectivity outages between our clients and the server. For one, we never experienced these symptoms with UW-IMAP.

I just duplicated the stall on copying to Sent folder. This is probably the more prevalent, and annoying of the two problems.

facts:

• There was only one active client.
• The client was T'bird, v1.5.0.10, running on XP.
• This particular test had a 3Mb attachment.
• The mail was delivered immediately to the single, remote recipient (after a ~20 seconds of 3Mb upload).
• The "Copying to Sent Folder" dialog stayed up for (no exaggeration) 15-minutes, and then completed; the message is in the Sent folder now.

suspicion, from months of experiencing the behavior:

• Attachments are usually involved.

How does the config look? Are the mbox lock settings appropriate? I was somewhat shooting in the dark there.

* Sendmail 8.13.6/8.13.6
* $sudo sendmail -bt -d0.10 < /dev/null | grep HASFLOCK
         OS Defines: BSD4_4_SOCKADDR HASFCHOWN HASFCHMOD HASFLOCK

mbox_read_locks = flock
mbox_write_locks = flock

What else can I provide? netstats? tcpdumps? Are there logs/debugging appropriate to enable?

Thanks for any ideas, Danno