+1

A very self-serving +1 to myself as well.

Hello SmP and Gabriele. While we're awaiting feedback from other users, I wanted to offer some guidance that may help. 

With this specific scenario in mind, I'd recommend setting all of the password brute-force IDS rules to 5 password failures. Outlook and most other modern email clients will attempt authentication 3 times before giving up and prompting the user for the updated password, so this should help block spammers/hackers without affecting the users that have recently updated their passwords and forgotten to update the client. 

I hope that helps! :)

Thank you for the idea. It's not so much about blocking nefarious traffic but rather legitimate users who would then unknowingly take that bad password and try right away again using any email client. We'd much rather temporarily block all but inbound email to the account instead the entire IP.

You're very welcome, and thanks for your clarification on this. That makes sense to me! I see 3 upvotes on this now, so we'll let it run a little longer and see what kind of votes/feedback we get from the community. Have a good one!

Hello,

Idea 1: only lock email that has password fail is a very good idea, thanks for SmP.

My customer often shouting me because whole company blocked, one of them has password fail.

Idea 2: dont block if 100 password fail with the same string. Example, smarter mail receive 100 password fail "myprvpassword" from IP xxx.xxx.xxx.xxx for email admin@domain.com

This mean this is not a brutforce.

+1 here too.  I have seen this happen with 1 of our clients in particular, several times.  They change their password, forgot to update the phone that is connected to WiFi... the phone blasts away trying the old password, then the IP Address is blocked along with 35 users to access their email.

We've also run into this issue of one user taking down access for an entire location. We have the webmail brute force by IP disabled for this reason. So, I agree that it would be great if the other mail protocols had this IP/account distinction too.

In the case of the office, it would be good if the successful logins from the other accounts would disallow the IDS block for the entire IP. 

An Option like [ ] Don't block if IP with existing logged in connections or successful logins in the past 30 minutes.