This project's scope is rather impressive, and from what I've gleaned from skimming its docs, it might be the perfect solution for people who want to self-host email.
It tries to have most of the advanced/difficult things (like getting DKIM set up right) taken care of for the postmaster, as far as that is possible within a single application. I love that it will print the DNS records you'll need to set up in your zone during setup.
If I were to start over my personal email setup (postfix with postscreen, dovecot with fts, opendkim, amavis/spamassassin), I sure would try it with this.
> If I were to start over my personal email setup (postfix with postscreen, dovecot with fts, opendkim, amavis/spamassassin), I sure would try it with this.
I am tempted to give that sort of thing a try, as successor to the franken-"postfix with postscreen, dovecot with fts, opendkim, amavis/spamassassin" contraption (actually Courier, not to mention LDAP, greylisting, a couple webmails, OCR, blacklists etc.) that we have been maintaining for two decades in service of friends & family.
But, for all its flaws, once put in production that setup on Debian packages Just Works - with upgrades and distribution version jumps handled almost flawlessly. I doubt that any of the new generation of integrated "mail things in a box" products that pop up since a couple of years have anywhere near that staying power. Does someone here know some that put long-term maintainability at the top of their priorities ? It seems to me that they all optimize for quick onboarding.
Yeah, that's my impression as well. I've been wondering about this sort of setup for a while – there's a lot of moving parts in traditional email servers, and projects like poste or univention/zimbra/… that just try to glue these massive stacks together have always been far too fragile and involved for any setup that's smaller than "we can afford a dedicated sysadmin for emailling".
The only feature I'd still want is Sieve, then it'd be good enough for not just home setups, but probably also SMBs.
Just throwing my 2c in the ring: I've been using iRedMail for I want to say 10+ years now. Just simple linux no-frills webmail with nice admin and default webmail. Best part is it is dead simple to set up, the developer is very nice and responsive on his forum and it has been rock-solid. Granted, I don't send a lot of mail from it but it has been running as a journal for many years without issue. I do send some mail from it--mostly from devices--to my gmail and have never had a problem with blacklisting. I think this mostly depends on your IP reputation so your host and how you host it is important.
The scope isn't revolutionary - I've used https://mailu.io/ for years for a few 10s of users, and I really like it. I've heard similar good stories from Mailcow users.
On a quick skim I couldn't tell what was new relative to these older compose-based solutions but (as co-author of similar solution 10-15 years ago) I'm interested to know!
I set up docker-mailserver[0] Monday in ~6 hours, most of which were me trying to be fancy using podman instead of docker and dealing with SELinux. But then again I did choose it over mail-in-a-box for just that level of customization. Obviously I can't tell how reliable it will be in the long run yet, but since it's using the classic Postfix/Dovecot stack I expect it'll be pretty stable
Email servers are notoriously difficult to configure, hence all these solutions ranging from tutorials to "everything included" systems. Recent activity on HN about mail servers: Mox, Poste.io from yesterday [1], Mailinabox, mailcow, ispmail, maddy, stalwart jmap, etc.
Many of these systems keep redoing the same work over and over which seems wasteful.
What I'd like is a "mail reverse proxy" that does all the work to manage DNS, SPF, DKIM, DMARC, etc and handles sending and receiving emails, but doesn't do any storage or user management. Instead it forwards mail from/to the "real" mailserver sitting somewhere in a private network. (Maybe using LMTP [2]?)
This way you could roll the dice until you get a $5 VPS with a clean static IP and just park it there permanently, where it does nothing but sends and receives emails from your real mail server wherever you want to host it. Kinda like a PO box. You never have to worry about upgrading it to get more storage, or switching providers and losing your IP, if it gets hacked the worst it can do is spy on live email traffic and send spam until its patched.
> Many of these systems keep redoing the same work over and over which seems wasteful.
There certainly is duplication of effort, but all these systems try to bring something new to the table.
> Why doesn't this exist already?
Because you haven't written it yet? (;
But seriously, I've had a somewhat similar thought. But instead of running a "reverse mail proxy" on a VPS, I was hoping to take a VPS, set up some tunnel magic (with wireguard probably) that forwards all traffic coming in from the internet, intact with original IPs, to my local side of the tunnel, and vice versa. So my local machine just has the same public internet IPs configured as the VPS and all internet traffic is going through the tunnel. So just use a VPS for its IPs. That way my data is not stored at my hosting party. If anyone has set this up already, or thinks this is a bad/good idea, I'd like to hear.
it's also wasteful in a different way: a lot of effort put towards building on top of a remarkably bad pseudonymous protocol based on anachronistic trust assumptions
from that point of view the refactoring to do is separating identification from transport and storage/lookup - for these things there are very good solutions but there is no cohesive protocol that is solid and widely adopted, and it's unclear if that will happen anytime soon, or ever - rather than just doing away with the mail metaphor in favour of the pager+answerphone metaphor which can be seen as a total overlap as you add features
but you're right that since email is here now and it "works" now, especially from a social perspective, then it makes sense to free up people from silos - what effectively webmail and proprietary messaging/social media are - and perhaps the best way is the toolkit approach you describe which would go about email a bit like git did with version control: establish protocols for the separate aspects of the system and then provide the user with a supervisor command tool, which can be automated to some particular use cases if need be but is flexible enough that it doesn't require one particular setup
> What I'd like is a "mail reverse proxy" that does all the work to manage DNS, SPF, DKIM, DMARC, etc and handles sending and receiving emails, but doesn't do any storage or user management.
spf, dkim and dmarc are all dns related. Running nameserver and mail servers on the same system doesn't sound like a good idea, nor does having a mailserver with write access to dns-records. using a central administration for both however sounds beneficial. but then why stop there and not add all kinds of other useful features and voila, you have a full blown control panel far away from being a simple solution for mail.
I think dns for mail needs to be complicated, otherwise people lightly just set their spf records incorrectly which gets their mailservers blacklisted. or they just will never know why their mails get blocked. if they even find out about that.
The project looks cool! However, I think the hard part of self-hosting email is not the tech stack, it's getting email delivered to your recipients using Google or Microsoft severe email servers. It's hard to rent a server that IP address is not in a block that big email providers consider suspicious already or will soon. And any mishaps can get you locked out and you need manual intervention to be allowed again.
I used to self-host years ago but I've abandoned the idea now.
> Also, webmail, calendaring are future features in this product. I wonder how critical are those for people setting up their own email.
I wonder the same. (:
I would personally use the calendaring.
One of the goals of mox is to make it easy to host mail yourself instead of go to/stay at one of the few large providers. I think folks commonly use the calendaring that comes with their free email address. And it seems many people enjoy their webmail over locally installed mail clients.
When I tried a similar project, every email I sent from a self-hosted email server were considered spam from Gmail.
In some cases, websites weren't even allowing email registration with a self-hosted email.
Is there any general advice about avoiding such problems?
I highly suggest that technical people like HN readers use the https://workaround.org/ispmail tutorials instead and set up postfix/dovecot from their OS repos. You'll learn enough on the way to fix things when they do go wrong rather than relying on some turnkey stuff who's internals are obscure and hard to fix when the inevitable problems happen.
Setting up a proper mailserver this way does take a few hours (from VPS setup to sending mail) but once it's set up it's good to go for a decade. And when the time comes to update the distro you're running it on you'll know how to port your data/config to the next VPS.
I don't agree with this take, talking as someone who has maintained their own email server in one form or another for many years. I think the separation of components in the traditional email stack is absolute bonkers and an artefact of various historical happenings, and not a technical necessity. That's why I love projects like Maddy or Mox who ship the whole stack in a single binary. Yes, you need to learn about DKIM, SPF and other high level email protocol concepts, but you shouldn't have to know how components interact between each other. So my recommendation to people is to go with projects like Maddy and Mox, and hopefully more people will host their own emails because of the lower entry barrier, so we can get some empathy from huge providers like Google and Microsoft.
It's certainly a good idea to understand how email works when you are running your own email server. I don't think setting up half a dozen services is the best way to get that knowledge though. Ideally, mox will explain some of it on its admin pages in the future. But I understand your point. Existing mail server components are long-lived, battle-tested, high-quality.
I wouldn't say internals of mox are obscure, it's all open source and relatively lean code (but clearly I'm biased). But indeed, if something goes wrong, you may not currently be able to google-search your way out of it. Mox is very young. The FAQ suggests first installing it a subdomain to gain experience, instead of switching your email over immediately.
FWIW, I implemented the mail export functionality before import functionality. You can easily get a tgz or zip with all maildirs or mbox files out of mox.
I’ve actually found that this is not the case and that while the learning is enjoyable, it’s very difficult to retain, especially if the result is a low maintenance server. A decade after I set it up, I will most certainly have forgotten how I set it up in the first place (speaking from experience).
The main benefit of this is (a) when using a distribution like Debian, you get automatic security updates, and (b) it is virtually guaranteed to be supported for decades, and there is extensive documentation. It’s also more flexible to customize, and it integrates with other packages and features of the distribution.
From my own experience maintaining a mail server for over a decade, I do not agree with this.
The time between any tweaks needed is large enough that I completely forget how it was set up and need to relearn stuff. And it's definitely not trivial, so I can't do that in 5minutes (the way I can with acme/letsencrypt, for example).
In the same way that caddy just makes web server setup easy, it's good to have a modern setup supported out of the box for mail as well.
If you are familiar with NixOS, and like to have everything declared in Nix configuration, Simple NixOS Mailserver is very robust and easy to use. Have been using it for ~2 years.
Can this scale to 10's of 1000's of users on a big server?
I wanted to open an alternative to gmail where users can use their domains and open several mailboxes for a small fee but when searching for solutions I always end up with dovcot scaling which is hard or expansive. What I am searching for is some solution where the mailbox can store large attachments on S3 / b2 and maybe also email content and just index the inbox on a local DB / Redis. Is there something like this available open source?
> Can this scale to 10's of 1000's of users on a big server?
No, probably not.
Indeed disk space may become an issue (though you can get large disks nowadays; also, if you want to be that big, modifying the code to storage the raw emails (or only the large ones) externally should be worth the time). And if you are that big, you probably want a backup mx, which pretty much requires replicating the index database to another place, which isn't supported yet.
But more importantly, mox doesn't have a spam filter or rate limiter for submitted (outbound) email. So it will currently take 1 compromised account to damage your IP's reputation. It's on my todo list.
I heard dovecot has an option to store messages to s3. It seems to be part of a paid variant.
Wow, impressive feature set! How long was the incubation time of this project? I see that the initial git commit already contains quite a lot :-)
I think this server hits a very interesting market segment of the users that want to self host a mail server but do not want to be locked in to the (some times opinionated and difficult to integrate with other infra) docker based turnkey options like mailcow or mailu.io. I certainly would take a look at it for my next iteration, even though I'm kinda very comfortable with my existing setup which is based on mailcow.
One key aspect with self hosting is how to keep the end system upgradeable. And this is where mailcow and mailu shine because internally evenrything has been worked out already. Still crossing fingers though, this looks promising!
> How long was the incubation time of this project? I see that the initial git commit already contains quite a lot :-)
I started prototyping about 1.5 years ago. Then work took over. But managed to work on this for the past ~6 months nearly full-time. I worked from git staging, keeping it all working with tests.
> One key aspect with self hosting is how to keep the end system upgradeable. And this is where mailcow and mailu shine because internally evenrything has been worked out already. Still crossing fingers though, this looks promising!
Mox is still very young. I think updates will probably require some admin intervention until the dust settles. But I typically build some support in my applications for automatically upgrading data to keep manual intervention to a minimum.
Second self-hosted mail server in 2 days. Are people really hosting their own mail servers? Why?
I did this for about 10 years and mostly it was uneventful and worked fine. HOWEVER, a little less than once a year it would break and I would suddenly not be receiving emails and would have to scramble to fix me mail server when literally anything else would be a better use of my time. It was a good learning experience, but kinda pointless tbh. There are so many free/cheap very reliable maintenance free (for me) options for email that I can't for one second understand why anyone would host their own (even as someone that did for years).
I'd love the ability to send mail through a public SMTP relay, such as Amazon SES or Sendgrid, so the server could be hosted on "untrusted" IP space and send outbound mail through a trusted relay.
Wouldn't it make more sense to just configure an AWS SES submission account as outgoing mail server, instead of trying to send it through a mail server like mox, only to have it forwarded again. I think you need to verify addresses with AWS SES anyway if you want to send from them (or perhaps it's only per domain?). Don't know if other mail service providers have a similar requirement.
Nice project. But I was always nervous about running my own mail server for reasons outside the server itself. I mean things like deliverability, security, uptime, patching.
How does it handle spam filtering? Surely the big mail providers have a network effect going on when one person marks an email as spam it's applied to similar emails.
But are there any good (modern) web clients (see Outlook Web)? E-Mail, in my experience as a light user, involves a lot of client side configuration (filters, sender names, ...) that I can't stand being tied to a single client device.
IO.OX (used at mailbox.org and strato, among others) is "alright", but I haven't seen much material about self hosting it.
I’ve set up and ran my zimbra server for a long time too. It was a pain to set up initially, but once it’s running, you rarely have to make changes. The only bugbear I have is to update the letsencrypt ssl cert for secure connection and https access. But a cronjob automates that for me.
I'm in two minds about this sort of things while it's nice that it makes it accessible, mail should be hard as it means that responsibility is taken - a bunch of mail servers run by people without any experience or knowledge is a bad thing for all of us
There's lots of hosting providers who will sell you a managed VPS that includes your own mail server among other things. That seems like a better solution to me, for someone who doesn't want to get into the guts of it.
[+] [-] c0l0|3 years ago|reply
It tries to have most of the advanced/difficult things (like getting DKIM set up right) taken care of for the postmaster, as far as that is possible within a single application. I love that it will print the DNS records you'll need to set up in your zone during setup.
If I were to start over my personal email setup (postfix with postscreen, dovecot with fts, opendkim, amavis/spamassassin), I sure would try it with this.
[+] [-] liotier|3 years ago|reply
I am tempted to give that sort of thing a try, as successor to the franken-"postfix with postscreen, dovecot with fts, opendkim, amavis/spamassassin" contraption (actually Courier, not to mention LDAP, greylisting, a couple webmails, OCR, blacklists etc.) that we have been maintaining for two decades in service of friends & family.
But, for all its flaws, once put in production that setup on Debian packages Just Works - with upgrades and distribution version jumps handled almost flawlessly. I doubt that any of the new generation of integrated "mail things in a box" products that pop up since a couple of years have anywhere near that staying power. Does someone here know some that put long-term maintainability at the top of their priorities ? It seems to me that they all optimize for quick onboarding.
[+] [-] creshal|3 years ago|reply
The only feature I'd still want is Sieve, then it'd be good enough for not just home setups, but probably also SMBs.
[+] [-] obituary_latte|3 years ago|reply
[+] [-] ilyt|3 years ago|reply
[+] [-] abdullahkhalids|3 years ago|reply
[+] [-] mattbee|3 years ago|reply
On a quick skim I couldn't tell what was new relative to these older compose-based solutions but (as co-author of similar solution 10-15 years ago) I'm interested to know!
[+] [-] ranger207|3 years ago|reply
[0] https://github.com/docker-mailserver/docker-mailserver
[+] [-] infogulch|3 years ago|reply
Many of these systems keep redoing the same work over and over which seems wasteful.
What I'd like is a "mail reverse proxy" that does all the work to manage DNS, SPF, DKIM, DMARC, etc and handles sending and receiving emails, but doesn't do any storage or user management. Instead it forwards mail from/to the "real" mailserver sitting somewhere in a private network. (Maybe using LMTP [2]?)
This way you could roll the dice until you get a $5 VPS with a clean static IP and just park it there permanently, where it does nothing but sends and receives emails from your real mail server wherever you want to host it. Kinda like a PO box. You never have to worry about upgrading it to get more storage, or switching providers and losing your IP, if it gets hacked the worst it can do is spy on live email traffic and send spam until its patched.
Why doesn't this exist already?
[1]: https://news.ycombinator.com/item?id=34901703
[2]: https://datatracker.ietf.org/doc/html/rfc2033
[+] [-] mjl-|3 years ago|reply
There certainly is duplication of effort, but all these systems try to bring something new to the table.
> Why doesn't this exist already?
Because you haven't written it yet? (;
But seriously, I've had a somewhat similar thought. But instead of running a "reverse mail proxy" on a VPS, I was hoping to take a VPS, set up some tunnel magic (with wireguard probably) that forwards all traffic coming in from the internet, intact with original IPs, to my local side of the tunnel, and vice versa. So my local machine just has the same public internet IPs configured as the VPS and all internet traffic is going through the tunnel. So just use a VPS for its IPs. That way my data is not stored at my hosting party. If anyone has set this up already, or thinks this is a bad/good idea, I'd like to hear.
[+] [-] muyuu|3 years ago|reply
from that point of view the refactoring to do is separating identification from transport and storage/lookup - for these things there are very good solutions but there is no cohesive protocol that is solid and widely adopted, and it's unclear if that will happen anytime soon, or ever - rather than just doing away with the mail metaphor in favour of the pager+answerphone metaphor which can be seen as a total overlap as you add features
but you're right that since email is here now and it "works" now, especially from a social perspective, then it makes sense to free up people from silos - what effectively webmail and proprietary messaging/social media are - and perhaps the best way is the toolkit approach you describe which would go about email a bit like git did with version control: establish protocols for the separate aspects of the system and then provide the user with a supervisor command tool, which can be automated to some particular use cases if need be but is flexible enough that it doesn't require one particular setup
[+] [-] taskforcegemini|3 years ago|reply
spf, dkim and dmarc are all dns related. Running nameserver and mail servers on the same system doesn't sound like a good idea, nor does having a mailserver with write access to dns-records. using a central administration for both however sounds beneficial. but then why stop there and not add all kinds of other useful features and voila, you have a full blown control panel far away from being a simple solution for mail.
I think dns for mail needs to be complicated, otherwise people lightly just set their spf records incorrectly which gets their mailservers blacklisted. or they just will never know why their mails get blocked. if they even find out about that.
[+] [-] snotrockets|3 years ago|reply
[+] [-] elric|3 years ago|reply
[+] [-] baudehlo|3 years ago|reply
[+] [-] p4bl0|3 years ago|reply
I used to self-host years ago but I've abandoned the idea now.
[+] [-] thunderbong|3 years ago|reply
Also, webmail, calendaring are future features in this product. I wonder how critical are those for people setting up their own email.
[0]: https://mailinabox.email
[+] [-] mjl-|3 years ago|reply
I wonder the same. (: I would personally use the calendaring.
One of the goals of mox is to make it easy to host mail yourself instead of go to/stay at one of the few large providers. I think folks commonly use the calendaring that comes with their free email address. And it seems many people enjoy their webmail over locally installed mail clients.
[+] [-] ajdude|3 years ago|reply
[+] [-] Lucasoato|3 years ago|reply
[+] [-] yamrzou|3 years ago|reply
[+] [-] superkuh|3 years ago|reply
Setting up a proper mailserver this way does take a few hours (from VPS setup to sending mail) but once it's set up it's good to go for a decade. And when the time comes to update the distro you're running it on you'll know how to port your data/config to the next VPS.
[+] [-] lifty|3 years ago|reply
[+] [-] mjl-|3 years ago|reply
I wouldn't say internals of mox are obscure, it's all open source and relatively lean code (but clearly I'm biased). But indeed, if something goes wrong, you may not currently be able to google-search your way out of it. Mox is very young. The FAQ suggests first installing it a subdomain to gain experience, instead of switching your email over immediately.
FWIW, I implemented the mail export functionality before import functionality. You can easily get a tgz or zip with all maildirs or mbox files out of mox.
[+] [-] aareet|3 years ago|reply
[+] [-] layer8|3 years ago|reply
[+] [-] senko|3 years ago|reply
The time between any tweaks needed is large enough that I completely forget how it was set up and need to relearn stuff. And it's definitely not trivial, so I can't do that in 5minutes (the way I can with acme/letsencrypt, for example).
In the same way that caddy just makes web server setup easy, it's good to have a modern setup supported out of the box for mail as well.
[+] [-] daitangio|3 years ago|reply
Easy to setup and mantain, no issue in the last 2 years (finger crossed)
[+] [-] giantg2|3 years ago|reply
[+] [-] quyse|3 years ago|reply
https://gitlab.com/simple-nixos-mailserver/nixos-mailserver
[+] [-] chalst|3 years ago|reply
[+] [-] oron|3 years ago|reply
[+] [-] mjl-|3 years ago|reply
No, probably not.
Indeed disk space may become an issue (though you can get large disks nowadays; also, if you want to be that big, modifying the code to storage the raw emails (or only the large ones) externally should be worth the time). And if you are that big, you probably want a backup mx, which pretty much requires replicating the index database to another place, which isn't supported yet.
But more importantly, mox doesn't have a spam filter or rate limiter for submitted (outbound) email. So it will currently take 1 compromised account to damage your IP's reputation. It's on my todo list.
I heard dovecot has an option to store messages to s3. It seems to be part of a paid variant.
[+] [-] theK|3 years ago|reply
I think this server hits a very interesting market segment of the users that want to self host a mail server but do not want to be locked in to the (some times opinionated and difficult to integrate with other infra) docker based turnkey options like mailcow or mailu.io. I certainly would take a look at it for my next iteration, even though I'm kinda very comfortable with my existing setup which is based on mailcow.
One key aspect with self hosting is how to keep the end system upgradeable. And this is where mailcow and mailu shine because internally evenrything has been worked out already. Still crossing fingers though, this looks promising!
[+] [-] mjl-|3 years ago|reply
I started prototyping about 1.5 years ago. Then work took over. But managed to work on this for the past ~6 months nearly full-time. I worked from git staging, keeping it all working with tests.
> One key aspect with self hosting is how to keep the end system upgradeable. And this is where mailcow and mailu shine because internally evenrything has been worked out already. Still crossing fingers though, this looks promising!
Mox is still very young. I think updates will probably require some admin intervention until the dust settles. But I typically build some support in my applications for automatically upgrading data to keep manual intervention to a minimum.
[+] [-] mjl-|3 years ago|reply
[+] [-] itslennysfault|3 years ago|reply
I did this for about 10 years and mostly it was uneventful and worked fine. HOWEVER, a little less than once a year it would break and I would suddenly not be receiving emails and would have to scramble to fix me mail server when literally anything else would be a better use of my time. It was a good learning experience, but kinda pointless tbh. There are so many free/cheap very reliable maintenance free (for me) options for email that I can't for one second understand why anyone would host their own (even as someone that did for years).
[+] [-] pas|3 years ago|reply
Nowadays I can wholeheartedly recommend Mailgun for outgoing mail. For personal/incoming ... well, Proton seems okay-ish.
[+] [-] igtztorrero|3 years ago|reply
Please use a VPS with your own IP clean checked.
Register on Microsoft Mail Program to pass Hotmail, Outlook and other MS domains.
SPF and DKim are mandatories !!!
Postal Server has a Good interface to configure and check SPF and DKim records.
[+] [-] dblitt|3 years ago|reply
[+] [-] mjl-|3 years ago|reply
[+] [-] TheMagicHorsey|3 years ago|reply
[+] [-] berjin|3 years ago|reply
[+] [-] solarkraft|3 years ago|reply
But are there any good (modern) web clients (see Outlook Web)? E-Mail, in my experience as a light user, involves a lot of client side configuration (filters, sender names, ...) that I can't stand being tied to a single client device.
IO.OX (used at mailbox.org and strato, among others) is "alright", but I haven't seen much material about self hosting it.
[+] [-] francois_h|3 years ago|reply
[+] [-] throwaway67743|3 years ago|reply
[+] [-] greenthrow|3 years ago|reply
[+] [-] scooke|3 years ago|reply