Some background on my issue and a proposal list at the bottom on this message. We are running SmarterMail version 15.5.6284 Enterprise. I got a call this morning from one of the companies we host that a user could not send out emails from the web interface. A red bar appeared at the top of the screen and indicated that the user could not send email because of previous suspicious activity. So going through my logs I found where several emails bounced back to the user in a short time frame which triggered the Bounces Indicate Spammer security rule like it should have. That's all good but the issue became, how do I unlock this user's account so they can send their email?
I checked the Current IDS blocks and there's no listing in there for this user's IP or any listing for the Bounces Indicate Spammer security rule. So I proceeded to check the actual user account listed under the domain section and the user's account is listed as Enabled. Searching further through all the security settings and domain listings I still don't see an area where I can de-list this user's email so they can send the message they wanted to send. I even went as far as logging into the console of the server and checked through several config files and still turned up nothing.
So in the end I restarted the SmarterMail service and that cleared this up. There's a major catch to that though, all the IP's that were listed under the Current IDS blocks disappear and start over again. I am assuming the list is memory resident and not cataloged somewhere. Plus this is super inconvenient to have to restart the SM service in the middle of everyone's day just to clear something like this out.
So why is there not a place that I can go to clear this out for this user that doesn't require restarting the entire mail server service? We have a rule for it, so why not have a place to clean it out if need be?
So I have a few proposals here and I believe this would be a huge benefit for everyone:
1. Current IDS block section should be listed to a XML file ,text file or something like a MYSQL table or SQL table that SM could read from when the time comes to police someone or if you need to reboot the server SM doesn't lose what it had before. This could also cut down on memory usage of SM because your not storing all that data in resident memory. You are only looking it up as needed.
2. Abuse rules per user: We really need to have a screen where we can go to in order to remove a user off the list instead of having to restart the SM service to remove someone from this list. Besides, what if you have 1 user you want to remove but have another user on the list that should not be removed yet because of an issue that still needs to be taken care of. This would be things like Internal Spammer or Bounces Indicate Spammer.