SmarterMail allowing login attempts from denied countries to fake out attackers?
Problem reported by ß - 7/28/2026 at 5:57 PM
Resolved
After an update from 9652 to 9693, I'm now getting many IDS brute force login attempts from countries that are specifically denied. My login denial list is all but USA.

Support says that SmarterMail lets some attempts through to "fake out" the attackers. Is this true? If so, what percentage? How does SmarterMail decide which attempts to fake out since not all of the attempts are getting faked out? Frankly, I think its a bug, but did I miss this new "feature?"

The reason that attackers from those countries are not just blocked outright is to waste their time and not make them aware that they can't log in because they are country-blocked. If an attacker did successfully guess a user's login credentials, SmarterMail would not indicate anything different, so the attacker can simply assume that the username and password combination they tried was incorrect.
Tim Uzzanti Replied
Employee Post
I think there is some confusion.

There’s nothing random about our blocking mechanism by country. It’s implemented just before authentication, which means the IP address is connected and transferring commands until we reject it. If you’re seeing this IP in sessions lists at times, that is why. Keep in mind, some of this block is also configurable at the domain level, and another reason it needs to go through parts of the system. The other thing is, in 9693, reporting for this is much more detailed so you have more visibility.  
Tim Uzzanti
CEO
SmarterTools Inc.
ß Replied
Tim,

1) 99% of the "outside of USA" IP Addresses are getting blocked for not being on the approved country list. However, a few get through. I notice these "few" because they end up on the IDS Block List. Some have already been blocked by country on the same day.

2) This IP Address was blocked at 7:56:54 but allowed a login attempt at 19:54:56. It shows up on the IDS Block List as being from Spain.
[2026.07.29] 07:56:54.189 [185.229.xx.xx] SMTP User user@domain.com with IP 185.229.98.44 attempting login from country Spain (ES) not on the allowed country list.
[2026.07.29] 19:54:56.336 [IpBruteForceDetector] Added 185.229.xx.xx to IDS block list. Duration: xxx seconds, Description: x incorrect in xx minutes
3) The idea that you let a few through on purpose to confuse the attackers sounds untrue to me. Can you confirm or deny this?

4) These non-USA IP Addresses on the IDS Block List (based on brute force by password) did not begin showing up until I installed the 9693 update (updated from 9652).
Andrew Barker Replied
Employee Post
The behavior you are describing is expected. It's the result of two separate systems working independently, which can make the logs easy to misread. Here's a brief explanation of the two:

  • Block Authentication by Country is an authentication gate; it does not block any connections. When a login is attempted from a restricted country, SmarterMail refuses the authentication. That will end the current session, but it does not prevent the IP from reconnecting and trying again.
  • IDS Rules independently counts failed authentication attempts. When an IP crosses the threshold for an IDS rule, a block is created and future connections from that IP are prevented until the block expires.
Because Block Authentication by Country is configured at the system level, and can be further restricted at the domain level, it isn't enforced until an authentication attempt is made for an account that apparently belongs to a valid domain. Anything up to that point which causes an authentication failure will count as an IDS rule violation.

With all that in mind, an aggressive IP from a restricted country is likely to trip both systems across multiple authentication attempts. Seeing both in the logs on the same day is expected as it's the result of two different types of protection catching the same bad actor.

That is exactly what your log lines show, only about 12 hours apart:
[2026.07.29] 07:56:54.189 [185.229.98.44] SMTP User user@domain.com with IP 185.229.98.44 attempting login from country Spain (ES) not on the allowed country list.
[2026.07.29] 19:54:56.336 [IpBruteForceDetector] Added 185.229.98.44 to IDS block list. Duration: xxx seconds, Description: x incorrect in xx minutes
The first line is the country filter refusing an authentication attempt, apparently using an email that seemed to belong to a domain that exists on your server. However, Block Authentication by Country never blocks connections, which is why the IP was able to keep trying. Over the next 12 hours, that same IP continued connecting and attempting to authenticate, at least occasionally using email addresses that belong to domains your server doesn't recognize. At 19:54, the IP finally triggered an IDS rule and a block was created.

In regards to your question, "Are a few let through on purpose to confuse attackers?" — no, SmarterMail is not intentionally letting anything through. What you're seeing in the IDS Block list isn't the country filter leaking a few IPs, it's authentiation attempts failing before getting to the country check and eventually triggering the IDS system.

You may very well be seeing IPs from restricted countries popping up in your IDS block list more often after upgrading from 9652 to 9693. Build 9673 included upgrades and fixes for the IDS system, including a fix for IDS tracking in SMTP. Prior to 9673, failed SMTP authentication attempts weren't always incrementing the IDS counters, which meant that bad actors could continue trying to authenticate for longer before triggering an IDS block, if they ever happened to trigger one. After 9673, failed SMTP authentication attempts are being counted more accurately, which means this sort of attacker is more likely to trigger an IDS block.

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

