Hi All,
Looking for some advise.
We ran into a situation yesterday where our SQL cluster (mariadb-galera) stopped serving requests due to some DDL queries locking the wsrep provider. We're addressing this separately, so just background as to the cause of the problem.
As far as I know both POP3 and IMAP protocols only have two possible responses when a user tries to authenticate, either ACK (yes, you're fine let's proceed) and NACK (no, something with authentication failed, and either you've got credential issues, or something is wrong with the backend).
An ACK results in granting the user access.
A NACK results in the user having to retry.
This is all good and well, but the *typical* response by a MUA is to re-prompt the user for credentials, to which the response is usually to retry random passwords until it works again (confirmed with Outlook and Thunderbird).
What I'm hoping is that dovecot has some way to in case of such "authentication backend" problem scenarios to ignore protocol and politeness and simply disconnect the client, ie, just shut the connection without saying anything, this could even be with a small delay (I'd say 1 second or so, just to avoid tight auth retry loops, up to 4 or 5 seconds IMHO would be fine).
The hope is that this will result in the mail client treating this like a connection error rather than an authentication error, and hopefully not prompt for new credentials, but simply an alert of the "there has been a problem communicating with your mail server please retry or contact your service provider" kind of error messages.
For reference, the errors in dovecot logs looks like:
May 1 04:42:25 uriel dovecot[352]: auth-worker(11615): Warning: sqlpool(mysql): Query failed, retrying: WSREP has not yet prepared node for application use May 1 04:42:25 uriel dovecot[352]: auth-worker(11615): Error: conn unix:auth-worker (pid=11453,uid=76): auth-worker<68>: sql(user@domain,a.b.c.d,<XXXX>): Password query failed: WSREP has not yet prepared node for application use May 1 04:42:27 uriel dovecot[352]: pop3-login: Disconnected: Aborted login by logging out (auth service reported temporary failure): user=user@domain, method=PLAIN, rip=a.b.c.d, lip=e.f.g.h, TLS, session=<XXXX>
Kind regards, Jaco
Looking for some advise.
Hmmm, I am glad I took the time to arrange a proper ldap infrastructure. What ever gets hammered stays local
What I'm hoping is that dovecot has some way to in case of such "authentication backend" problem scenarios to ignore protocol and politeness and simply disconnect the client, ie, just shut the connection without saying anything, this could even be with a small delay (I'd say 1 second or so, just to avoid tight auth retry loops, up to 4 or 5 seconds IMHO would be fine).
auth_failure_delay = 2 secs ?
Hi Marc,
On 2024/05/02 15:31, Marc wrote:
Looking for some advise. Hmmm, I am glad I took the time to arrange a proper ldap infrastructure. What ever gets hammered stays local
Hahaha, yea well, galera served us well until now, and assuming no DDL changes on large tables we believe it will continue to do so. That aside, I do like ldap indeed, but unfortunately that's not a feasible option at this stage.
What I'm hoping is that dovecot has some way to in case of such "authentication backend" problem scenarios to ignore protocol and politeness and simply disconnect the client, ie, just shut the connection without saying anything, this could even be with a small delay (I'd say 1 second or so, just to avoid tight auth retry loops, up to 4 or 5 seconds IMHO would be fine). auth_failure_delay = 2 secs ?
That will still simply wait before *rejecting* the login, compared to *dropping the connection*.
We are thus looking for three different behaviours:
1. If backend confrims auth, ACK auth + proceed (grant access) to email.
2. If backend confirm "no such user" or "invalid creds", wait for auth_failure_delay and then *reject* the login.
3. If the backend fails (ie, can neither confirm nor deny), simply drop the connection.
I hope this is more clear.
Kind regards, Jaco
auth_failure_delay = 2 secs ?
That will still simply wait before *rejecting* the login, compared to *dropping the connection*.
We are thus looking for three different behaviours:
If backend confrims auth, ACK auth + proceed (grant access) to email.
If backend confirm "no such user" or "invalid creds", wait for auth_failure_delay and then *reject* the login.
If the backend fails (ie, can neither confirm nor deny), simply drop the connection.
I hope this is more clear.
Yes that is more clear, but no idea (seems a little out of scope to support by design)
participants (2)
-
Jaco Kroon
-
Marc