Hi, Sorry for the delay in replying. Been having a few mail problems ironically! Gmail smtp server stopped working!
On 23/09/2019 4:13 PM, Bernd Petrovitsch via dovecot wrote: > It's not directly a solution within dovecot but "fail2ban" exists. Yes, I have fail2ban, but that bans based on IP address. And most mail password attacks these days are distributed, and although fail2ban will try to spot them it doesn't do a very good job. I thought denying any logins without the @domain.com part would be an additional layer. I understand that there's no way these attempts could log in, its just that there are so many attempts logged, that it fills up 90% of my logs with noise, and prevents me from seeing the other important events. > Are users able to login without the @domain part? No. All valid mail accounts are in the form u...@domain.com > There is also sshguard that will do the same thing. > One of these should probably be running anyway as they help mitigate issues > where someone keep hammering on your system, however in the days of DDOS, > they are less helpful than they used to be. I'll take a look at sshguard, although it looks like its retroactive too: it waits for the events to be logged and then bans based on what it finds in the logs. I was intending to do something more proactive, at the dovecot layer, and ideally just silently drop them. Or throw the attempts into a different log perhaps. Just thinking out loud at this point. For the sake of completeness, there's also my personal favourite, CSF, which in my opinion does a better job than fail2ban, but still not exactly what I envisaged. > you can add username_filter = *@domain.com > or deny-passdb before actual passdb with username_filter = !*@domain.com > https://doc.dovecot.org/configuration_manual/authentication/password_databases_passdb/ This is more like what I had in mind. Let me try this out and I'll report back. P.