Oliver Replied
What I always find amazing is how much time the guys at ST take to answer the questions here on the forum in such detail. Thank you so much!
ß Replied
Andrew,

You may very well be seeing IPs from restricted countries popping up in your IDS block list more often after upgrading from 9652 to 9693.
In my case, more often went from ZERO to 25/day.

If all authentications from non-USA are blocked, I still don't see why any non-USA IP Addresses should show up on an IDS Block List. If 1 failed authentication triggers an IDS Block, why do not ALL of the non-USA IP Addresses show up on IDS Block List? Why only a few?

I think ZERO non-USA IP Addresses should end up on the IDS Block List because non-USA IP Address authentications are blocked. If it's not zero, then it should be ALL of the attempts. No one has explained why a few get through to the IDS Block list when 1 failed attempt triggers the IDS Block List.

Your explanation does not explain why the same non-USA IP Address was blocked-by-country at 7am and not blocked-by-country at 7pm. While this scenario is very rare, I still don't see why. As I've already said....1 failed login attempt triggers the IDS Block. According to you, ALL 1200/day should be on the IDS Block list; they aren't. About 50 do not show in the logs as failed country, but ONLY as a failed login attempt, and these 50 end up on the IDS Block List from a non-USA IP Address.

Seems like the block-by-country is sometimes getting bypassed (or your list of countries is changing by the millisecond).

Thanks

Andrew Barker Replied
Employee Post
The. explanation you are looking for is in my previous post, but let me try with an example.

Say you have three domains on your server:  example-ca.com, example-us.com, and example-mx.com. At the system level, Block Authentication by Country is set to only allow authentication from Canada, United States, and Mexico. At the domain level, example-ca.com is further restricted to only permit authentication from Canada, example-us.com only allows authentication from the United States, and example-mx.com only accepts authentication from Mexico.

Now let's say that you have an attacker originating from a single IP in  Australia. Their first attempt uses the email address user@not-my-domain.com. SmarterMail's authentication logic parses the domain name out of that and tries to find the domain on the server. Since it isn't one of the three domains, the authentication attempt fails and is reported to the IDS system. Then another authentication attempt arrives from the same IP for user@example-mx.com. The authentication logic is able to find this domain, since it exists on the server, so it moves to thestep of checking against the Block Authentication by Country service. Sincedomain-mx.com only allows auth from Mexico, and the IP is from Australia, the authentication is automatically failed, but it does not get reported to IDS.
 
This is what appears to be happening on your server, but many times in a day. Block Authentication by Country isn't getting bypassed in any of the authentication attempts. Rather, some attempts simply never reach the Block Authentication by Country.

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

ß Replied
All domains match the system level block by country.
This didn't happen before the last update I applied.
Something changed on your end. I would like to know what.
ß Replied
BTW, tech support still insists that SmarterMail lets "some" non-USA IP Addresses through simply to confuse the attackers.
Shay Jacobs Replied
Employee Post
Hi SmarterMail community!

I just want to make some clarifications as the agent handling this ticket.

I never said that SmarterMail lets "some" - or any - non-USA IP addresses through. I will summarize my responses to Brian here (each point of which has been confirmed true by our developers and senior support):
  • The reason that attackers from blocked countries are not just blocked outright is to not make them aware that they can't log in because they are country-blocked.
  • If an attacker did successfully guess a user's login credentials, SmarterMail would not indicate anything different, so the attacker can simply assume that the username and password combination they tried was incorrect.
  • Brute-force attacks are constant and universal across email servers. With that in mind, Brian's logs actually show a very normal and unconcerning number of brute force attempts.
  • The reason that failed attempts from blocked countries count toward the IDS block threshold is that SmarterMail checks the blocked countries lists during authentication, since the block-by-country rules can be made more restrictive at the domain level. If an authentication attempt should be blocked based on country of origin, that counts as a failed auth, which should increment the IDS rules. 
  • The appearance of blocked country IPs in the logs/IDS blocks is not a bug nor a security concern and it actually proves that the system is working as intended. Those who may still be concerned about this can strengthen their own server security in a number of ways, including implementing a firewall that would outright block foreign IPs from reaching the website.
  • Each of these points has been confirmed by developers and senior support within this thread, the ticket, and in conversation, as well as by our CEO himself within this very thread.

I hope that clears up any confusion and concern, but please let us know if further clarification is needed!
Shay Jacobs
System/Network Administrator
SmarterTools Inc.
Tim Uzzanti Replied
Employee Post
Thanks for following up Shay!
Tim Uzzanti
CEO
SmarterTools Inc.
ß Replied
Marked As Resolution
Apparently, authentication for non-existent users does not trigger the country blocking (even with a valid domain). I was under the impression that only invalid/non-existent domains in the target user caused the country blocking to not get triggered.

In Session 1, the country blocking was triggered. In Session 2, the country blocking was not triggered, apparently because the user was non-existent, which caused the IP address to be added to the IDS Block List.

