AUTH command behaviour when authentication process failed or aborted by user is changed

[John Fawcett]

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.