Control: tags + moreinfo
Hi,
upstream team answered (see
https://github.com/cyrusimap/cyrus-imapd/issues/5452#issuecomment-2908229941):
The two errors from sync_client confused me for a minute, but I think
what happens here is:
It tries to connect to the replica via imap (sync_try_imap: yes is
the default). The authentication fails with the bad protocol / cancel error.
It wants to try again via csync, but can't work out how (probably
there's no "csync" record in /etc/services), so this fails too. I think
this is a red herring and the real problem is the first attempt having
failed.
The errors on the other side show:
imap service receives a valid login using GSSAPI
something unknown goes wrong in SASL
the session is dropped
The "decoding error:" on line 2 looks like it comes from
prot_sasldecode(), which "Decode(s) data sent by a SASL security layer".
Here it is again, trimmed:
decoding error: generic failure; SASL(-1): generic failure: , closing
connection. I think this means:
generic failure is how sasl_errstring() described the issue
SASL(-1): generic failure: is how sasl_errdetail() described the issue
, closing connection is imapd describing how it's handling the
error. Looks like it was trying to parse a command from the client at
the time the error happened. That might be the failed client connection
attempt sending a Logout before closing its end.
I think something is going wrong in SASL here. I think it looks like this:
C: tries to login
S: login succeeds, sends success response
C: fails to parse the success response due to SASL failure, decides the
login failed
C: sends logout
S: fails to parse the logout due to SASL failure, drops the connection
The other log message, "which for some reason does not go to the default
log", isn't from cyrus-imapd because it's in the wrong place. I guess
it's probably from SASL, describing the problem it encountered. It's
hard to be certain since the timestamp is completely unrelated to the
other log lines, but I suppose the reporter sees a lot of this error and
just picked one as an example, rather than trying to correlate it with
the other log lines.
I don't know much about SASL nor GSSAPI, but it looks like there's been
a few changes in cyrus-sasl related to GSSAPI over the last few years.
Maybe something changed in there.
Does the problem still occur if they use something other than GSSAPI?
