My inbox is specified in my ~/.pinerc as:
(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...
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
Created attachment 18270 [details]
Edited (for privacy) ~/.pinerc
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
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.
what happens if you set try-alternative-authentication-driver-first, do you
still get the same error?
Yes -- I get the exact same sequence of errors.
Here's another suggestion: try adding
to your .pinerc
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? :)
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!
Closing bug - problem determined as not a bug.