Useful features for SM beta
Idea shared by Matthew Titley - 12/20/2022 at 9:13 AM
Hi all,

Three features that would be very helpful:

1.) Granular permissions for domain admins. I have a number of clients whom would like to give basic administration tasks to staff (creating accounts or aliases, etc) but they don't want them to have access to the domain email archive. Right now this is impossible in SM. They ask me regularly if ST intends to implement this.

2.) Escalating IDS IP bans. Right now, IP addresses that trigger an IPS threshold get a time defined temp ban. I think that if the same IP keeps coming back after some set number of attacks it should go on a perm ban list. I have a client in AWS with open RDP (yeah... I know...) using a port of fail2ban for Windows. There are few like EvlWatcher, IPBan, RDPGuard, that do much the same thing. They have some good logic in them. Although their IP ban list keeps growing, it has made a significant impact on reducing the number of attacks. Without an automatic permanent ban option many attackers just keep coming back.

3.) Scheduled reports. It used to be in SM and was removed. A few clients liked to keep tabs on sales reps to see how many emails they were sending out weekly. In SM 15 you could schedule a variety of HTML formatted reports to be emailed with pretty charts and graphs. It was nice. Did it help me? No, but many of my hosting clients loved it and were irritated when it was unceremoniously dumped for no good reason.

I know I've mentioned these many times over the years. I don't understand why they can't be implemented.



2 Replies

Reply to Thread
Andrea Free Replied
Employee Post
Hi Matthew, 

Thank you for participating in the BETA and sharing your requests! I have some feedback for each.

Granular permissions for domain admins
This sort of functionality seems easy on the surface, and it sounds like it could be helpful for some who do want that sort of granularity. However, a common issue that can occur when building and managing software is that the product becomes bloated and over-complicated, and things that were added to bring value to the product can end up being a detriment instead. In the 20 years we've been building products, we've gone through many cycles of over-complicating/over-configuring and then simplifying the products. It's this experience that helps us to know the criteria needed to bring in new functionality, and, unfortunately, this level of administration can't be accommodated.

Escalating IDS IP bans
This is on our list to bring into SmarterMail. I'm not sure whether this will make it into the upcoming final release or whether it'll be included in a future build, but we do have a task to look into the possibility of allowing Admins to blacklist IPs that get IDS Blocked X number of times. For now, you'll find that the BETA includes a new column in IDS Blocks: Blocks in 30 Days. This new column will help Admins to recognize the repeat offenders and blacklist them from the IDS Blocks grid. 

Scheduled Reports
We have some metrics regarding the utilization of the products, and scheduled reports were very rarely used. As such, we removed this feature from multiple products a couple years back. At that time, we got a handful of complaints and concerns. However, the lack of substantial feedback helped to justify the decision to remove it. I'm afraid there are no plans to bring back scheduled reports at this time.

I hope this helps shed some light on these requests, Matthew. I know this will be somewhat disappointing to hear, but I do hope you can understand our reasoning as well. And I hope to continue hearing your feedback throughout the BETA on the functionality we've added and the features you're still looking for. 

Kind regards,

Andrea Free
SmarterTools Inc.


Would also be awesome to have the ability to specify if an SMTP port requires authentication or not. We have several customers who's security software complains that unauthenticated mail is allowed over port 587. A checkbox under the "Port" modal for SMTP protocol that says "Require Authentication". Obviously, SMTP Auth Bypass IPs would still pass through.

We have also found that if we block public access to port 25, some spammers have figured out that they can simply send mail to port 587 and SM will accept it. So this fix would also prevent unauthenticated mail from being sent over an SMTP port.

SM would respond with an error code 530, indicating that authentication is required.

Reply to Thread