Howell,
I'll try to address each of your points here.
1. "Password Brute Force By Email" should be logged against an IP Address which would allow the "real" user to continue to login without an issue while ONLY blocking the hackers. This also does not tell us the source SMTP, POP, IMAP, WebMail, EAS, EWS nor MAPI.
The Password Brute Force by Email rule type is designed as a measure to interrupt distributed attacks - that is, multiple attempts to authenticate an account from multiple IP addresses. In such attacks, it is likely that no two triggering authentication failures come from the same IP address, so there isn't typically a single IP to block when the rule is triggered.
Password Brute Force by IP is designed to address multiple attacks coming from the same IP address. whether the attacks are against the same account or not.
If you are seeing many cases where the Password Brute Force by Email rule is being triggered by failed attempts from a single IP, it may benefit you to add a Password Brute Force by IP rule. If you already have a brute force by IP rule, it may be worthwhile to review the limits on your rules and consider adjusting them to better handle the specific types of attacks you are seeing.
As for the source of the block, IDS rules currently work independent of protocol. This means that the rules can be triggered even if the attacker spreads their authentication attempts over two or more protocols. However, if you check the administrative logs, you should see entries like this to help you track down which protocols are being used in the attacks:
00:15:06.639 [98.185.70.250] MAPIEWS NtlmAuthenticate Login failed: Authenticate parse failed for <user@example.com>.
Brute force attempts increased to 1 of 25 in 5 minutes.
User brute force attempts increased to 1 of 50 in 10 minutes.
Next clean available at 8/30/2023 12:15:56 AM2. If you have 2FA enabled and you enter a bade 2FA Code it is logged into the Administrative Log, however, the IDS does not block this as it would with just a username and password.
This sounds like a potential bug. Please open a support ticket so we can gather more details.
3. We needs IDS Rules for EAS, EWS and MAPI as these protocols are getting very popular
In the current version of SmarterMail, most of the IDS rules are protocol independent and will track failed authentications for webmail, IMAP, POP, EAS, EWS, etc. The only exceptions to this are the "Bad SMTP Sessions (Harvesting)" as that rule is specific to an attack that only works over SMTP, and the "Internal Spammer" and "Bounces Indicates Spammer" rules which operate at the spool level.
3. For the IP Address BlackList we don't have an option to block access to Web Mail by IP Address
The current implementation of the IP Blacklist is designed to prevent socket connections, which are easily managed for IMAP, POP, and SMTP. Webmail, EAS, EWS, MAPI, and WebDAV are all HTTP based communications, so they have not been made options in the IP Blacklist. However, with some of the changes we are working on, we have been discussing how we can add these protocols as options for the IP Blacklist and Whitelist.