Some email is considered too sensitive to send using ordinary SMTP, and encryption via web relay is the preferred solution. Zixmail seems to have been the first vendor to offer this feature, and now this feature is provided by most of the email filtering products. I don't think even Zixmail is offered as a standalone product anymore.
I currently use an email filtering appliance with this capability, but the product has a limited future because the vendor is moving to a cloud-based offering which is priced per-user and costs much more. Several of us are finding that we can build good replacements for inbound filtering products using Declude or rSPAMD, but this leaves us without a solution for outbound encryption.
I might be able to build my own, but my conceptual design requires incremental licensing for SmarterMail, so I think SmarterTools is the best one to create the product.
Conceptual design:
We currently trigger encryption in response to specific senders, specific recipients, specific keyword in the subject text, or embedded content with Social Security Numbers. The selection rules don't really matter as long as the final result is a message header with a value that tells SmarterMail to encrypt.
When encryption is triggered, the original message is redirected to a special destination, and the intended recipient is given a replacement message telling them to pick up their message from the secure website. For vendor products, the special destination is hosted by the vendor, and the replacement message is sent by the vendor. I have never liked this configuration because it requires trusting a third party to handle my messages securely. So a SmarterMail-based system should be hosted locally on a second server configured for this purpose.
I suggest that the special destination can be configured with accounts of the form:
When encryption is needed, a script checks to see if this account already exists in the special destination, and creates the account if necessary. Then it re-routes the message to that destination and creates the replacement message indicating that the message should be picked up. This is the first piece of required custom code, and I suspect that I could create all of it in Declude if I was doing it myself.
To prevent the special destination from growing without limit, inactive accounts need to be disposed of based on local policy timers. This is the second piece of custom code.
The final piece of custom code is the trickiest. The user should only be able to reply to his received messages or create new messages to users at [mydomain] that have sent him a message.
Is there a market for this solution? I hope so.