Hello List(s), ...
saslauthd on the other hand could read the CAPABILITY tag, skip it, and process the next tag to read an OK, and then close the connection, with the Unexpected response error eventually.
--
When using saslauthd for authentication with a remote imap server, in this case perdition IMAP4, there seems to be a compatibility issue.
After LOGIN, perdition is sending the CAPABILITY tag before the OK.
saslauthd expects an OK, but receives the CAPABILITY first and then closes the connection.
saslauthd[8454] :do_auth : auth failure: [user=x@xxxxxxxxxxxx] [service=imap] [realm=]
[mech=rimap] [reason=[ALERT] Unexpected response from remote authentication server]
I was able to alter the last lines of auth_rimap.c, and hack this out, but this should be implemented properly.
I assume, perdition behaves standard compliant within the IMAP4 protocol, however it could send the combined "a OK [CAPABILITY ... ]" as dovecot does. Is there a technical reason for the two separate messages? I was not able to manipulate this behavior with configuration arguments.
saslauthd on the other hand could read the CAPABILITY tag, skip it, and process the next tag to read an OK, and then close the connection, with the Unexpected response error eventually.
I'm not sure which is the more standard compliant approach, but if my assumption is correct, auth_rimap.c should be modified for increased compatibility.
I already wrote to the perdition mailing list and to the cyrus-devel mailing list, but no one responded so far. It would be important for me to get this issue fixed, as my system requires this setup. I can workaround with compiling the modified saslauthd, but it would be much better to have it built-in.
Could anyone assist me with this?
Thank you, ...
Greetings,
