Bug 40286

Summary: Pine does not fall back to imap over SSL
Product: [Retired] Red Hat Linux Reporter: Joshua Baker-LePain <joshua.bakerlepain>
Component: pineAssignee: Mike A. Harris <mharris>
Status: CLOSED NOTABUG QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-05-17 19:56:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Edited (for privacy) ~/.pinerc none

Description Joshua Baker-LePain 2001-05-11 19:46:07 UTC
My inbox is specified in my ~/.pinerc as:

inbox-path={$IMAPS-SERVER/ssl/novalidate-cert/user=$ME}inbox

(without the variables of course).  When I open pine, it displays the
following sequence of messages:

[No credentials cache found (try running kinit) for $IMAPS-SERVER]
[Can not authenticate to IMAP server: Invalid base64 string]
[No folder opened]

The same configuration works when I compile pine myself (turning on SSL). 
Yes, I can just do that, but SSL in pine *is* an advertised feature...

Comment 1 Mike A. Harris 2001-05-12 07:46:38 UTC
I'll look into this and get back..  You're the first to report that pine/ssl
does not work.  What imap server is it connecting to, is it a Linux server
or something else, and does it support ssl, kerberos, etc?

Give me as much information about your setup as you can, both pine, and the
imap server if possible.

I'll also need your config file ~/.pinerc

Replace any private info in the file with XXXXXX or something so as not
to publicize your private data.  Attach that to the bug report using the
link below.

Comment 2 Joshua Baker-LePain 2001-05-14 11:57:00 UTC
Created attachment 18270 [details]
Edited (for privacy) ~/.pinerc

Comment 3 Joshua Baker-LePain 2001-05-14 12:09:20 UTC
The IMAP server is Solaris (possibly 2.6, but I'm not sure).  It supports
kerberos for those using the public clusters.  I am not in the kerberos domain.
It also supports IMAP over SSL, which I use with self-compiled versions of pine
(both 4.30 and 4.33).  The pine version I tried was that installed with RedHat
7.1.

From sniffing the wire while pine starts up, all packets are travelling to/from
the correct port (993) on the IMAPS server.  The 'invalid base64 string' error
is the same one I got when they switched the server to IMAPS and I didn't
have SSL compiled into pine.

Pleasel let me know if I can provide any more info.

Comment 4 chappa 2001-05-16 06:02:31 UTC
what happens if you set try-alternative-authentication-driver-first, do you
still get the same error?

Comment 5 Joshua Baker-LePain 2001-05-16 11:10:20 UTC
Yes -- I get the exact same sequence of errors.

Comment 6 chappa 2001-05-17 01:03:23 UTC
Here's another suggestion: try adding 

disable-these-authenticators=GSSAPI

to your .pinerc

Comment 7 Joshua Baker-LePain 2001-05-17 12:42:30 UTC
That got it.  So I guess it's a problem in pine "falling back" to SSL when
kerberos doesn't work?  Or is merely PEBKAC?  :)

Thanks.

Comment 8 chappa 2001-05-17 19:56:04 UTC
I'm glad that thelast suggestion solved the problem. Here's a more technical
explanation of what happened.

  Pine and the server when they start a session match a list of authenticators
that both of them know (in your case, kerberos and ssl). In your case, both the
server and Pine had been compiled with this support, the problem that you had
was that you could not obtain the Kerberos credentials from your machine.

  What the command "disable-these-aunthenticators=GSSAPI" does, is to disable
Kerberos authentication *in PINE*, as opposed to disabling this on the server,
so while the server still advertises kerberos authentication to Pine, Pine in
turn does not advertise kerberos authentication to the server, so you are left
with ssl authentication (called actually "PLAIN"), which is the authentication
that is used to login you to the server.

  I hope this helps. Have a nice day!

Comment 9 Mike A. Harris 2001-05-28 21:50:12 UTC
Closing bug - problem determined as not a bug.