> > [MAIL FOLDER "INBOX" CLOSED DUE TO ACCESS ERROR]
> This is more likely a Pine issue and should perhaps be posted in
> comp.mail.pine, but since this imap server was written by the same
> people as Pine perhaps its ok to discuss it here?
> I would like to add a few details: This error has been bugging me too
> and I would be interested in seeing this improved.
> First observation: I understand that reporting this error and giving
> up is appropriate when the IMAP access is in response to an explicit
> user action, e.g. opening a mailbox. But Pine also seems to
> occasionally report this error (and then close the mailbox) when it is
> performing its periodic background check for new mail. IMHO, this is
> less than ideal. Better would be to simply keep trying. Perhaps
> reporting the error is ok, but closing the mailbox is undesirable in
> this case.
You apparently don't understand what the error message means.
Pine does NOT "occasionally report this error and then close the mailbox."
Rather, the mailbox stream was closed (note the passive voice) by some
external agent. Pine, finding the stream closed, reports this as "CLOSED
DUE TO ACCESS ERROR" and closes its end of the stream. It would serve no
use for Pine to keep its end open.
The issue, therefore, is to find out what killed the stream. It's not
Quote:> Second observation: I have mailboxes on two networks and the
> connectivity between the two networks is often poor at certain hours
> of the day. It often happens that Pine cannot connect to the remote
> network. This, of course, is not Pine's fault. But what I find
> annoying is that subsequent to an access error with the remote network
> Pine often immediately reports that there was an access error with the
> local network and closes my local inbox too. I suspect that this is
> caused by a timeout while waiting for the remote network and not due
> to a genuine problem with the local net?
There are a number of possibilities.
If you use PC Pine, there is a known bug in Winsock TCP where it stops
acknowledging data until subsequent data is sent. Something has to put
Winsock into this state; it's possible that it's memory corruption since
it only happens to some machines and the problem goes away for a while
after a PC reboot.
There is a known bug in UNIX TCP where it incorrectly decides that it has
retransmitted too much and it nukes the server end session. The problem
is twofold. First, UNIX TCP doesn't decide "excessive retransmission"
correctly; second, it doesn't provide a way to turn off this feature. Both
are violations of the TCP specification. Apparently, someone at Berkeley
got upset at "hung" TCP connections staying around for a long time and
implemented this bug.
We're still investigating these problems, and trying to determine some
form of workaround.
There is another known bug in some versions of UNIX where a "Destination
Unreachable" ICMP datagram will cause all TCP connections to that
destination to get nukes. This bug was supposedly fixed 10 years ago, but
there are still systems that have it.
-- Mark --
* RCW 19.149 notice: This email address is located in Washington State. *
* Unsolicited commercial email may be billed $500 per message. *
Science does not emerge from voting, party politics, or public debate.