161–170 of 204 posts
We need better client support for JMAP. Apple Mail, Thunderbird, Outlook (as if), and so on. I'm surprised some of the smaller ones like Canary or Spark don't implement it as a product differentiator.
Serious question: what’s the differentiator if major email providers don’t support it? (This should not be interpreted as a defense of IMAP.)
Earlier quoted context omitted.
We're working on it. We still use an unholy set of earlier versions of JMAP internally for our contacts and calendars; in particular the caldav_sync code is gnarly - I wrote it over 10 years ago when I knew less about calendars than I do now! It's still using an earlier branch of what became the perl Net::CalDAVTalk library interally, even though our frontend API is an almost-up-to-date version of what will become th…
Aside, this bit that Neil and the team are working on is something I think is the 'next big thing': https://www.ietf.org/archive/id/draft-ietf-jmap-emailpush-01... The next, next big thing would be the Chatmail relays[1] supporting JMAP based servers (right now it's Dovecot) and this new targeted push extension for faster notifications without battery drain on mobile. I can see how the Fastmail mobile client will ben…
I can understand why JMAP instead of IMAP given the latter's antiquated design. I don't see the advantage to clients in replacing WebDAV though, and the others are a bit iffy too. They'll need to make a way better sales pitch than 'JSON vs XML' (serialization ain't tough, XML is supported everywhere). I guess contacts/calendar follows JMAP naturally when the clients already implement it, but that only applies in the…
I think we're about ten years past the point where "newer = better" was a reasonable starting presumption.
Earlier quoted context omitted.
This should be pretty straightforward to do with an IMAP IMAP syncing tool, like mbsync [1]. You'd run it periodically in the background to sync the remote IMAP to Stalwart's local IMAP server, and Stalwart can then automatically serve that via JMAP, doing the translation internally. I was originally thinking you'd need to go remote IMAP maildir Stalwart IMAP, which would be really complicated, but I think the IMAP I…
imapgoose which was recently featured here I think is another option: https://whynothugo.nl/journal/2025/10/15/introducing-imapgoo...
Earlier quoted context omitted.
It's one tiny binary that does everything you could possibly need for hosting a mail server, including an admin UI, and you get a bunch of modern and convenient features for free. For example, it automatically handles Let's Encrypt certs for you. You get JMAP, CalDAV, WebDAV, CardDAV, IMAP4rev2, DKIM/SPF/DMARC, MTA-STS, DANE, spam filtering, SQL+blob+object storage backends, search, clustering, OpenTelemetry, etc all…
What you’re describing sounds like one huge downside to me, not and advantage. The only way to adopt Stalward is to drop everything else and use a single monolithic do-it-all? Messages are stored in a bespoke format and not easily accessible directly? It doesn’t sound like it’s made to be usable with other software. This isn’t an advantage in my book.
Between all the options, you can design incremental backups, snapshots, or whatever with 3rd party tools to write a script to backup your mailboxes to be restorable in any other email service or software. I have tested it with rsync, restic, database dumps, mc/aws-cli depending on the backends used, of which I have tried them all, and found it designed to be very straightforward.
The monolithic aspect is a necessary aspect of being built for HA and distributed environments that it is all the more impressive how versatile it is.
Earlier quoted context omitted.
It’s not that I cannot appreciate the improvements in the space, I’m just wondering if there might be a big part of the design space for widely used protocols that ends up unexplored because the default for almost anything now is HTTP. It has basically become OSI layer 8 at this point.
HTTP/3 replaces parts of OSI layer 4 (TCP/UDP). There's a perspective that HTTP has been trying to lower its layer for decades. Especially the way that TLS originated as HTTPS but now is almost a "universal" vertical chunk of Layers 4, 5, and 6. In that perspective HTTP is probably the new Layer 6.
I recommend actually reading X.200 (the specification of the OSI model) at some point: it's quite approachable (especially for an ITU spec, which are notoriously dense reading), and will quickly make you realize how silly it is that we still use it as a reference for modern stacks.
What next? Replacing Sieve with something cumbersome, but JSON based? There is no good desktop implementation of MUA with old technologies (IMAP, Sieve), will all this JMAP help? I don't think so. What is profit to have good server with new good (assume it is good, I'm not sure, but lets assume) protocols without good client? IMAP4 is underused by modern clients: it allows to effectively store client configuration on…
Solved problem? Dovecot can't handle UTF-8 to this day. Things like Stalwart do try and change that and actually support non-legacy features. (Though I think Stalwart doesn't do IMAP NOTIFY either.) Clients on the other hand have actually kinda moved forward, Apple Mail works with IMAP servers and offers features that people only got with Gmail before. But there are many other examples as well.
I don't have any problems to use UTF-8 in my messages received via dovecot and I have some folders with national characters on my account, and it works both with IMAP and Sieve.
What next? Replacing Sieve with something cumbersome, but JSON based? There is no good desktop implementation of MUA with old technologies (IMAP, Sieve), will all this JMAP help? I don't think so. What is profit to have good server with new good (assume it is good, I'm not sure, but lets assume) protocols without good client? IMAP4 is underused by modern clients: it allows to effectively store client configuration on…
> What is profit to have good server with new good (assume it is good, I'm not sure, but lets assume) protocols without good client? You need both. You could say, what profit is a good client without a server? By that reasoning, we never stake a step forward without a complete solution. Now a better mail implementation is just a client away.
Maybe, Apple Mail is good, again, I don't know as I'm not using Apple, but I don't know any client for Windows and/or OSS with Windows support which has as basic features as support of per-folder settings (identity, sorting mode, etc.) stored on server or proper support for Sieve. In my eyes it is basic features.
And don't let me start to rant about message editor itself, especially in text-only (as opposite to HTML) mode with proper quoting & such.
I tried to set up stalwart, but I didn't understand exactly what it wanted me to do. It's a webserver (for webmail and admin) and mail server in one, but I already run a webserver and I already have cert infra. So I couldn't figure out what dns settings to use and what ports to reverse proxy. And how to get it to play nice and share the certificate. Seems like stalwart has been designed as if it is the only thing run…
1. curl this shell script
2. Run it as root.
Anytime you see that, you can assume the software wants to take over the whole box and isn't likely to make any attempt to play nicely with other services/software/users already running on the same host.
To their credit, they do have a docker image (https://stalw.art/docs/install/platform/docker).