I found that the problem was already fixed in https://github.com/dovecot/core/commit/d0ea7f9f4530878a40ae0275cf0c36d3ff9111fc. So, I'm going to wait until the new dovecot release. Thank you for your help!
сб, 26 дек. 2020 г. в 19:59, John Fawcett <j...@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/2c42881c056e5ab2e2e14b2f800d6dc72026399b > > < > https://github.com/dovecot/core/commit/2c42881c056e5ab2e2e14b2f800d6dc72026399b > >, > > 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. > > >
