Hi Sergei,
Not quite. max_user_connections limit is enforced after successful authentication - that's when the server knows the user name.
max_connections is enforced as soon as the client connects.
So yes, even when usera has reached max_user_connections limit, it can keep trying to connect and exhaust max_connections too, especially if it'll delay sending authentication packets.
So what about waiting a bit with dropping the connection of max_connections, so you can do - get the send user name - check if the username is in max_user_connections limit - if it is limited drop the connection, but don't add it to the max_connections counter. - if it is not limited add the connection, and add it to max_connections counter. disadvantage - is when you drop the connection for max_connections. You have to maybe postpone this a bit. - could this postponing be abused in a dos attack? advantage - is you allow other not blocked users from the same ip. - admins don't need to set max_connections high to prevent it from blocking other valid users - keep this max_connections functionality as it is meant for. I think this is a good enhancement. Depending on postponing this dropping. In sendmail you have a delayed_checks option. You could also add this to the configuration activating this behaviour. So people can choose to have this functionality or not. It all depends on the influence of postponing dropping a connection until you know what the user name is. Afaik is the current combination of max_user_connections and max_connections useles when on the same ip.