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.
dunno mail has kinda been off my list.
like taco bell… it always sounds good until youre just about finished and you realize what youve done to yourself
So it has got TLS. Nice.
But what about all the other security features that are required of a mail server today?
they are probably listed in a longer readme which is not shown at every new feature release. Or not, who knows. If we only had a place where to look…
I don’t even want the list. I’m just asking if it has them all — or less than all :-)
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.
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
Haven’t really used any proper JMAP clients - since the setup is broken anyway, so mainly just curl.
There’s not one built in but it’ll work with any that connects to IMAP or JMAP servers.
I honestly dont see how mail can be reliably self hosted, and be accepted by the majority of filters. Especially as we move farther and farther into the world of limited IPv4 availability.
All it takes is for your IP to be listed as spam, and a large number of companies out there are going to put you in junk, or worse drop you completely.
Add on top of that the issue of reliability, and I just can’t fathom hosting myself. It makes much more sense to me for email to be one of the only things you do third party.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters HTTP Hypertext Transfer Protocol, the Web IMAP Internet Message Access Protocol for email IP Internet Protocol SMTP Simple Mail Transfer Protocol SSL Secure Sockets Layer, for transparent encryption TLS Transport Layer Security, supersedes SSL nginx Popular HTTP server
5 acronyms in this thread; the most compressed thread commented on today has 6 acronyms.
[Thread #409 for this sub, first seen 8th Jan 2024, 04:55] [FAQ] [Full list] [Contact] [Source code]
nginx isn’t an acronym lol
