Comment on Stalwart v0.5.2
ikidd@lemmy.world 8 months agoI wouldn’t; it’s a monolithic container and I wouldn’t be comfortable putting an edge device up like that, with no separation of the backend from the front-facing services.
You could also just run IMAP/JMAP/SMTP as separate components, I can’t see any place in the Stalwart documentation - or in the Docker image itself - where monolith is the only option.
I haven’t tested the setup myself yet, but me and another root are planning on testing a setup of Stalwart to replace a semi-broken IMAP/JMAP setup for a computer club, keeping the SMTP as is.
Out of curiosity, what JMAP client have you been using? There doesn’t seem to be a lot yet and I’ve heard mixed reports about it with larger volumes, not that I’m working at scale anymore
ninjan@lemmy.mildgrim.com 8 months ago
Another user pointed out that there is no webmail built in so all that is contained is stuff that would need to be on the edge, i.e. SMTP and I/JMAP. Those services need direct port communication to the internet. As for the true backend stuff it’s not part of the setup since you need to provide your own storage backend and authentication backend. So I don’t understand your concern, could you elaborate what they do wrong in your mind?
ikidd@lemmy.world 8 months ago
Your SMTP should relay to the IMAP server but not be part of the same system so only new mail in and out is compromised, not the old. Or the spam filter. Or the other relays.
The webmail is the least of it, but even that should be separated from the services since that can compromise the users browser.
Do one thing, and do it well. Then put them together, securely.
ninjan@lemmy.mildgrim.com 8 months ago
Ok, I can understand your concern now but I feel like you’re basically saying that mail and self-hosting in general shouldn’t be streamlined at all and be super complex. Because your recommendation puts a lot of the security burden on the end user building their setup of various best-of-breed solutions. You would then yourself have to ensure all inter solution communication is secure as well as deploy every solution securely. Whereas with a all-in-one it’s generally on the Developers and the larger FOSS community to ensure the package is secure internally and the end user is only responsible for the deployment (i.e. that they follow the instructions and have reasonable security on the server they deploy to). Theoretically if an end user is very bad at security then your recommendation doesn’t end up with a more secure solution over all, it would be just as easy to compromise as the all in one, if not easier.
ikidd@lemmy.world 8 months ago
Not even saying that. Mailcow-dockerized is as simple to set up but separates the functions by container, and lets you specify secrets for database access, etc outside the docker compose. Unfortunately, the other easy-to-set-up one, docker-mailserver is a monolithic container as well.
I would also point out that people that don’t understand server security practices should probably stay way the hell away from self-hosting mail. When I did this professionally, I would compartmentalize the mail infra physically, then eventually by individual VMs. I now use unprivileged docker on it’s own docker host separate from the rest of my infra, in fact on another virtualized DMZ, because mail is the #2 point of contact for penetration.