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 --

9 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 --

Dave Camenisch Replied

3/10/2026 at 12:46 AM

Same issue here...

J. LaDow Replied

3/10/2026 at 6:22 AM

Yeah this is still causing a problem here too.

The logic for detecting a hash and it's length needs to be re-visited because we are either having to turn off our IDS rule against brute force or constantly dig through the banned IPs list to find users who cannot connect - only to see that their accounts are having a mixed success logging in and the successful logins (from the same IP and most likely same device) are all throwing NTLM errors that are false positives. Either something is identifying a submitted hash incorrectly as NTLMv1 or the devices are magically sending NTLMv1 hashes when they've been told explicitly to use a different authentication algorithm...

MailEnable survivor / convert --

Dave Replied

3/10/2026 at 6:45 AM

It really seems to be a lot worse with last weeks build. :(

Came in yesterday morning to about 5 people blocked.

J. LaDow Replied

3/10/2026 at 8:53 AM

As an additional note:

iOS/macOS devices can be told to specifically use CRAM/MD5 (or something else) instead of NTLM but it is not guaranteed the device will adhere to it. We generate .mobileconfig profiles for iOS/macOS for auto-configure and our profiles specifically have the CRAM/MD5 as the requested protocol. When this issue comes up, we have those devices uninstall and re-download their .mobileconfig profile and that mitigates the issue "somewhat" but is not foolproof and does not seem to last.

MailEnable survivor / convert --

J. LaDow Replied

3/11/2026 at 1:06 PM

This is the excerpt from our Administrative log from today - regarding the broken implementation of NTLMv1 hash checking versus the IpBruteForceDetector and what is happening to multiple of our users.

Someone REALLY needs to re-visit this because disabling or weakening the IDS rule to get around this is unacceptable - as that just leaves everything else open to "slow-rolling credential attacks".

12:46:28.257 [CUSTOMER_IP_REDACTED] IMAP Attempting to login user: [REDACTED]
12:46:28.257 [CUSTOMER_IP_REDACTED] IMAP Login successful: With user [REDACTED]
12:46:29.753 [CUSTOMER_IP_REDACTED] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [HASH_REDACTED]
12:46:29.753 [CUSTOMER_IP_REDACTED] IMAP NtlmAuthenticate Login failed: NTLM; AuthenticateMessage; User password too long for LMv1 authentication.
	Brute force attempts increased to 1 of 5 in 4320 minutes.
	User brute force attempts increased to 10 of 20 in 360 minutes.
	Next clean available at 3/11/2026 12:47:27 PM
12:46:30.353 [CUSTOMER_IP_REDACTED] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [HASH_REDACTED]
12:46:30.353 [CUSTOMER_IP_REDACTED] IMAP NtlmAuthenticate False IDS counting for NTLM failures over IMAP at this IP is throttled.
12:47:42.546 [CUSTOMER_IP_REDACTED] User [REDACTED] calling patch message, owner: [REDACTED], count: 1, folder: Inbox
12:47:43.759 [CUSTOMER_IP_REDACTED] User [REDACTED] calling delete messages, folder: Inbox, owner: [REDACTED], all: , count: 1
12:51:59.020 [CUSTOMER_IP_REDACTED] User [REDACTED] calling patch message, owner: [REDACTED], count: 1, folder: Inbox
13:11:19.322 [CUSTOMER_IP_REDACTED] IMAP Attempting to login user: [REDACTED]
13:11:19.322 [CUSTOMER_IP_REDACTED] IMAP Login successful: With user [REDACTED]
13:16:59.917 [CUSTOMER_IP_REDACTED] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [HASH_REDACTED]
13:16:59.917 [CUSTOMER_IP_REDACTED] IMAP NtlmAuthenticate Login failed: NTLM; AuthenticateMessage; User password too long for LMv1 authentication.
Brute force attempts increased to 2 of 5 in 4320 minutes.
	User brute force attempts increased to 11 of 20 in 360 minutes.
	Next clean available at 3/11/2026 1:17:59 PM
13:17:00.221 [CUSTOMER_IP_REDACTED] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [HASH_REDACTED]
13:17:00.221 [CUSTOMER_IP_REDACTED] IMAP NtlmAuthenticate False IDS counting for NTLM failures over IMAP at this IP is throttled.
13:49:17.078 [CUSTOMER_IP_REDACTED] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [HASH_REDACTED]
13:49:17.081 [CUSTOMER_IP_REDACTED] 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 12 of 20 in 360 minutes.
	Next clean available at 3/11/2026 1:50:17 PM
13:49:18.618 [CUSTOMER_IP_REDACTED] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [HASH_REDACTED]
13:49:18.618 [CUSTOMER_IP_REDACTED] IMAP NtlmAuthenticate False IDS counting for NTLM failures over IMAP at this IP is throttled.
13:49:19.972 [CUSTOMER_IP_REDACTED] IMAP Attempting to login user: [REDACTED]
13:49:19.972 [CUSTOMER_IP_REDACTED] IMAP Login successful: With user [REDACTED]
13:49:21.404 [CUSTOMER_IP_REDACTED] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [HASH_REDACTED]
13:49:21.404 [CUSTOMER_IP_REDACTED] IMAP NtlmAuthenticate False IDS counting for NTLM failures over IMAP at this IP is throttled.
13:49:22.314 [CUSTOMER_IP_REDACTED] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [HASH_REDACTED]
13:49:22.314 [CUSTOMER_IP_REDACTED] IMAP NtlmAuthenticate False IDS counting for NTLM failures over IMAP at this IP is throttled.
13:49:23.548 [CUSTOMER_IP_REDACTED] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [HASH_REDACTED]
13:49:23.549 [CUSTOMER_IP_REDACTED] IMAP NtlmAuthenticate False IDS counting for NTLM failures over IMAP at this IP is throttled.
13:49:23.847 [CUSTOMER_IP_REDACTED] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [HASH_REDACTED]
13:49:23.847 [CUSTOMER_IP_REDACTED] IMAP NtlmAuthenticate False IDS counting for NTLM failures over IMAP at this IP is throttled.
14:21:39.523 [CUSTOMER_IP_REDACTED] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [HASH_REDACTED]
14:21:39.524 [CUSTOMER_IP_REDACTED] IMAP NtlmAuthenticate Login failed: NTLM; AuthenticateMessage; User password too long for LMv1 authentication.
14:21:39.903 [CUSTOMER_IP_REDACTED] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [HASH_REDACTED]
14:21:39.903 [CUSTOMER_IP_REDACTED] IMAP NtlmAuthenticate False IDS counting for NTLM failures over IMAP at this IP is throttled.
	Brute force attempts increased to 4 of 5 in 4320 minutes.
	User brute force attempts increased to 13 of 20 in 360 minutes.
	Next clean available at 3/11/2026 2:22:18 PM
14:21:40.395 [CUSTOMER_IP_REDACTED] IMAP Attempting to login user: [REDACTED]
14:21:40.395 [CUSTOMER_IP_REDACTED] IMAP Login successful: With user [REDACTED]
14:21:40.913 [CUSTOMER_IP_REDACTED] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [HASH_REDACTED]
14:21:40.913 [CUSTOMER_IP_REDACTED] IMAP NtlmAuthenticate False IDS counting for NTLM failures over IMAP at this IP is throttled.
14:21:41.418 [CUSTOMER_IP_REDACTED] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [HASH_REDACTED]
14:21:41.418 [CUSTOMER_IP_REDACTED] IMAP NtlmAuthenticate False IDS counting for NTLM failures over IMAP at this IP is throttled.
14:21:42.238 [CUSTOMER_IP_REDACTED] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [HASH_REDACTED]
14:21:42.238 [CUSTOMER_IP_REDACTED] IMAP NtlmAuthenticate False IDS counting for NTLM failures over IMAP at this IP is throttled.
14:21:42.563 [CUSTOMER_IP_REDACTED] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [HASH_REDACTED]
14:21:42.564 [CUSTOMER_IP_REDACTED] IMAP NtlmAuthenticate False IDS counting for NTLM failures over IMAP at this IP is throttled.
14:50:46.197 [CUSTOMER_IP_REDACTED] User [REDACTED] calling patch message, owner: [REDACTED], count: 1, folder: Inbox
14:50:50.367 [CUSTOMER_IP_REDACTED] User [REDACTED] calling patch message, owner: [REDACTED], count: 1, folder: Inbox
14:50:59.651 [CUSTOMER_IP_REDACTED] User [REDACTED] calling patch message, owner: [REDACTED], count: 1, folder: Inbox
14:51:28.456 [CUSTOMER_IP_REDACTED] User [REDACTED] calling send message, subject: [REDACTED]
14:51:36.533 [CUSTOMER_IP_REDACTED] User [REDACTED] calling patch message, owner: [REDACTED], count: 1, folder: Inbox
14:51:38.310 [CUSTOMER_IP_REDACTED] User [REDACTED] calling move messages, owner: [REDACTED], folder: Inbox, newOwner: [REDACTED], new folder: ACCOUNTING, count: 1
14:51:41.811 [CUSTOMER_IP_REDACTED] User [REDACTED] calling move messages, owner: [REDACTED], folder: Inbox, newOwner: [REDACTED], new folder: ACCOUNTING, count: 1
14:51:52.756 [CUSTOMER_IP_REDACTED] User [REDACTED] calling move messages, owner: [REDACTED], folder: Inbox, newOwner: [REDACTED], new folder: TIF, count: 1
14:53:54.302 [CUSTOMER_IP_REDACTED] IMAP Attempting to login user: [REDACTED]
14:53:54.302 [CUSTOMER_IP_REDACTED] IMAP Login successful: With user [REDACTED]
14:56:39.398 [CUSTOMER_IP_REDACTED] IMAP NTLM; AuthenticateMessage; User password too long for LMv1 authentication [HASH_REDACTED]
	Brute force attempts increased to 5 of 5 in 4320 minutes.
	User brute force attempts increased to 11 of 20 in 360 minutes.
	Next clean available at 3/11/2026 2:57:32 PM
14:56:39.399 [IpBruteForceDetector] [CUSTOMER_IP_REDACTED] Added to IDS block list for violating rule Type: Password Brute Force by IP, Description: Default Brute Force by IP rule
14:56:39.403 [IpBruteForceDetector] Added 2603:6013:f140:2:bc08:a346:4c6c:e1d1 to IDS block list. Duration: 604799.9950725 seconds, Description: Default Brute Force by IP rule
14:56:39.404 [CUSTOMER_IP_REDACTED] IMAP NtlmAuthenticate Login failed: NTLM; AuthenticateMessage; User password too long for LMv1 authentication.
14:57:04.699 [CUSTOMER_IP_REDACTED] User [REDACTED] calling send message, subject: [REDACTED]
14:57:12.789 [CUSTOMER_IP_REDACTED] User [REDACTED] calling patch message, owner: [REDACTED], count: 1, folder: Inbox
14:57:16.784 [CUSTOMER_IP_REDACTED] User [REDACTED] calling patch message, owner: [REDACTED], count: 1, folder: Inbox

Additionally, as requested in other threads, if something such as an authentication protocol can be listed as a capability of a mail server (such as "AUTH-NTLM") - then it should have the ability to be turned off.

response: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=NTLM AUTH=PLAIN SASL-IR UTF8=ACCEPT UIDPLUS QUOTA MOVE XLIST CHILDREN ENABLE CONDSTORE X-SM-TAGS

MailEnable survivor / convert --

Dave Replied

3/11/2026 at 1:32 PM

Agreed.

Have you opened a ticket about it?

I was thinking of doing it but am buried dealing with other issues at the moment.

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text