Sievepad is built on Monaco (the editor component behind Visual Studio Code) and executes scripts with sieve-rs, the interpreter inside Stalwart, compiled to WebAssembly.
433 karma · joined April 14, 2022
https://stalw.art/docs/install/upgrade/
The goal is to stabilize the database layout/configuration format very soon so v1.0.0 can be released (hopefully before Q1/Q2 2026).
It’s also worth noting that only about 5% of the codebase is Enterprise, and that small slice helps fund ongoing development and expansion of the team [1]. As much as I'd love to be completely sponsor-funded, the reality is that open source projects still need to cover real-world costs. For what it's worth, Stalwart has received two NLNet grants [2] [3] to support open protocol work, which hopefully reinforces our commitment to open source.
So while the optics of this situation may look rough from the outside, I promise it’s not some “open source in name only” kind of thing. It’s just one of those painful balance acts between building features, maintaining packages, and paying the bills.
And hey, if you're heading back to Maddy, no hard feelings. But the door’s always open if you want to give Stalwart another shot down the road.
[0]: https://stalw.art/docs/development/compile [1]: https://stalw.art/compare/#faq [2]: https://nlnet.nl/project/Stalwart/ [3]: https://nlnet.nl/project/Stalwart-Collaboration/
To give you more context about the project: Stalwart Labs was indeed started and is currently led by a single developer: myself. I have over 30 years of experience working with email technologies and have previously founded three email-related companies.
That said, I’m not working entirely alone. While I’m the core developer and founder, there are others involved in Stalwart Labs today handling support, sales, and maintaining smaller parts of the codebase (mostly changes required by clients). My plan is to continue leading development myself until the project reaches version 1.0, which I hope will happen later this year. After that milestone, the goal is to gradually expand the development team, particularly to support work on a Rust-based webmail and calendar interface that will complement the mail server.
Stalwart’s development has been largely self-funded, aside from two NLNet grants. I’ve been growing the team organically and intentionally. While I have been approached by two VC firms, I’ve chosen to decline their offers. Not just to avoid external pressure (and stress), but also because some proposed directions conflicted with promises I’ve made to the community. For example, there have been suggestions to move some open-source features behind a paywall, which I’m against and promised the community never to do.
As for enterprise support, yes, Stalwart Labs offers an enterprise license that includes premium support services. And regarding adoption, I'm happy to say that there are currently a few hundred enterprise clients using Stalwart in production. While I would need the clients' permissions to share their names, I can say that Mozilla Thunderbird is one of them. They’ve publicly announced their upcoming launch of thundermail.com, which is powered by Stalwart.
I hope that gives you more clarity and confidence in the project. Thanks.
That said, I personally value privacy highly, which is actually one of the main reasons I started Stalwart Mail Server. I don't maintain a personal presence on LinkedIn or other social media platforms, not because I'm trying to be anonymous, but because I prefer to focus on the work rather than promoting myself. I’ve found that platforms like LinkedIn are more noise than signal for me, especially with constant recruiter spam.
That being said, Stalwart Labs as a company is far from hidden. You can find our company page on LinkedIn here: https://www.linkedin.com/company/stalwartlabs/. We're also active on:
* Mastodon: https://mastodon.social/@stalwartlabs * Twitter/X: https://x.com/stalwartlabs * Reddit: https://www.reddit.com/r/stalwartlabs/
While I may not be putting my personal life on display, I’m committed to transparency where it matters most: through the project’s code, documentation, and community engagement. I hope that helps clarify things!
Excited to announce that Encryption at Rest has just been added to the open source Stalwart Mail Server. With this addition, the mail server will now automatically encrypt all incoming plaintext emails, utilizing either OpenPGP or S/MIME, before they are written to disk. Importantly, the keys are owned and controlled by the end user, ensuring that not even system administrators can decrypt these messages.
I'd love to hear your thoughts and feedback. Thanks!
https://stalw.art/docs/smtp/inbound/data#content-filters https://stalw.art/docs/smtp/inbound/data#spam-filtering
Only from enthusiasts, the main problem is that there are very few email clients supporting JMAP. Big players such as Google and Microsoft do not seem interested in JMAP so adoption has been painfully slow so far.
> What is stalwarts relationship to Fastmail, do they use stalwarts software?
No relation. Fastmail uses Courier IMAP as far as I know.
I'm excited to announce the release of Stalwart Mail Server, a single binary solution that combines the Stalwart JMAP, Stalwart IMAP, and Stalwart SMTP servers into one easy-to-install package.
In response to your feedback, some key enhancements were made. Stalwart Mail Server now supports LDAP and SQL authentication, providing seamless integration with your existing infrastructure. For single node setups, RocksDB has been replaced with SQLite with the option of using LiteStream for replication. For larger, distributed setups, support for FoundationDB was added, letting you scale to millions of users without sacrificing performance. Additionally, it is now also possible to store your emails in an S3-compatible storage solution such as MinIO, Amazon S3, or Google Cloud Storage.
Other notable updates include support for disk quota, subaddressing (or plus addressing) and catch-all addresses.
Check it out here: https://github.com/stalwartlabs/mail-server
I look forward to your feedback and questions!
This point you mention is being improved. The next release of Stalwart JMAP (expected in one or two months) will delegate user management to either a SQL database or an LDAP directory. Messages will be stored in either Maildir or MinIO/S3. And all other information will be in either SQLite or FoundationDB. All these features were already implemented except MinIO/S3. Development progress can be tracked at https://github.com/stalwartlabs/mail-server/tree/main/crates...
Not sure what do you mean with application device specific passwords? Currently Stalwart JMAP only allows registered accounts to login using a password which is stored encrypted with Argon2. Authentication can be done using the OAuth or Basic mechanisms. There are no additional passwords specific to a particular device. Not sure if this answers your question though.
My long term plan is to make an open source alternative to Google Workspace (not just e-mails and calendars but also Documents, Spreadsheets, etc) but I won't be able to do all that by myself so that is why I'll start looking for funding in the near future.
At the moment backing up the raw messages can be done by copying the blobs directory. However backing up the metadata (which is stored on RocksDB) is not yet supported but will be added on the next release. RocksDB has support for checkpoints and backups so adding the backup functionality is pretty straight-forward. In Stalwart JMAP there is a single master user which is the administrator. Continuous backup will be implemented as a housekeeper task which can be run on a schedule or manually triggered by the administrator.
> Is it possible to use any OIDC server on the IMAP proxy?
The IMAP proxy supports the OAUTHBEARER authentication scheme but using third-party OIDC server is not supported at the moment. However, once the SMTP server is out I plan to add support for other SASL mechanisms on the IMAP proxy (since some of the work will be shared with the SMTP Auth module).
> Do you support password authentication for legacy applications (preferably application and device specific passwords)?
Yes, the IMAP proxy supports both the LOGIN and AUTH=PLAIN mechanisms.
> Also, is it possible to export the mails and the state, so if this project does not work out, there is a way out?
E-mails can already be exported by copying the blobs directory (only the raw messages are stored under that directory). To export the metadata and folder structure any IMAP backup tool or service could be used.
Data is replicated using the Raft consensus protocol and when multiple nodes go down the cluster will keep keep active unless there are not enough nodes to guarantee consistency. More details can be found on the documentation [1] but I plan to add more details on how replication works once the server passes the Jepsen tests.
> Also, have you considered implementing server-side encryption of e-mail messages so that a "honest but curious" system administrators could not read user's messages? (e.g. using the user's password to derive an encryption key). More generally, what are your thoughts on the "privacy" aspect?
Yes, in addition to server-side encryption also S/MIME and PGP are on the roadmap.
Yes, Stalwart IMAP server's compliance to the IMAP4 protocol was tested using Dovecot's ImapTest tool.