In the end, the user is not getting through because 1) user doesn't exist or 2) because country is blocked. Something did indeed change, though. I guess we will leave it to the changes in 9673 mentioned by Andrew. I don't think this was limited to SMTP as IMAP non-valid-user attempts now hit the IDS, too.

SESSION 1
[2026.07.29] 07:56:52.742 [185.229.xx.xx][66124389] Connection initiated
[2026.07.29] 07:56:53.266 [185.229.xx.xx][66124389] rsp: 220 mail.gooddomain1.com  Service ready
[2026.07.29] 07:56:53.266 [185.229.xx.xx][66124389] connected at 7/29/2026 7:56:53 AM
[2026.07.29] 07:56:53.266 [185.229.xx.xx][66124389] Country code: ES
[2026.07.29] 07:56:53.594 [185.229.xx.xx][66124389] cmd: EHLO ladious
[2026.07.29] 07:56:53.594 [185.229.xx.xx][66124389] rsp: 250-mail.gooddomain1.com Hello [185.229.xx.xx]250-SIZE 136533333250-AUTH PLAIN LOGIN CRAM-MD5250-8BITMIME250-SMTPUTF8250-DSN250 OK
[2026.07.29] 07:56:53.894 [185.229.xx.xx][66124389] cmd: AUTH CRAM-MD5
[2026.07.29] 07:56:53.894 [185.229.xx.xx][66124389] rsp: 334 PC0yNTk3ODc0NTEuNjM5MjA5MDg2MTM4OTQ2ODY1QG1haWwub2FrbGV5cHViLmNvbT4=
[2026.07.29] 07:56:54.188 [185.229.xx.xx][66124389] Authenticating as gooduser@gooddomainalias1.com
[2026.07.29] 07:56:54.189 [185.229.xx.xx][66124389] Authentication failed - blacklisted ip by country
[2026.07.29] 07:56:54.189 [185.229.xx.xx] SMTP User gooduser@gooddomainalias1.com with IP 185.229.xx.xx attempting login from country Spain (ES) not on the allowed country list.
[2026.07.29] 07:56:54.189 [185.229.xx.xx][66124389] rsp: 535 Authentication failed
[2026.07.29] 07:56:54.520 [185.229.xx.xx][66124389] cmd: *
[2026.07.29] 07:56:54.520 [185.229.xx.xx][66124389] rsp: 500 command unrecognized
[2026.07.29] 07:56:54.520 [185.229.xx.xx][66124389] disconnected at 7/29/2026 7:56:54 AM

SESSION 2
[2026.07.29] 19:54:53.140 [185.229.xx.xx][50291078] Connection initiated
[2026.07.29] 19:54:54.516 [185.229.xx.xx][50291078] rsp: 220 mail.gooddomain2.com  Service ready
[2026.07.29] 19:54:54.516 [185.229.xx.xx][50291078] connected at 7/29/2026 7:54:54 PM
[2026.07.29] 19:54:54.516 [185.229.xx.xx][50291078] Country code: ES
[2026.07.29] 19:54:54.998 [185.229.xx.xx][50291078] cmd: EHLO solocyle
[2026.07.29] 19:54:54.998 [185.229.xx.xx][50291078] rsp: 250-mail.gooddomain2.com Hello [185.229.xx.xx]250-SIZE 136533333250-AUTH PLAIN LOGIN CRAM-MD5250-8BITMIME250-SMTPUTF8250-DSN250 OK
[2026.07.29] 19:54:55.601 [185.229.xx.xx][50291078] cmd: AUTH CRAM-MD5
[2026.07.29] 19:54:55.601 [185.229.xx.xx][50291078] rsp: 334 PC00ODE2MDczNDQuNjM5MjA5NTE2OTU2MDExMzIyQG1haWwuYXJsaW5naGF1cy5jb20+
[2026.07.29] 19:54:56.334 [185.229.xx.xx][50291078] Authenticating as baduser@gooddomainalias2.com
[2026.07.29] 19:54:56.334 [185.229.xx.xx][50291078] Authentication failed - login failed domain or user not found baduser@gooddomainalias2.com
[2026.07.29] 19:54:56.336 [IpBruteForceDetector] Added 185.229.xx.xx to IDS block list. Duration: 59999.9994167 seconds, Description: 1 incorrect in xx minutes
[2026.07.29] 19:54:56.343 [185.229.xx.xx][50291078] Login failed: Domain or user not found.
[2026.07.29] 19:54:56.344 [185.229.xx.xx][50291078] Authentication failed - blacklisted ip
[2026.07.29] 19:54:56.344 [185.229.xx.xx][50291078] rsp: 421 Too many authentication failures by this IP, closing transmission channel
[2026.07.29] 19:54:56.679 [185.229.xx.xx][50291078] disconnected at 7/29/2026 7:54:56 PM

Reply to Thread

Enter the verification text