Hi Matthew, 

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

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.

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. 

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,

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.