Hmm. A random thought: one of the blockers of migrating my email into my homelab is webmail, something my Mom currently depends on.

There ain't a lot of decent webmail clients. I tried setting up roundcube, but ran into all kind of stupid issues I don't really want to debug.

So I was thinking: what if I set her up with notmuch, and notmore as her local webmail? She only uses webmail from her miniPC anyway - she has K9/Thunderbird on Android. Or I could just... see if she's fine with Thunderbird, or Geary, or something other than webmail?

@algernon @stalwartlabs is working on a webmail for their 1.0 release (I'd advise waiting for the 1.0 release before trying it)

@petko Does it / will it work with servers other than @stalwartlabs's own? Because I have no plans to run stalwart at this time.

I should maybe explore Stalwart too at some point. I don't remember why I abandoned my last  experiment, forgot to document that properly.

I probably made a small tootstorm, though. Wonder if I can find it?

Hmm. But the current script doesn't seem that bad, and other issues I've heard about Stalwart seem to have been resolved.

Maybe I should give it a try. I do have an experiments domain, afterall. I can use that for this purpose.

Stalwart also has a "No AI-Generated Code" contributing policy. That's a great boon, because Dovecot and rspamd have slop, and postfix has no such policy.

So... looks like there's another Stalwart experiment in my future!

Though, unlike last time, I will likely not try to do declarative users. That was a painful part in my first Stalwart experiment.

The original idea was that a declarative configuration alone would set up a usable system. Since then, I relaxed that: declarative config + restored backup would.

There are some things that aren't worth doing declaratively.

Aight, that's enough of a side quest! I'll add it to my TODO list.

Now, there are downsides to Stalwart: it does not allow drive-by contributions, and contributors need to sign a Fiduciary Contributor License Agreement. So I can't really patch it, not even if I'd wanted to: I will not be signing the FLA, nor will I go out of my way to become a "vouced contributor", so any change I make, would be local.

But it's also AGPL, so I'd have to publish those changes. Which is fine-ish, but... I don't like publishing changes that I do not want to see merged, or derived from.

But then, the chances of wanting to patch Stalwart is pretty darn low, so this is something I can probably live with.

With that said... that "have to publish" part is something I'm not 100% sure of. Who would be entitled to ask for the patches? My local users only, or anyone who interacts with my mail server in any way?

If my local users only, then this is fine, and I don't need to publish my patches, if any, because my local users are me and my family.

(Though, the patches will be public anyway, since they'll be part of either my infra repo, or a stalwart repo fork - but being public and publishing are two different things in my book.)

@algernon for webmail I had looked into alps at some point, that seemed quite decent.
I havent touched it in a few years though

@4censord Looks interesting, thanks! Bookmarked it.

Though, their AI policy does not spark joy. Could be worse, but could be a lot better too.

@algernon a couple of notes from a person that has had their primary mail address on a self-hosted stalwart:

1. Their kv store is undebuggable from my PoV. Make sure to have regular backups of *exports* of it just in case something goes wrong.

2. The same goes for their blob storage.

3. Upgrades are hit and mostly miss. The suggested approach is to export all data from the old version (both kv and blob), create a new empty instance, and then import. That's why I suggest waiting for 1.0.

@petko Bummer. That's not very encouraging. Does that all still apply if I configure the data store to be backed by Postgres and blob as S3 (Garage)?

@algernon

I don't understand why people are so hellbent on using arbitrary homebrew kv stores in place of tried and tested sql... Both Stalwart and Kanidm...

@algernon if you configure the data store to be backed by postgres you only tell stalwart to use postgres to store its kv store in instead of whatever the popular Rust homebrew db was... rocksdb? The issue is with the structure of the kv store itself -- it is *not* human readable (the keys are numeric), it is not documented apart from digging in the source code. It uses absolutely nothing of the toolset of PG apart from a table with two columns. And it needs to be migrated upon upgrade.

@petko Ow. Okay. That's not something I want to deploy into prod.

I guess we'll see what happens faster: Stalwart 1.0, or me decomissioning my old mail server.

...and the Stalwart experiment is postponed until it hits 1.0 (see other replies upthread).

But I decided against using NixOS-Mailserver too, because it doesn't give me enough control.

So the current plan is to use Exim + Dovecot + rspamd, while waiting for Stalwart 1.0. Is there an IMAP server other than Dovecot that's reliable, and is slop-free (preferably with an anti-LLM policy)?

Cyrus is also contaminated, Courier looks okay.

@algernon strange… Because their website looks very vibe-coded and has a CLAUDE.md: https://github.com/stalwartlabs/website

@LilaHexe Yeah, the anti-LLM policy is for "code contributions". I suppose slop is still fine elsewhere.

(Which is silly, yes, but... my alternative is Dovecot that's allowing slop in code too.)

@algernon stalwart violates the AGPL. I do not recommend it

@noisytoot Oh. I was wondering about the web admin frontend stuff I've seen in Codeberg's script. Now I understand how that works, and eww.

Thanks for highlighting this (and other red flags mentioned on your link)!

aaand it looks like there will not be a Stalwart experiment, because of a number of reasons:

• Their KV store is undebuggable, and unstable, migrations are hit and miss.
• While the code repo has an anti-LLM policy, their website doesn't. So there's a threat of LLM creeping into code too, sooner or later.
• It is essentially a company-backed project, and I'm not a big fan of those.

In short: too many red flags, to few advantages over my existing stack.

A shame, because the self-hosted email stack is not in a great place at the moment.

(Edit: Removed a few assertions, because they turned out to be incorrect and/or outdated)

Just before you think it, @algernon, no, you're not going to write your own email stack. Forget it. I will not assist, and you can't do shit without me.

@doctor I know! sigh

I wasn't gonna think it.

@algernon Regarding rugpull relicensing, this is incorrect, Stalwart's core has been AGPL-3.0 since day one, that hasn't changed. What we actually did was move features that were previously paid-only into the open source version. So the relicensing went in the community's favor, not away from it.

Also, there are no proprietary parts in the stack, the server itself is AGPL-3.0 and the supporting Stalwart libraries are MIT/Apache.

@stalwartlabs ACK, updated my toot, thanks for clarifying.

@algernon Regarding the KV store, Stalwart is built as a distributed server, so it's designed around scalable backends like FoundationDB rather than something like Maildir, which doesn't scale to that model. That does mean data is stored in a binary, serialized form rather than plain text files you can grep.

@stalwartlabs I have no problem with storing data in binary formats, that's not a problem. The problem is upgrading from one version to another (which, according to a Stalwart user in this very thread, can be very hit and miss).

If upgrading from version A to B is painless, if there are tools to debug and fix issues (bugs happen), then binary formats are fine. Often better than text formats too, because it's easier to detect & address corrupted data.

According to these docs, there is no automated upgrade tool yet, that's scheduled for 1.0.0. I've been seen putting highly experimental things into production, but my email is one of the things where I do not wish to do that.

So best case scenario: I wait until 1.0.0, or likely 1.1.0 to see how well the automated upgrade tool works, before I'm comfortable switching.

@algernon Regarding being company-backed, this is also true of most of the self-hosted email stack you'd otherwise pick, Cyrus is Fastmail, Dovecot is Open-Xchange. Dovecot actually did a rugpull in v2.4 they removed clustering support from the open source version, pushing it behind a paid tier. Stalwart is company-backed too, and we do sell licenses, but that funds continued development of the open source features without taking on VC money, and the core has never had features pulled out of it.

@stalwartlabs I'm aware that my alternatives aren't much better in this regard, and especially Dovecot is a pain point. But those are the stack I already use. If I migrate, I need clear advantages, more of them than downsides.

With my current stack, I have the advantage of replacing parts of it, if need be (for example, I'm likely going to replace Postfix with Exim, because Exim has a strong anti-LLM policy). That would be harder if I was on an all-in-one stack (which does have its own advantages, mind you).

@algernon

Have you had a look at snappymail ? It is a fork of rainloop, and Migadu is using one of the two. It's doing everything I need when I need it at least.

notmuch is amazing (I used to contribute to sup, its ancestor) but the issue has always been the syncing back of flags and message moves. notmuch isn't really designed to "export" whatever happens, of course there are scripts to do it but now you have to integrate them in the workflow...

After playing around I still think thunderbird is good enough for classical use, I use deltachat though now because it kinda fits better in how I actually use emails

@rakoo Oh. I've seen snappymail before, but fell off my radar. Thanks for reminding me, will give it a try!

On the webmail front: Mom's using K9/Thunderbird on Android 99% of the time. She's open to using Thunderbird on her desktop for the remaining 1%.

Wife's using K9 too, kids won't be using webmail either, I don't use it - so I can get rid of it. That's one component less I need to care about.

Yay!

@algernon in my experience @stalwartlabs has not been putting effort into QAing upgrades, which has lead to me having a broken (partly functioning) server upon upgrade that didn't follow an export - import operation, but a migration instead.

I've been excusing this with the fact that it has not hit a 1.0 version and is considered beta/alpha.

@algernon the situation with the blob store is the following -- it is your run of the mill tree structure, but the directory and file names are tied to values in the kv store. Thus if your kv store gets broken your blob store is useless and will need to be reindexed (i.e. extract the eml blobs and import them into accounts manually).

@algernon

> I've been excusing this

I am a paying customer, I'm not entitled, I promise!

@algernon I expect it will be part of @stalwartlabs's package, so no.

@algernon Yes, you should wait until 1.0 which should be released around October. The product itself is stable but is moving fast (adding new protocols, or performance enhancements that change the serialization format on disk) and migrations between versions are a known pain point.