<div dir="ltr"><div>Hi all,</div><br>I have tried to update from 2.3.10.1 to 2.3.11.3 and found some strange change of dovecot behaviour at pop3 authentication.<br>Firstly this changes have been found by my tests with curl. But this can be simply reproduced with telnet too.<br><br>On version 2.3.10.1 when authentication is failed or aborted by client, client can send "AUTH [auth method]" to retry authentication with the same or another authentication method. Example of client <-> server conversation:<br>server <<< +OK Dovecot ready.<br>client >>> AUTH DIGEST-MD5<br>server <<< [some_auth_data]<br>client >>> *<br>server <<< -ERR Authentication aborted by client.<br>client >>> AUTH CRAM-MD5<br>server <<< [another_auth_data]<br><br>But on version 2.3.11.3 in the same cases client must send only "auth method" without "AUTH". Example of successful conversation on this version:<br>server <<< OK Dovecot ready.<br>client >>> AUTH DIGEST-MD5<br>server <<< [some_auth_data]<br>client >>> *<br>server <<< -ERR Authentication aborted by client.<br>client >>> CRAM-MD5<br>server <<< [another_auth_data]<br><br>And example of what happens if a client will try to do that in an old way on version <a href="http://2.3.11.3">2.3.11.3</a>:<br>server <<< OK Dovecot ready.<br>client >>> AUTH DIGEST-MD5<br>server <<< [some_auth_data]<br>client >>> *<br>server <<< -ERR Authentication aborted by client.<br>client >>> AUTH CRAM-MD5<br>server <<< ERR [AUTH] Unsupported authentication mechanism.<br><br>As you can see dovecot tries to find an authentication method by string "AUTH" not by "CRAM-MD5".<br><br>This change looks strange to me. And changes break curl, because it uses an old way to make authentication. To reproduce it with curl you can just do something like:<br>[<a href="mailto:user@10.52.48.220">user@10.52.48.220</a>]# curl -u [user]:[password] --verbose pop3://[dovecot-host]<br><br>Also seems like new behaviour is not fully accorded to rfc1734 (<a href="https://tools.ietf.org/html/rfc1734">https://tools.ietf.org/html/rfc1734</a>). Based on this part of rfc:<br>"If an AUTH<br> command fails with a negative response, the session remains<br> in the AUTHORIZATION state and client may try another<br> authentication mechanism by issuing another AUTH command,<br> or may attempt to authenticate by using the USER/PASS or<br> APOP commands."<br>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.<br><br>I suppose this changes was made in commit <a href="https://github.com/dovecot/core/commit/2c42881c056e5ab2e2e14b2f800d6dc72026399b">https://github.com/dovecot/core/commit/2c42881c056e5ab2e2e14b2f800d6dc72026399b</a>, but not sure about this. Seems like if authentication is aborted or failed client->current_cmd is not going to be cleaned.<br><br>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.</div>