- cross-posted to:
- hackernews@lemmy.smeargle.fans
- technews@radiation.party
- cross-posted to:
- hackernews@lemmy.smeargle.fans
- technews@radiation.party
Copied from r/selfhosted as seems interesting enough to share with wider audience.
I’m excited to announce the release of Stalwart Mail Server, a single binary solution that combines the Stalwart JMAP, Stalwart IMAP, and Stalwart SMTP servers into one easy-to-install package.
In response to user feedback, some key enhancements were made. Stalwart Mail Server now supports LDAP and SQL authentication, providing seamless integration with your existing infrastructure.
For single node setups, RocksDB has been replaced with SQLite with the option of using LiteStream for replication. For larger, distributed setups, support for FoundationDB was added, letting you scale to millions of users without sacrificing performance. Additionally, it is now also possible to store your emails in an S3-compatible storage solution such as MinIO, Amazon S3, or Google Cloud Storage.
Other notable updates include support for disk quota, subaddressing (or plus addressing) and catch-all addresses.
Check it out here: https://github.com/stalwartlabs/mail-server
I look forward to your feedback and questions!
I’ll say that I really like this idea. The challenge with self-hosting email will always be in the message deliverability to others because the big bois don’t play well with smaller mail servers and often route legitimate messages to spam. This is even despite implementing SPF, DKIM, and DMARC properly.
The single binary thing is a nice idea. I don’t see myself migrating off mailcow anytime soon though - I have no desire to set up mailservers more often than required.
Wow!
I was searching exactly for this! I wanted to run a mail server for fun between a few users (Delta chat) but I didn’t want to have a full VM dedicated to that, just a docker
There’s docker-mailserver which runs the entire stack in one container.
Pedantic side-note: you don’t run “a docker”. You run a container, and you happen to use docker to do so. Just like you don’t send someone an Outlook or Chrome their website. Docker is just a way of running OCI containers, not the whole tech.
I’ve been playing with DeltaChat a little bit. How do you like it? Have you found any problems with it? Curious about any experiences …
Didn’t really use it, as I think there’s too much overhead and if used as intended it counts as abuse on a free email account (too many messages sent/received in a burst) - that’s why I wanted to self host that mailboxes
written in rust
👀
What the hell is JMAP anyway? Never heard ofAnother new alternative to IMAP. Can be read here.Ok, so JMAP is an E-Mail API, replacing proprietary solutions like Gmail’s(?). But for what? What does it do/solve?
People’s apparent desire to put JSON into everything? ;)
Unfair. JMAP is a official IETF RFC, a working standard powering a very large mail email service, a modern, open move towards a sort of open ActiveSync.
Fastmail has done a lot of work on this, for free, and no one has a better suggestion, so it’s the state of the art.
Looking into it a bit more, it does seem like a considerable improvement over IMAP and *DAV (especially *DAV). Maybe I was too quick to write it off. Might test it out
IMAP is not proprietary. Gmail does support it though, as does pretty much every email provider under the sun. It has limitations though, and JMAP is one proposed alternative to solve some of those.
Note that I don’t have enough knowledge to emit an opinion on whether it’s good or not. I’m just pointing out a couple facts.
It solves a bunch of stuff caused by IMAP being a bit of a mess. Top of the list of JMAP benefits is:
[JMAP] is stateless. It doesn’t need a persistent connection, which is better for mobile use, which may have intermittent network access and where battery life must be conserved by turning the radio off whenever possible.
JMAP was developed by the guys that run FastMail (who are the primary developers of the open source email server Cyrus-IMAP). It’s easier to implement and more performant.
Side note, Cyrus is a pretty amazing mail server. It doesn’t get much love here, but it’s bombproof, fast, supports multi-node clusters, IMAP, NNTP, CalDAV, CardDAV and more that I’m forgetting. It’s just a bit old school as far as configuring goes.
A good read about self hosted email servers: https://news.ycombinator.com/item?id=32715437
If you are going to use it within your family members it will be fine, but not with other users who uses corporate provided email services.
I think there’s a lot of FUD around this. Yes, deliverability can be a PITA, but with a clean IP and good setup it’s usually solvable. Worst case, you can pay a small amount to use a 3rd party SMTP relay and still get most of the benefits of selfhosting. It wasn’t deliverability that made me stop selfhosting it was spam, and it wasn’t that dealing with spam was that hard, it was just annoying.
As an anecdote – I have been sitting on an elastic IP at AWS for years, with reverse DNS configured properly for it. Way early on (years ago), some spam filters would block the whole netblock, but I can’t remember the last time the IP Block was wholesale blocked. I think AWS is very much on top of any spam complaints from their Elastic IPs, and as long as you don’t abuse your specific IP, you are in good shape for light volume, non-spam mail.
I use Mail-in-a-Box (planning to move to ISPMail though) and i rarely have deliverability issues. My main issue is actually that the grey filter takes too long for my preferences! With self hosting mail, i consider that a good issue to have
This is unfortunately true. That much said, the tide may be slowly turning in our favor as more and more people discover non-corporate, free and open source social media. Some of my circle of tech friends have deleted all corporate social media and have stood up instances of Mastodon or Akkoma, Friendica, Pixelfed, and Lemmy or Kbin for family.
Eventually, people will be asking themselves why they bother using gmail.com, outlook.com, and yahho.com addresses when they can just do it themselves for friends and family. The internet was never meant to be controlled by a select few corporations. It was always intended to be decentralized to avoid a single point of failure so as to continue to mostly work in the case of war, catastrophe, or both.
I am placing
careful(nevermind that, this seems very nice) interest in this.Few questions (since I’m on mobile, and it’ll take me a while to get back to my computer to find out for myself):
- How does managing sieve work with this?
- Does it play along with rspamd?
- Is it tested on
x64_64
only? - Does it support PGP, can email be encrypted-at-rest using this?
- Is there a way to run this behind a reverse proxy that handles the certificates? I’m not too keen on dealing with two separate sets of those in separate places.
- Does this require LDAP?
If missing, are those on roadmap?
The author is actively answering questions on the Reddit thread, probably best to ask them.
It has sieve support and rspamd/spamd are supported via filters. It doesn’t require ldap. PGP doesn’t require any server support so that should work fine. I haven’t seen anything about supporting encryption at rest.
LMTP support would be nice too: existing mail routing infrastructure could send messages into stalwart-managed mailboxes. (Edit: reading the docs, they do support LMTP! This is awesome)
It sais in the readme that LDAP and SQL based auth is supported.
Interesting. I might try this out later.
a single binary solution
but that means that it’s not using any OS-level privilege separation?
A single binary can be invoked with different privilege levels. OpenSSH, for example is a single binary, but uses OS privilege separation when setting up connections from the root-owned daemon. (Just to be clear, I’m not sure that stalwart is using this technique, just that single binary apps do not exclude the possibility of OS privilege separation.)
Ahh yes, but https://stalw.art/docs/configuration/general/ seems to suggest that it’s both single binary and single process.