Stalwart v0.16: A New Foundation
34 points by pl
34 points by pl
mox is an alternative that isn't open core, you get all of the features for free (for me, multiple domains, each with very little traffic, is important)
Stalwart has multiple domain support in core, it's multitenantcy (each with their own set of domains) that's in enterprise
So if I were to use the free community edition and several domains, would the exact same localparts be available on all domains, or could those be different?
You can add an alias to a domain, so that if you have example.org with example.net as an alias, both a@example.org and a@example.net will get in the same mailbox.
You can also create separate domains which are not linked (other than that they're present in the admin UI).
The admin creates a user with a primary address (localpart@domain.example), and can assign multiple aliases to that user, that will all go in the same mailbox (e.g.: sales@example.com).
The admin can also rather choose to create multiple users with their own mailboxes and addresses.
The full structure:
This will result in these mailboxes:
All of which are visible in the management UI for the admin, unless you have the enterprise edition with multi-tenant.
(Edit: Changed the example addresses, as there were some errors).
And multitenancy is that you can have separate tenant organisations, each with their own admins and domains that don't interact with each other?
The fact that most errors with setting up an email service is with DNS, and they now manage every required record, makes this an amazing release just for that reason.
This covers most of the authentication and discovery story out of the box. SPF, DKIM, and DMARC records are managed alongside autoconfig and autodiscover SRV records, CAA records for certificate issuance authorization (including the accounturi parameter for account-scoped issuance), and TLSA records for DANE. The TLSA records are automatically refreshed when ACME certificates are renewed, so DANE-enabled domains no longer risk a validation gap during certificate rotation.
In previous releases, Stalwart was managed through a REST API that lived alongside its native JMAP interface. In v0.16, the REST API is gone. Every configuration and management action is now a JMAP object, reachable through the same /jmap endpoint that already serves email, calendars, contacts, and files.
The benefits of this change are hard to overstate.
I agree. People not familiar with JMAP might not realise how big a deal using JMAP for an API really is. (Honestly I’m surprised they weren’t using a JMAP API already, and am curious why they weren’t.)
People often assume JMAP is a Mail Access Protocol, as IMAP is, but it’s actually a general-purpose object synchronisation protocol, and that’s a big deal. APIs over HTTP (REST, GraphQL, whatever) almost always start out with just representing current state, and then they steadily grow ad hoc synchronisation, sometimes for full offline support, sometimes just for caching and latency compensation. And it always goes wrong, and going wrong often means data loss.
JMAP is an object synchronisation protocol, principled and robust. Build correctly atop its primitives, and synchronisation is simply solved, with bonuses like batching (of the type that can save entire round-trips) and push notifications.
It’s not the only solution to the problem, by any means, and it’s not perfect (I suspect the most common complaint might be that there are no code generators like for OpenAPI, and the specs aren’t machine-friendly), but it’s the best web-compatible, general-purpose, client–server one that I know of, by quite some way. (More recently, it feels like there’s more interest in real-time text-collaboration client–client designs, using CRDTs and such. But plenty of systems still want or need other modes of operation.)
(Personal credentials: I worked on Fastmail’s webmail for three years, 2017–2020, before life took me in a different direction. During that time, rjbs and I wrote a Modern Major-General parody, beginning “It is the very model of a modern syncing protocol”.)
Passwords can also be given explicit expiration and rotation policies
I’d like to understand why they’d implement that. It’s been well-known for a long time that rotation policies are a horrible and counterproductive idea, and even NIST finally started recommending against it a couple of years ago.
(The ability to expire compromised passwords is useful, but rotation is not.)
I’d like to understand why they’d implement that. It’s been well-known for a long time that rotation policies are a horrible and counterproductive idea, and even NIST finally started recommending against it a couple of years ago.
Not everybody is as up-to-date as you (and, finally, NIST) are. There are plenty of places, perhaps with less sophistication, that still demand password rotation. I also know PCI DSS 4.0 still requires password rotation in certain cases.