Subject: (Linux) PINE hangs trying to open INBOX

From: James Strickland <[email-masked]>
Date: 2 Dec 1995 01:19:58 GMT

I've been running PINE on my Linux machine for a couple of months without
problems.  I'm using a PPP connection to the machine which stores my
mail.  Until yesterday, PINE would start up, say "Opening INBOX...", pause
for 5 seconds or so, then request login and password.  Everything was
hunky-dory, although I did wonder why there was the delay.

Yesterday my Internet service provider noticed weird rsh requests - apparently
PINE was attempting to start up an IMAP server on the remote host.  Security
was beefed up and now PINE will just hang when it gets to the "Opening
INBOX..." message - apparently it tries the rsh request, doesn't handle
the failure properly, and never attempts to contact the IMAP
port on the remote host.

Has anyone heard of such a problem?  Does PINE in fact attempt an rsh?
Why?  How can I comment this out of the source?  Any other pointers?
Is this something magic/wrong with the Linux port of PINE?

Help!

Thanks in advance...
(replies through email *will* work because I can just log into the mail
server)

--
James Strickland       Interested in transportation issues? Try
[email-masked]        http://www.freenet.vancouver.bc.ca/t2000bc/

---

From: [email-masked] (Barry Bouwsma)
Date: 3 Dec 1995 00:53:44 GMT

>hunky-dory, although I did wonder why there was the delay.

    Pine first makes a connection to your mailbox host, then attempts to
exec the imapd on that host with an rsh process.  If this fails, such as
if you don't have a .rhosts file to permit access from your Linux box,
Pine then reverts to the login/password authentication.
    This delay is due to the time taken for this rsh attempt at transparent
passwordless login to fail and an IMAP port 143 connection to be
established.
    To prevent Pine from trying this rsh login (whose intent is to make
the IMAP access to the mail folders transparent to the users), specify
the IMAP port number in the host specification separated from the
hostname by a colon, like...
{mailhost.your.domain:143}INBOX  [also for folder connections*]

    Your delay should be shorter.  There may still be a slight delay as
Pine establishes the port 143 connection, but Pine will then skip the
attempt at rsh.

>the failure properly, and never attempts to contact the IMAP

    What your ISP has probably done is to install the tcp_wrapper package
and configure it to refuse rsh attempts.  However, there's a problem with
the way this package closes the refused connection and what an attempt at
an rsh without .rhosts or /etc/hosts.equiv fails.  I forget the details,
maybe someone else can provide them, and possibly configuration to the
tcp_wrapper package so this is not a problem.

    In short, if you try an rsh process that fails (darn it, the security
measures I had set up seem to be no longer in effect so I can't describe
how it would look) with something other than a Login incorrect or
similar, then use the :143 to bypass this authentication.

* I believe there is some minor bug related to a hack I made to the folder
collections.  This would only affect you if you do not already have an
IMAP connection to your host, for your primary INBOX, for example.  I know
my hack to specify username in the .pinerc** wouldn't work there; I'm not
sure if the port specification is ignored as well.

** Don't ask.  My hacks were wiped out from all the accounts where I had
them saved, sorry.

-- 
 Barry Bouwsma, Mendel University Brno, Czech Republic -- I Still Have No Life
Flash!  Seeking work with computers over winter in Czech or Slovak Republic...
(or Austria, Switzerland, Germany...)    send offers to  <[email-masked]>
This sig is five lines long.  Check your newsreader configuration if you do not

---

From: James Strickland <[email-masked]>
Date: 3 Dec 1995 18:56:50 GMT

Thank you!!!!  The {mailhost.your.domain:143}INBOX fix works!

---

From: Henry Robertson <[email-masked]>
Date: Sun, 03 Dec 1995 19:11:57 -0500

UNSUBSCRIBE

---

From: Mark Crispin <[email-masked]>
Date: Sun, 3 Dec 1995 11:43:02 -0800

Pine tries the command "rsh IMAPSERVER /etc/rimapd" to see if it can get a
IMAP connection using rsh authentication.  If you do not have rsh
permission, or if /etc/rimapd does not exist, then the rsh command gets an
error and it will open a TCP connection to port 143 (the IMAP port) which
will require you to log in.  Normally, the rsh rejection happens in a few
seconds.

Your ISP made the usual knee-jerk response, which was to turn off rsh
service in a paranoid assumption that "security was being violated".  No
such thing was actually happening, and generally sites which behave this
way are clueless about real security problems which go on.

The problem with the knee-jerk response is that they usually do it wrong;
they simply remove rsh service or filter out rsh packets.  The problem is
that without an explicit refusal from an rsh server, the rsh client will
take a substantial amount of time before it times out.  Pine is sitting
there waiting for the rsh program to do something.

Pine 3.92 will impose a 10 second alarm clock around the rsh call.  The
right fix it to get your ISP to turn off rsh properly, or find another
ISP.

The workaround that you can do now is to force Pine to connect to port
143, skipping the rsh step.  You do that by appending ":143" to the
hostname in the mailbox specification.  For example, in .pinerc:
	inbox-path={imapserver.paranoid-isp.com:143}inbox

Another workaround, if you assume that you will never be able to use rsh,
would be to remove the rsh binary from your system and/or rename it so
that Pine cannot find it.

> (replies through email *will* work because I can just log into the mail

-- Mark --

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.