- JMAP Core, JMAP Mail and JMAP over WebSocket full compliance. - IMAP4 rev2/1 support via Stalwart IMAP, an imap-to-jmap proxy [2]. - Scalable and fault tolerant: consensus over Raft, node autodiscovery over gossip and read-only replicas. - RocksDB backend with full-text search support in 17 languages. - OAuth 2.0 authorization code and device authorization flows. - Domain Keys Identified Mail (DKIM) message signing. - Written in Rust. - No third-party software required to run or scale.
The next item on the roadmap is to release an SMTP server in Rust with the goal of making self-hosting an e-mail server much simpler.
Any comments or suggestions are more than welcome!
[1]: https://github.com/stalwartlabs/jmap-server [2]: https://github.com/stalwartlabs/imap-server
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.
That said, I think I'll find some time to give Stalwart JMAP a try. I've been curious about JMAP for a while, and there are a couple things about Dovecot I'm not too fond of...
As a serializer/deserializer efficiency goes, wouldn’t Binary Serial Object Notation (BSON) have made more sense?
However, I am duly impressed with how Stalw.Art takes it to the next level with their consolidation of many protocols under one build tool by language and fewest toolset needed (no Autotool, grep, awk, automake, multi-C suppprt, Flex, Bison).
A very nice job.
Probably any structured data like json would be fine, it's basically bikeshedding to argue about json when the real driver behind JMAP is the previous state of email's crustiness
Maybe the old foggity in me is yearning for the good ol’ Text-only SMTP days that were spam-free.
Excuse the pessimism here but we are still perpetuating the weakness of SMTP-related backends, notably HTML inclusion into RFC 822, no?
I see increasing prevalence of link tracking of emails by those who commercialized IMAP … and now JMAP. However, I hope to see more private mail servers but that future of privacy remains cloudy.
Some might say that if someone can't setup Postfix, they've no business self-hosting an email server in the first place.
Some might say that if you cannot setup Linux manually yourself (without any installers), they've no business running Linux. Also, you are not allowed to use a library unless you can manually put together the compile command without any Makefiles.
Or you know, we can make the whole process easier with less pitfalls, so more people can enjoy the beauty of open ecosystems :)
In my mind, the reason I chose nginx every time wasn't because of performance, it was because I hated apache's config files. Ergonomics are important
I also work on a Rust IMAP server that is far from being as feature complete as yours. I also chose your `mail-parser` library to parse RFC822/5822, but we observed that in many cases, we did not have enough information to build some BODY/BODYSTRUCTURE responses. We also discovered that line count and many details are not very obvious on IMAP, did you run some tests to compare your IMAP server outputs to existing servers? Or, more generally, what is your approach to ensure compatibility / integration with the existing email ecosystem?
In any case, congratulation for your project, we will follow it closely! I experimented how big these protocols became with all their extensions, this is an impressive work!
Yes, Stalwart IMAP server's compliance to the IMAP4 protocol was tested using Dovecot's ImapTest tool.
There’s also the vSMTP project: https://github.com/viridIT/vSMTP
What's the backup story like? Can the whole state be restored from the mail storage (I assume not)? Do you support "master users" (as in dovecot) so that I can do a continuous backup with dovecot sync?
Is it possible to use any OIDC server on the IMAP proxy? Do you support password authentication for legacy applications (preferably application and device specific passwords)?
Also, is it possible to export the mails *and* the state, so if this project does not work out, there is a way out? (Here dovecot sync might also work.)
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.
> 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).
It would be great to allow another OIDC server (to have single sign on and MFA) without having to run another SASL server.
> Yes, the IMAP proxy supports both the LOGIN and AUTH=PLAIN mechanisms.
How are application-device-specific passwords handled? Is there some documentation?
I have a Dovecot mail store ~(10gb of mail) on Mailcow (which is Postfix and Dovecot under the covers) and tools like mbsync fail to pull all my mail without multiple invocations. I've been looking for a migration path off it.
When I migrated to this system, I found an IMAP to IMAP script that I had to fiddle with and hack, which tool roughly a day to complete. I'm hoping for a more straightforward migration path in the future.
I think once things are a bit more settled, I'll be interested in the client end of things... That's something that I didn't see much on the Stalwart website. Yes, I'm sure I could run the same set of tools now, but that seems like a waste of an opportunity.
I think which license you use has less to do with number of contributors or "prosperity" than other things happening in the project.
I'm even a Signal subscriber, and just didn't think about that aspect of their shared source model.
I mentioned number of contributors as that attribute is generally predictive for longer running, healthy projects.
Can you talk a bit about how data is replicated between nodes when Stalwart is run in clustered mode, and what kind of data integrity/resilience properties we have when one, two, several nodes go down?
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?
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.
The docs are missing the most important part...
As I user of Fastmail I don't care that much yet, as I can use the Fastmail app and any of the IMAP apps, but if I were to move to a self-hosted solution, that would be a big deal.
For those unaware, Fastmail was the party who created, built and open sourced JMAP (with many others contributing).
This took over 5-years of work for Fastmail to complete and projects like above wouldn’t have been possible without them.
We take for granted that no other company is advancing the development of email and its open standards, without it being behind some proprietary paywall (Eg Google, Microsoft, HEY).
If you haven’t tried Fastmail, I encourage you to do so. Their web mail client is fantastic (and unbelievably fast).
https://fastmail.blog/open-technologies/jmap-new-email-open-...
