Very Computer

I am running "IMAP4rev1 v11.237 server" on a Solaris 2.6 server and
accessing a mailbox using PINE. On occasion, I have been getting the
following error:

        [MAIL FOLDER "INBOX" CLOSED DUE TO ACCESS ERROR]

I have to re-open my inbox. Can anyone help me understand why this is
happening? The server uses sendmail as the MTA and procmail as the
delivery agent and  delivers mail into a local /var/mail.

Regards

--
Divya Sundaram -----------ITS Messaging Team---------CONDITUR IN PETRA
We don't need more strength, or greater opportunity. What we
need is to use what we have.                  - BASIL S. WALSH

Quote:

> I am running "IMAP4rev1 v11.237 server" on a Solaris 2.6 server and
> accessing a mailbox using PINE. On occasion, I have been getting the
> following error:

>    [MAIL FOLDER "INBOX" CLOSED DUE TO ACCESS ERROR]

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.

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?

Joachim

--

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
Pine's fault.

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?

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.

Quote:> If you use PC Pine, there is a known bug in Winsock TCP...
> There is a known bug in UNIX TCP...

Joachim

--

I have been testing this on other clients (Netscape and Z-Mail 5.0 for
Solaris 2.5+) and see the same behaviour. I.E. Z-Mail keeps losing the
IMAP connection to the server also. Netscape doesn't show any visible
signs of any problems though ... perhaps that is a matter of how it works
anyways.

Regards

--
Divya Sundaram ------ Motorola ITS Team -----CONDITUR IN PETRA
We don't need more strength, or greater opportunity. What we
need is to use what we have.                  - BASIL S. WALSH

|> >>
|> >> You apparently don't understand what the error message means.
|> >> ...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.
|> >
|> >Right, I misunderstood the cause of the error message. Nevertheless, from
|> >a user's perspective who might be relying on Pine's new mail notification,
|> >it is still annoying to find that the connection has been closed (by
|> >whoever). Almost always these are temporary failures in the sense that
|> >re-opening the closed mailbox usually works fine. So, when pine finds that
|> >the IMAP connection for the default inbox (which it normally keeps open
|> >for the duration of the session) has been closed by the other side, it
|> >would be useful if Pine made an attempt to re-open the connection.
|> >Perhaps, this could be added to the wishlist?

|> Hi all,
|>
|> I have been testing this on other clients (Netscape and Z-Mail 5.0 for
|> Solaris 2.5+) and see the same behaviour. I.E. Z-Mail keeps losing the
|> IMAP connection to the server also. Netscape doesn't show any visible
|> signs of any problems though ... perhaps that is a matter of how it works
|> anyways.

The question seems to boil down to

        "Do you want your mail reader to try and do a
        reopen without user interaction."

My guess is that Netscape does, and does so without informing the user.
Pine does not, but waits for the user to force the reopen.

Part of the problem with automatically doing the reopen is if you have
competing clients.  You go to another machine without closing your
session.  You start a new client after rebooting your mailserver or
whatever, and your existing client back on your desk is going to be
restarting things with its "view" of the mailbox.  Maybe before it does
that you've run a client directly on the postoffice so the mailbox is
different, I hope your client doesn't try to force its preconcieved notion
of what the INBOX looked like onto the new spool file.

I like pine's behavior as its very clear and understandable, even if not
ideal.  I'm never sure what Netscape is doing behind the scenes.  At best
if pine tried to do something like "automatically reopen on key press",
I'd like to see it configurable (but of course everything is configurable
in pine :-)

Murf

--
John Murphy, better known as Erin's dad  http://remarque.org/~jam/ermp/erm.html

345 Scarborough Road          millihellen: The beauty needed to launch 1 ship
Briarcliff Manor, NY 10510 ** My opinions do not reflect those of my employer **

Quote:>The question seems to boil down to

>    "Do you want your mail reader to try and do a
>    reopen without user interaction."

>My guess is that Netscape does, and does so without informing the user.
>Pine does not, but waits for the user to force the reopen.

Hi,

What I want to know (and why I initially posted to this newsgroup instead
of the pine newsgroup) is what would cause the IMAP server to disconnect
the client? There are no NFS locking issues on the server, then what is
causing the problem?

The MTA is sendmail and I use procmail to deliver the mail to the user
mailbox. I do not see why this should be occurring at all. The server
is a beta server so it only has ONE mail account on it (!) and it is an
Ultra 2 Solaris 2.6 machine with 128 MB RAM and 100 MB Network XFace.
and no other significant activity ...

I have no problems with PINE, Netscape or Z-Mail ... They all seem to
work well once the user grasps the concept of IMAP mailboxes. (This gets
to be a problem for UNIX users who also consider their UNIX machine
a "server" -- so "folders on the servers" gets confusing for them at
times).

Regards

--
Divya Sundaram ------ Motorola ITS Team -----CONDITUR IN PETRA
We don't need more strength, or greater opportunity. What we
need is to use what we have.                  - BASIL S. WALSH

Quote:> What I want to know (and why I initially posted to this newsgroup instead
> of the pine newsgroup) is what would cause the IMAP server to disconnect
> the client? There are no NFS locking issues on the server, then what is
> causing the problem?

UNIX has a "feature" in which it'll nuke a TCP session if there are too
many retransmissions.  The problem is, it calculates this wrong, and to
make things worse offers no way of turning it off.

Among other things, this breaks the very desirable TCP feature that a
session can survive a network outage.  Let's just hope that the US
military does not use UNIX, or they will be in for the surprise of their
lives.

-- 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.