No specific feature for handling invalid addresses differently, but it might be a good feature request.

You should assume that if they are attacking SM, that they are attacking any other access paths as well.

To that end, it is useful to mimimize the number of accessible protocols, and to restrict different protocols differently.

Our loosest protocol is unauthenticated SMTP, because it is hard to know all sources of legitimate traffic.  So use an inbound gateway for that function only, and lock every function on your main server much more strictly.

Our brute force block by IP address is extremely long lifecycle and detection. That's where we get the "slow-rolling" attacks from IPs that will try an account -wait a day, try another one, etc.

On our servers, you get 5 chances across 5 days -- and then that IP gets locked at our firewall. We have a web-form if a user can't get in and we go from there to restore their access. The number of hacks we've caught this way (especially someone trying to break into an account using stolen data) has been very successful. The users have been very understanding when it is explained this is for security purposes - it's better to get inadvertently locked out than to leave things "looser" and just let it rip...

Brute Force by Email Address is much looser and has a shorter lifecycle. We rarely if ever see an account fall to this one.

Legit logins won't trigger the IP detector - only bad ones - and bad ones won't hardly ever come from legit users because they save their passwords - like 99% of the time... The only time our legit users have had an issue is if they change their passwords but don't manage to update their devices. Our web-form also facilitates them alerting us for these situations so we can resolve.

We have pretty much abandoned any form of IP blocking. The country block list turned out to be our biggest enemy and manually blacklisting IPs is time consuming. For us, the issue was staff working from home or off mobiles. Whilst we are based in the UK, we regularly see authenticated access from Ireland, US, Sweden, Italy and many others. We tried to set the country list to allow all the ones that popped up, but as senior management pointed out, they want to know that if anyone goes abroad, they should still get emails.

I have asked for a feature update where the email address itself is blacklisted (security/blacklist) as we see that same email address being used over and over again. They are always "singleword"@ whereas we use a different format, We set up a long list of fake email addresses in the SMTP list, but that doesn't seem to do anything

Agreed that IP blocking can be time consuming. 

We use a logfile monitor that detects the IDS entries and blocks them at our edge for 30 days... Additionally, we monitor the SMTP / IMAP logs to watch for a known list of attempted accounts (or accounts without a domain), and those get an autoban for 90 days...  IPv4 turnover means we can't block forever - but this time span seems most effective...

We're working on a custom solution that can read last known good authenticated IPs and give those some weight to compensate for when a user may be changing a password - to prevent the IDS from flagging those IPs while the account settles down. The same concept for use where we're having with bad NTLM coming from a handful of iOS devices that keep false-triggering an IDS blockade...

We're a US based provider, and the country blocking is effective as we limit authentications to a handful of countries our clients are present in. We recommend/require a VPN when connecting from outside those countries for multiple reasons - adversarial and insecure networks being one of them. Reducing the brute-force footprint is another.

Unfortunately no simple solution.  What I did was setup an script on my website (checkfailedlogins.aspx) this script opens the SmarterMail Logs and reads them line by line to determine if there was a failed login attempt.  If it finds a failed login it adds the IP to my firewall.  I have the script setup to run every 5 minutes via Windows Task Manager.  When the script finishes is saves to a mysql database what the last line was, so next time it runs it starts at that line instead of the beginning.  I also have my script setup to look for login attempts with accounts that have never been on my server.  Often times these bots try using various common login names.  If they use one of those its firewalls the IP.