Thanks for the reply.

That's roughly what I've been doing. But there's got to be an easier way. For one user who kept having this issue I just put a permanent exception in fail2ban. Also sometimes the user doesn't have all the devices available to turn off their wifi, in which case it works fine until they bring that device in the next day and the whole site gets banned again. Not fun.

There must be a better design solution to this.

PS: on at least one client (Bluemail), you can't change the password unless the server accepts it. When you change the client password, it tries to verify it against the server. When it fails, it reverts back to the old one. Arggghh.

PPS: With iOS Mail, it behaves similarly, but if you save it a second time (after it says it failed), it says "This account may not be able to send or receive properly. Are you sure you want to save?". Only then does it actually save the new password.

Well, I see your point, but it could be argued that the password isn't so much wrong as out of date; these are clients that haven't yet been told the new password.

It would be nice if the clients saw that the error was a bad password and didn't then keep retrying. But they all (Outlook 2019, iOS Mail, and Bluemail for a start) seem to just count it as a soft fail and retry a few minutes later.

However, perhaps they do behave as you suggest and fail2ban isn't being triggered by multiple retries from one client, but rather a single retry from each of the three (in the example above) local clients that haven't yet got the new password.

Yes, exactly. This is the issue.

Well, good from the point of view of attempted hacks. But not good when it's a legit user with a legit issue.

But they can't do this while their IP is blocked by fail2ban. They need to wait, or I manually have to clear the block.

--------------

Let's take a real-life example. I have three sisters who live in a large farmhouse in the mountains. They have two shared desktop computers, two laptops, three phones and four tablets. There is also a separate building with a couple of farm workers who have a total of five devices. Almost all of these have at least one client attached to our iRedMail server; some devices have multiple user accounts and thus are attached from multiple instances. Because they are all on one internet connection, they all have the same public IP. So a total of maybe twenty attached clients from this one IP.

If one sister (with a phone, tablet, laptop, and account on two desktops) changes her password on one device, she won't remember to change the password immediately on the other four (she's a farmer, not a tech). In half an hour, fail2ban will have banned the whole IP and five people are on the phone to me.

What makes it worse is that once fail2ban blocks the IP, her attempts to fix her password on the other devices all fail because the client is being ignored (yes, the client should see this issue as a timeout rather than a bad password, but it doesn't report it to her this way. Nor is she qualified to understand the difference and ramifications). Then she thinks she's been typing it in wrong and tries different combinations, and it all goes south from there.

Meanwhile, everyone at the site is locked out, and keeps getting re-locked out every time enough of her attempts fail that the IP is banned again.

PS: obviously this is an extreme case, and I have put an exception in fail2ban for their IP. But I have at least three other user sites with (simpler) variations of this problem.

I'm just wondering if anyone has a clever solution to this problem, which must happen more than just here. Maybe a temporary whitelist in fail2ban, so that one IP would be okay for 24 hours? Or something in dovecot that would still fail attempts to login with old passwords, but log them differently so that fail2ban wouldn't trigger?

Neither of this are clean solutions, but the current mess is bad enough I may have to turn off fail2ban altogether.

There's no easy or "clever" solution in your case, because this is how Fail2ban works.