On Thu, 22 Dec 2005, Terry Figel wrote:
I've witnessed the following from various clients:
The client has imap set to check their email every 15 minutes (or whatever),
the server has recieved new mail, but the client does not get any
notification of this
Sometimes restarting the client fixes it.
othertimes you need to kill the imapd process on the server.
I suspect that this is a client issue, not a server issue.
There is no such thing as "setting IMAP to check every 15 minutes".
Presumably, what is happening is that the client is set to issue an IMAP
command, even if it's just a no-op, at least every 15 minutes in order to
cycle the protocol and cause new mail notification.
If the client uses the IDLE extension (e.g., Outlook and Outlook Express),
make sure that you have the most recent release of UW imapd (imap-2004g),
due to the following issues:
There is an issue caused by client use of NAT which will cause the NAT
mapping to expire if the session is idle for more than a couple of
minutes.
To avoid this, recent versions of UW imapd send an announcement while in
IDLE mode, even if there is no new mail to announce.
There is another issue related to IDLE; Outlook Express does not terminate
IDLE mode at 29 minutes, even though the specification (which Microsoft
helped write!) requires that it do so. The result is that the server
autologouts at 30 minutes. The client sees this, but doesn't make that
fact clear to the user (it's a tiny little icon), and then the user
complains that they aren't getting told about new mail any more.
This issue is also resolved by recent versions of UW imapd, which fake a
"new" message near the end of the permitted IDLE period. Outlook Express
wakes up to get the new message, UW imapd immediately says that the
fake "new message" was "expunged", so OE puts the session back in IDLE
mode with a fresh 30 minute autologout timeout.
In the current solaris 9 environment, the mail spool and home directories
are local.
I've seen 100's of these stale processes, typically to home DSL or cable
boxes.
Is there a reason imapd does not die, on a non-graceful disconnect?
I can't tell you much about how Solaris behaves. imapd certainly tries to
commit suicide after 30 minutes of inactivity. I suspect that those stale
processes are in the process of committing suicide, but the announcement
of that fact is blocked in TCP output wait. The question is why TCP never
times out that output.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
