IP Brute Force Detector "Throttled IP" issue

Problem reported by J. LaDow - 2/9/2026 at 7:55 AM

Submitted

On the current build - 9526 (observed on 9511 and 9518 as well) there seems to be a change in the IP brute force detection and throttling when it comes to NTLM hashes.

On older builds, this didn't seem to be an issue - when we saw this "throttled" notation in the logs, there weren't any "brute force entries" that went with them. Now, it seems that an "initial" brute force attempt is logged before throttling - like a step in the filters changed order.

I can probably produce logs from previous builds but here is what we're seeing now. Additionally (as has always been the case with this user) they seem to log in using the "alias domain" but the server does catch and authenticate against the main domain. I think this is irrelevant to the issue but noted regardless.

00:47:55.906 [redacted IP] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [redacted data]
00:47:55.906 [redacted IP] IMAP NtlmAuthenticate Login failed: NTLM; AuthenticateMessage; User password too long for LMv1 authentication.
	Brute force attempts increased to 3 of 5 in 4320 minutes.
	User brute force attempts increased to 2 of 20 in 240 minutes.
	Next clean available at 2/4/2026 12:48:14 AM
00:47:56.334 [redacted IP] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [redacted data]
00:47:56.334 [redacted IP] IMAP NtlmAuthenticate False IDS counting for NTLM failures over IMAP at this IP is throttled.
00:47:57.258 [redacted IP] IMAP Attempting to login user: [redacted@alias-domain-redacted] <-- ALIAS DOMAIN
00:47:57.258 [redacted IP] IMAP Login successful: With user [redacted@redacted] <-- primary domain
00:47:57.643 [redacted IP] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [redacted data]
00:47:57.644 [redacted IP] IMAP NtlmAuthenticate False IDS counting for NTLM failures over IMAP at this IP is throttled.
00:47:57.929 [redacted IP] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [redacted data]
00:47:57.929 [redacted IP] IMAP NtlmAuthenticate False IDS counting for NTLM failures over IMAP at this IP is throttled.
00:47:58.874 [redacted IP] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [redacted data]
00:47:58.874 [redacted IP] IMAP NtlmAuthenticate False IDS counting for NTLM failures over IMAP at this IP is throttled.
00:47:59.315 [redacted IP] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [redacted data]
00:47:59.315 [redacted IP] IMAP NtlmAuthenticate False IDS counting for NTLM failures over IMAP at this IP is throttled.

MailEnable survivor / convert --

3 Replies

Reply to Thread

J. LaDow Replied

2/9/2026 at 8:13 AM

Additionally, we are looking for information on disabling the NTLMv1 capabilities. They are already disabled on the server via registry and group policy, yet SM seems to still be accepting them. Please advise.

MailEnable survivor / convert --

Andrew Barker Replied

2/9/2026 at 10:28 AM

Employee Post

This throttling logic was added about a year ago when we noticed that Mac Mail was triggering IDS blocks when it tried to do NTLM authentication for POP, IMAP, and SMTP. For some reason, Mac Mail would attempt NTLM authentication multiple times in short period without indicating to the user that something was wrong or trying a different authentication method. The log snippet you provided actually shows similar behavior. The first two lines are the first attempt, which does get counted toward the IDS rules. The third and fourth lines indicate a second authentication attempt that isn't being counted due to the throttling.

As for disabling NTLM, that isn't currently possible in SmarterMail. Further, SmarterMail natively processes NTLM authentication without relying on Windows, which is why the registry and group policy settings have no impact on SmarterMail's behavior.

Andrew Barker Lead Software Developer SmarterTools Inc. www.smartertools.com

J. LaDow Replied

2/9/2026 at 11:20 AM

Given that NTLMv1 is considered insecure by standards, and Microsoft and others are pushing for it to be disabled, what is the timeline for the ability to disable the insecure protocol. This is quickly becoming an issue with regards to security audits when we cannot turn off insecure "features".

To get back to the initial issue - the problem is that the behavior has changed from where we were to now, and it is resulting in banned IPs that shouldn't be banned (and weren't previously). Does this means that there wasn't any brute force detection on the IMAP / SMTP ports until a year ago and now there is? Because we would get brute force lockouts from all protocols that were being abused - but not false positives like we are now.

In understanding how it currently works, if the first two get "counted against brute force" but the third one is successful in the same session and the client is detected as sending NTLM hashes, the brute force entry should be "rolled back" and not counted against the user (in that case). Ever since we upgraded, I have several users that have to be unblocked even though they're successfully authenticating - and the only failures are related to their NTLM attempts that they cannot control. We are working with the users currently to see if there is an alternate resolution. I had this behavior appear as well with one Outlook 2021 user as well but recreating the profile cleared the issue for them.

I'm going through the old log files to see the differences - because nothing has changed on the user end - and the only difference is our upgrade. We moved from 8657 -> 9511 -> 9518 -> 9526.

[edited for clarity]

MailEnable survivor / convert --

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text