If you (or others here) are truly interested in email+tcp proxying+workers-like-computing, then I have work to offer you in the build out of my company’s network/computing platform.
This is something that you can or could already do with Envoy proxy with the right amount of polish, knowhow, and elbow grease (which we have).
What Cloudflare doesn’t have are good general computing products and multitenancy supprt. But we have those, something like D1, and something like a remote tunnel that runs in your browser. So users can launch Stalwart instances painlessly and use our secret magic to render it in actual browsers without special middleware or extra state (or we could offer shared/default Stalwart to do it completely out of the box). So that would take you the rest of the way from platform-level email to application-level and user-level/managed email.
What we don’t have is the time to spare in productizing that and handling the email-specific routing in envoy, or finding capable/knowledgeable people who know all the email-specific content and skills. So hit me up if that's you, and otherwise, feel free to run wild with the knowledge that you can configure Envoy Proxy with an L4 network filter or HTTP filter that delegates to dynamically loadable/configurable wasm if you want a hackable Cloudflare workers or even a platform-level alternative (hint: store wasm code in FUSE). The L4 filter should work for email filtering.
[2] https://mail.mplode.dev (demo/test Stalwart instance we're running in our dev environment. Platform magic would allow us to render an email client directly embedded in https://brilliant.mplode.dev via remote IMAP/POP3)
This is something that you can or could already do with Envoy proxy with the right amount of polish, knowhow, and elbow grease (which we have).
What Cloudflare doesn’t have are good general computing products and multitenancy supprt. But we have those, something like D1, and something like a remote tunnel that runs in your browser. So users can launch Stalwart instances painlessly and use our secret magic to render it in actual browsers without special middleware or extra state (or we could offer shared/default Stalwart to do it completely out of the box). So that would take you the rest of the way from platform-level email to application-level and user-level/managed email.
What we don’t have is the time to spare in productizing that and handling the email-specific routing in envoy, or finding capable/knowledgeable people who know all the email-specific content and skills. So hit me up if that's you, and otherwise, feel free to run wild with the knowledge that you can configure Envoy Proxy with an L4 network filter or HTTP filter that delegates to dynamically loadable/configurable wasm if you want a hackable Cloudflare workers or even a platform-level alternative (hint: store wasm code in FUSE). The L4 filter should work for email filtering.
[0] https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overv...
[1] https://github.com/proxy-wasm/spec/tree/main/abi-versions/v0... (where you'd start implementing email filtering logic)
[2] https://mail.mplode.dev (demo/test Stalwart instance we're running in our dev environment. Platform magic would allow us to render an email client directly embedded in https://brilliant.mplode.dev via remote IMAP/POP3)