I might be wrong but I do understand that only authentication its being blocked by that feature. That means nobody can login to their email account from outside united states but for smtp traffic it has no effect (and you probably don’t want that).

I actually DO want that. lol. There are no customers that have that. In fact, that would be a GREAT feature request if that is the case and controllable at the server level and the domain level. 

Then comes another question. If I click on the list and click BLACKLIST why doesn't it get added to the blacklist. I just checked that. I did a copy, marked as black list. Went into the list, and that ip was not in the black list. I had to add it manually. Have all the ones I've been black listing and dropping not been added????

I have to agree with "XT":   Just because your clients are regional, it does not mean that their communication patterns are exclusively regional.   Additionally, a lot of mail comes from server farms that are replicated around the world for redundancy, and we simply cannot predict which country will originate a particular message.   You should block China if at all possible, but it gets more complicated after that.   

Spam filtering is a subtle business.   If you use a broad-brush approach like non-US blocking, you will need to commit the labor effort to monitor that rule for mistakes, and you will need a flexible exception mechanism to configure the exceptions when they are detected.   Once you have those tools in place, you can tighten down or loosen up as your actual message flows show you what is needed.

It's gonna be a tough conversation with a user who reports they didn't get their email confirmation from a German, British, Italian, French, Swiss online company.

We have USA fire department customers using SmarterMail to spec and purchase Fire Trucks from France.

Yet, we can probably block Nigeria and nobody would ever know. Country SMTP blocking is too intricate. 

We employ a third party solution that watches our logs.

Blocking country authentication does not block incoming SMTP messages. Country blocks in SM will not mess up your incoming mail. It only blocks "authentication" into an account to send via SMTP or read via the other protocols. In SM's case - a block still allows communication - which consumes resources and bandwidth.  By allowing continued attacks "even if they can't get in" they're still consuming resources and bandwidth that I pay for.

The solution we use watches for blocked country logins, bad EHLO strings, and multiple other strings we scan for in the authentication logs and flat out blocks the IP at the firewall when an offender is logged. We've seen our logfiles for SMTP drop by over 30% since we went back to this solution from our MailEnable days.

Our customers still get their incoming mail unless the same IP address is hosting a malicious user or server that is attacking us. We are not a huge provider - but we have a decently active mail server - just under 100 domains and 400 active users - and it works well for us.

John,

If you take a look on the list, the connection from Brasil is on port 25 witch is unauthenticated, because received messages on port 25 are unauthenticated, they came from other server delivering email and not from users sending authenticated email.

Regards,

SR

If you have an incoming gateway (which never expects authenticated SMTP), you can use it as a honeypot.   Modify the "Password brute force by IP" to Threshold=1, BlockSeconds=(big number).  This will trap a lot of troublemakers.  

Ideally, you should be able to export the IDS blocked address list to a file so that it can also be loaded it into your mail store server or your firewall.  Might be possible with the API, but not easily accomplished using the web interface.