to your account
< * OK IMAP4rev1 proxy server ready
> A001 CAPABILITY
< * CAPABILITY ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE ESEARCH ID IDLE IMAP4rev1 LIST-EXTENDED LITERAL+ MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR SEARCHRES UIDPLUS UNSELECT WITHIN ESORT I18NLEVEL=1 SORT THREAD=ORDEREDSUBJECT LIST-STATUS XLIST AUTH=PLAIN AUTH=GSSAPI
< A001 OK completed
* gss_init_sec_context() failed: No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000).
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):
curl: (56) Failure when receiving data from the peer
curl 7.58.0 (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Release-Date: 2018-01-24
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
operating system
Linux
Might this be happening when kinit is not run and therefore there is no ticket in the cache?
I think the problem is, the code block below is returning TRUE purely because of the existance of GSSAPI capability without checking any user or domain data is actually retrieved from the cache. As a result, it proceeds with the GSSAPI mechanism and when Curl_auth_create_gssapi_user_message is run, Curl_gss_init_sec_context simply fails.
https://github.com/curl/curl/blob/master/lib/vauth/vauth.c#L139-L144
I have more info to share:
Using CURLOPT_LOGIN_OPTIONS="AUTH=PLAIN" will force another auth method and succeed.
We have a few IMAP connections that were failing with error "Access denied", upong checking verbose, it was trying NTML and not working, but switching to auth=plain solved the issue too.
