What version of SmarterMail 17 are you running?  Also, do you have your administrative logs set to Detailed?  If so, can you provide those logs that cover the timeframe in which the accounts are being blocked?

SmarterMail Enterprise
Version: 6898 (nov 20, 2018)

This below is an example of today.

All the users of domain XXXXXX.IT where blocked and listed in WEBMAIL BLOCKS (in the log appear thet they failed the login from IP address 95.XXX.98.XXX).

They have Kerio Connect on premise in their office that download email via POP3.

After restart "SmarterMail Service" the log report succesful login for all the users from the same IP address (that is the IP address of their office).

The only operation that I made was restart SmarterMail Service.


This issue is appearing randomly on all domains in SmarterMail.

***LOG DELETED FOR PRIVACY***

Hi Gabriele,

what you posted looks like similar issue that I noticed/reported yesterday:
the 'clean time' looks incorrect/not suitable to the SmarterMail logging/server-system-date/time:
the clean time is probably/currrently UTC, but should use server time (in our case GMT+1)

example/excerpt of our SmarterMail/administrative-log:
[2018.11.26] 11:57:32.954 [89.248.162.159] POP Login failed: Too many login attempts for user office@fag-bremen.de. Brute force attempts increased to 17. User brute force attempts increased to 1. Next clean available at 26.11.2018 10:58:11
->login failed 2018/11/26 11:57 next clean 2018/11/26 10:58


looks similar to the logfile-lines you posted:
[2018.11.27] 08:22:05.230 [95.227.98.162] POP Login failed: Too many login attempts for user denisbudel@bullodesign.it. Brute force attempts increased to 1840. User brute force attempts increased to 453. Next clean available at 27/11/2018 07:22:47
->login failed 2018/11/27 08:22 and next clean 2018/11/27 07:22

Hi Thomas, thanx for the info!

Are you checking this bug?

At the moment we have to restart our SmarterMail every 3 hours to avoid problems ...

Hello Gabriele, Thomas is right that our clean time was in UTC and in our next release it was changed to server time.  Also, you could try whitelisting the different domain IPs to prevent IDS block checks against those accounts.  We have our SmarterTools office IP address whitelisted so that we don't lock out everybody in case somebody forgets their password and tries to many username/password combinations.

If you don't want to whitelist that IP then we'll have to figure out which POP account is entering incorrect username/passwords.  Also, I believe you can unblock IPs from the IDS blocks settings page instead of restarting your mailservice.

I can't unlock IP in IDS because there's NO IP listed in POP IDS, only a list of mailbox under WEBMAIL IDS.

But these mailbox result blocked also in POP3 dowload and my customers can't download their mail via POP3.

Also I must say that they are NOT using an incorrect password, because it is registered in the Outlook account and as soon as the SmarterMail service is restarted they are able to download to POP3 without having to type in any password.

Updated to the latest version today, the issue is not resolved.

I'll open up a support ticket for this issue.  I'll probably need your entire Administrative log file for review.

I've sended you the 03 dec LOG via mail

Two issues described within this thread that I want to address

First Issue

For all those posting email addresses on a public forum, you're opening yourself up a possible GDPR case - you should redact those email addresses unless your clients have agreed for you to disclose their personal information.

Second Issue :

Restarting the smartermail service should not remove an IDS block. This was identified within one of the tickets I logged with SmarterTools and was addressed within a release for v16 - Clearing the IDS block after a restart exposes the server, services and users to risk. 

Hi Jade, I know the GDPR, but I have the agreement of this particular customer to disclose this information.

Thanks

Jade - your #2 reply item states that "Restarting the smartermail service should not remove an IDS block." Here's a forum post from a few years ago where I echoed the same request - https://portal.smartertools.com/community/a2614/current-ids-block-table.aspx. If you read towards the end of the thread, a couple of SmarterMail folks indicated that the entries were going to be persisted in the database, and released in v16. I am still on v15. 

I hope you're not saying that this feature is still missing in v17!!

Just to clarify IDS blocks are persisted and have been since version 16.  What I believe is happening here is we're seeing login brute force settings being invoked, which we happened to move into the same section as IDS blocks so that system admins could have more control, like unblocking a login brute force user from the interface.

Hi Eric,

The IDS blocks being removed after a restart bug was resolved in v16 - I specifically logged a ticket relating to this and shortly after ST released an update.

Hi Gabriele

If if you do have an agreement (which would be the first I have heard of) I would not post email addresses on a public forum/

Hi Larry, thanks for Clarification 

With the latest version 6913 this issue SEEMS to be resolved.

I would like to keep an eye on the system for a few more days, then I will let you know if everything is OK

Sounds good, thanks for giving us an update.  Thanks!

Hi,

We are with version 7242 and we found a problem with IDS. We had an IP blocked, we unblock the IP but the service still blocking the IP until we restart the service.

Regards,

I confirm the same, tickets were logged but support were unable to resolve or duplicate the issue.

We now wait for BETA development to finish before getting more important issues fixed.