We prevent scripts from running by not allowing you to view HTML versions of the message. The message itself remains intact on disk as is, but we can't have javascript or dangerous html entities running from the browser. Someone could inject JS that controls your page, allowing them for example to steal your authentication token allowing their server to make authenticated calls on your behalf. Do to the extreme nature of this type of attack we erred on the side of caution on some of the things we allow in HTML. However, I have also noticed an increase in messages that are being detected due to <forms> in the message. Could you send me the raw/HTML content of one of these emails to my DM's? I'll run it through our filter locally and see why it's being detected.
If we can get a solid base of examples I can go through them and maybe we can loosen up the checks on these messages depending on what they are doing.

Sent Matt, thank you

On our side, we prefer erring on the side of caution, so the current behavior is fine. We`ve seen too many hijacked accounts and infections coming in via email, so let`s keep blocking scripts and dynamic content, but of course without actually touching the mail (currently the mails are not touched, just that they will not display this content when viewed in the browser). 

Outlook also does this by default and it`s OK. For the mails that we know to be trustworthy, we`ll manually allow the content to load and run.

That's the problem though Ionel, there is no option to LET THEM RUN.

It is a hard set BLOCK which cannot be overridden.  So clients are not

able to see the contents of these messages at all at times.

You can see these messages in all their glory using a dedicated client, as far as I know. 

For messages that just have remote content, you can simply click on "show" to force load it.

The thing is, web clients are nice, but pose a problem when the message has such scripts because if compromised, they can escalate to compromise the whole system. Having seen damages from countless infections because people desperately want to click on a link despite all warnings, I personally am all OK from blocking them if there is a high chance that the message is dangerous - at least as the default behavior. 

Of course, giving administrators (and even users?) the option to disable safeguards should also be an option, maybe with a disclaimer absolving the service provider and SmarterTools of any responsibility.