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.
• They did a rugpull relicensing a while ago, so whether they can distribute Stalwart is questionable.
• Essential parts of the stack are proprietary.
• 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.

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.