The title says it all.
CA support may read on and reply, but if you are a DEV/power user/hack on the product read on, and share in my misery! hurrah!
What and why are there limitations for the Exchange agent to prevent silent blocking from being possible? Silently blocking is only available if there are client endpoints installed, and mail is inbound. There is no server based silent blocking capability, only INBOUND mail, which sucks, and is really messing up with late stages of my deployment. I can see why Data in Motion policies would avoid the Block Silently control action, as it requires a user facing popup, but in the messaging realm leave it configurable.
I am resorted to having to create DB triggers that check and confirm smart tags (once set correctly for this new custom action), then forcibly refactor/replace inserted (pseudotable) rows into the Wgn3Trigger table, (due to new event order of operations) and Wgn3EA tables to enforce my own BLOCK/NOTIFICATION procs. which cascade into generating custom HTML, dynamically formatted alerts--essentially replacing the dirty notifications the platform creates with beautified, interactive, helpful notifications for almost all causal interactions a user can come up with. This would not be necessary, if the appropriate functionality were available. We integrated with the iConsole webservices though (and found a lot of bugs with them!) to accomplish this, but anyway...
All other warnings and alerts, quarantine capture, quarantine release, quarantine reject, etc, were already easily replaced with custom HTML dynamic templates (all through the database and webservices) just fine... It just gripes me that there is no 'Block Silently' action with the ESA. I have had to spend many hours coding around this limitation.
All in all, its been a lot of lines of code to get the client to this point. Hacking the system to add functionality is fun, in the end. More to come, of course