We are thrilled to announce the release of Stalwart Mail Server 0.5.2, which brings two significant advancements: the integration of the ACME protocol for automatic TLS certificate deployment and support for the HAProxy Protocol. These features mark a substantial step forward in our commitment to enhancing the security and efficiency of Stalwart Mail Server.
Cool, I’d be compelled to try but I think I’d need a guide on how to replace my current mail server with this one with as little fuzz as possible. Since I already have DKIM, DMARC, SPF, DANE and MTA-STS setup I’d need some help in sorting out what steps I have to take to make sure the switch is seemless to any sender.
Further I can’t really seem to get a good grasp on if there’s a webmail client or not?
I 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.
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?
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. And vice versa, if the users browser is owned and can infect the webserver, then the infection spreads all the way across the mail server, not just isolated to the nginx server.
Do one thing, and do it well. Then put them together, securely.
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.
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.
There’s not one built in but it’ll work with any that connects to IMAP or JMAP servers.