[tracker1]

I'd love to work on Cloudflare's underlying email platform... from pretty early on, I've felt like the workers model could be great for handling relatively short lived tcp connections, not just web requests... in this way, all the other facilities CF offers such as R2 and D1 could be used with an email platform that could scale incredibly well. With this acquisition, it's another natural fit into such a platform for email spam filtering and classification.

Definitely exciting to see.

[NicoJuicy]

Recently implemented it to only process emails where the sender is in the list of customers email and then extract info from email and do an api call.

Really easy to do it on the edge. No hassle with POP3, IMAP, ... Easy to use a subdomain of my email domain

Loc: ~40

[tracker1]

Did a CF worker for an email group list which worked well enough... having each email address target have to approve themselves was about the only hiccup. Definitely nice options all around.

Would be interested in seeing an Outlook/(o365/Exchange) alternative from Cloudflare with a bit more of a feature rich offering... or at least the ability to build something like that on CF.

[weitendorf]

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.

[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)