This topic got me thinking about the larger problem of how to minimize the attack surface so that the IDS configuration is less important.
Distinguish between user connections (authenticated protocols) and inbound email connections (unauthenticated SMTP)
I think the preferred way to do this is to use an Inbound Gateway which only accepts unauthenticated SMTP on port 25. This allows the gateway to be a honeypot, where a single authentication failure triggers an IDS block on the source IP without blocking any users. It also simplifies country blocking. The country blocking list for unauthenticated SMTP typically needs to be small, because legitimate infrastructure tends to be hosted on services spread across multiple continents. Country blocking for user connections can restrict client access from countries where you do not have users.
Our solution for user travel: Before travel, user makes us aware that she will be travelling. On arrival, she notifies us of her current IP address. We enable remote access from that one address for the duration of her stay. If she moves to a new location, she has to repeat the process. Inconvenient, but very safe.
Use a Web Application Firewall (nickname WAF, alternate name Reverse Proxy) to manage external HTTPS protocols differently than internal HTTPS protocols. This should have been possible every since SmarterMail switched to an embedded web browser on port 17017, because IIS is now functioning as a WAF to translate HTTPS on port 443 to HTTP on port 17017. if you have a WAF on a perimeter device, you can connect it directly using HTTP to port 17017. But SmarterMail is adding WAF support in recent versions, so there is probably now an option that avoids unencrypted traffic. I haven't found details about that effort yet.
Once the WAF is in place, you should be able to use path filtering to restrict which protocols are available. We allow EAS from cell phones and webmail, but we don't want users connecting externally with MAPI or EWS because those protocols imply client software that is doing long-term storage of corporate data on non-corporate devices. I have a source of information about the path used for different protocols which I will post as an edit when it is available, unless SmarterTools support is nice enough to post it first.
The WAF should also allow you to tailor country blocking to each of the HTTPS sub-protocols, if that seems useful.
Block the external protocols that you don't need. Do not allow client connections on port 25, since they can and should connect on a submission port (587 or 465). Better yet, migrate external users away from IMAP+SMTP and POP+SMTP so that you do not have to allow any form of SMTP from external systems directly into your mail store server..
Once you have a high level of granularity