Subject: Re: ipopd timeout on Solaris 2.5

From: Mark Crispin <[email-masked]>
Date: Mon, 16 Dec 1996 14:26:30 -0800

On 15 Dec 1996, Peter J Naylor wrote:
> Hi, we're running the imapd and ipopd's that came with Pine3.95 on our
> Solaris/SPARC 2.5 mail server.  Normally everything works fine, but
> occasionally with a user on a slow PPP link and a large file in their
> mailbox, they get a timeout.  Anyone else experienced this and got some
> tips?  I've checked out the latest developer's imapd package from UW, but
> the only things which might be relevant in there are in the imaprc file.
> None of the timeout parameters in there seem like they'd be a problem, as
> their default is set to infinite.  This bugs me... please help! :)
> 
> Our syslog lists a "Kiss of Death" for the pop login, if that helps...

This is a frequently asked question.

The user has some sort of "check for new mail" background task running.
This periodically opens a POP3 connection to probe the user's mailbox.

In the UNIX mbox format, only one process can have the mailbox opened in
read/write mode at a time.  In our implementation, if a new process
discovers that some other process has the mailbox read/write, it sends a
"kiss of death" to the old process requesting that it kill itself so the
new process can acquire read/write mode.

This is done because PCs, Macs, and similar toy computers tend to crash
frequently.  This leaves stuck servers at the other end.  After the user
reboots her toy computer and tries to connect again, she expects to be
able to get at her mail and not be told "you already have it open, go
away."

The POP3 protocol specification specifically forbids more than one active
POP3 session per user on a server at a time.  So the choice is either "new
kills old" or "you already have it open, go away".

So, why are your users getting a Kiss of Death?

There are a number of little background programs (TSRs and the like)
floating around which "check for new mail".  They work by periodically
connecting to the POP3 server to see what new mail exists.

Guess what happens when this background task fires off when the user has
an active POP3 session.  You got it, that POP3 session gets killed.

The immediate fix is to stop using those "check for new mail" background
tasks.  If the user really insists upon using one, get ahold of one which
does a query via IMAP4 instead of POP3.  IMAP4 has a "STATUS" command
which will return information about new mail without requiring a
read/write lock.  POP3 has no such choice. 

-- Mark --	Read http://www.imap.org for the "best kept secret in email"

DoD #0105, R90/6 pilot, FAX: (206) 685-4045  ICBM: N 47 39'35" W 122 18'39"
Science does not emerge from voting, party politics, or public debate.