I found that the problem was already fixed in https://github.com/dovecot/core/commit/d0ea7f9f4530878a40ae0275cf0c36d3ff911.... So, I'm going to wait until the new dovecot release. Thank you for your help!
сб, 26 дек. 2020 г. в 19:59, John Fawcett john@voipsupport.it:
On 24/12/2020 08:42, Михаил Сандаков wrote:
Hi all,
.....
Also seems like new behaviour is not fully accorded to rfc1734 (https://tools.ietf.org/html/rfc1734 https://tools.ietf.org/html/rfc1734). Based on this part of rfc: "If an AUTH command fails with a negative response, the session remains in the AUTHORIZATION state and client may try another authentication mechanism by issuing another AUTH command, or may attempt to authenticate by using the USER/PASS or APOP commands." I think "AUTH command" means full auth command started with "AUTH", not only authentication method. But I may be wrong in the interpretation of this part.
Your reading of the RFC looks correct. AUTH commands start with the string "AUTH". This is no different after a negative response.
John
I suppose this changes was made in commit
https://github.com/dovecot/core/commit/2c42881c056e5ab2e2e14b2f800d6dc720263...
< https://github.com/dovecot/core/commit/2c42881c056e5ab2e2e14b2f800d6dc720263... , but not sure about this. Seems like if authentication is aborted or failed client->current_cmd is not going to be cleaned.
So I suggest to revert old behaviour in this cases. If I am right with commit, it seems like we just need to add clearing client->current_cmd if the authentication process has failed somehow.