Hello Jane! The block authentication by country essentially just stops the auth attempt if their IP address correlates to a country on your block list. It won't override the IDS system that is detecting the number of failed authentication attempts though, unfortunately. What I recommend here is first determining if it is their email address/account being blocked or the customer IP itself. You should be able to determine that by reviewing Manage>IDS Blocks while they're blocked, and from there you can put together a better set of next steps. 

If the client's account is being blocked because of those failed attempts, I recommend taking a look at your IDS block configurations (Settings>Security>IDS Rules) to make sure the Password Brute Force by Email rule is set to trigger in a higher number of attempts than the Password Brute Force by IP Address is configured to trigger on. This ensures the password guessers get dinged by an IDS block before they trigger a block on the client's email address. 

If you want some help reviewing your IDS rules and other security configurations please don't hesitate to reach out on a ticket so we can take a look. Have a good one!

What client is he using?

Microsoft has made all mail go by their servers in the US before getting to your smartermail server.

Thanks Kyle.  I did have the email at lower threshold than the IP. I have made that adjustment.

That's still not clear to me why if China and Hong Kong are on the list of IPs that are blocked, they still can make attempts.  I'm using whois to find out where the IPs are from...I'm assuming that's accurate.

Thanks,

Jane

Country Blocked for Authentication would be a hint to the bad guys to vpn in. 

Ron,

Are you accepting that risk for all of us? If you accept the risk that a hacker knows exactly how to bypass the block, why not disable the block and accept that risk? It's not that different a risk.

Maybe a good feature request would be to make all these error messages admin configurable?

Why would a hacker be less likely to see the webmail login error? Are our webmail servers not attacked like every other website? Until it's too late? Too late to try a VPN login?

Ron, I get your concern, and I'm not trying to be obtuse, but obfuscated login error messages are a very typical security method. I can't remember the last time I was told anything more specific than "domain not found" or whatever our webmail tells us, and generally it's "username or password incorrect". It's just the way things are done. Maybe let your users know you have this limitation?

I run two very small SmarterMail servers. One of my user's passwords got compromised. I only knew about this from the message I got that one user had sent too many outgoing messages in the time allowed. I was able to disable his account (on my iphone) before more than a few thousand spam emails got sent. At the time, I wasn't blocking by geo. If I had been, the hacker would likely have thought the user name / password he obtained was simply wrong, or had already been changed. If the error message had been specific, he would then have been able to use the account. (At this point in his operation, he was likely setting up the account in his spam software manually.)  Giving specific information about login errors is almost always a bad idea.

IMHO, that is.

Edit to add: This is what the SMTP log shows for a geo blocked SMTP (587, TLS) login:

[2024.05.03] 22:54:51.273 [xxx.xxx.xxx.xxx][18370050] Authentication failed - blacklisted ip by country
[2024.05.03] 22:54:51.273 [xxx.xxx.xxx.xxx][18370050] rsp: 535 Authentication failed

SmarterTools can correct me if I'm wrong, but all the client sees is the second entry, which is vague, as it should be.

(2nd edit, redacted the ip address, which was cellular.cingular.net. That's a blast from the past.)

I agree with Patrick here.

The obfuscated login error message is a good (and often used) security measure, because giving any hint to a hacker is always a bad idea.

So please keep the "Authentication failed" message as generic as possible!

Hello everyone,

I wanted to follow up on this thread regarding the block authentication by countries. It appears that this feature is counting towards the "Password Brute Force by Email" IDS rule, which should not be the case. In order to confirm this, I will conduct some testing and try to replicate the issue. If I'm successful in doing so, I will write up a bug report for us to resolve the issue.

I understand some have suggested changing the failure text but we cannot do so as it might help the attackers. However, the IDS block portion does seem like a bug to me that needs fixing.

Thank you,

Hello Everyone, 

I just wanted to follow up. I did some testing with a VPN and I was unable to trigger this IDS rule via an IP that was on the blocked countries list on the latest version. If you're having this issue please open a ticket so we can take a look. 

Thanks,