Show HN: Mox - Modern full-featured low-maintenance self-hosted mail server

> 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.

Only thing I see that would really be missing is Sieve, it's soo much nicer to have server side filtering/categorizing

I have used https://mailinabox.email/ for about 1.5 years. Installation was dead simple, and no technical problems after.

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

[0] https://github.com/docker-mailserver/docker-mailserver

> 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.

For small loads (<100k emails/month) and a $5/month budget, you can get this with AWS SES and a few lines of code on Lambda.

The idea certainly has merit, but if it doesn't do storage or user management, how can you secure it?

You just described Haraka.

I've not really had those issues. A temporary block a few times, but that gets resolved.

FWIW, with mox, I prefer not to rely on blocklists (centralized!). Incoming mail is first checked with reputation of the sender. This reputation is only per account. So one accounts junk-classification doesn't affect another accounts. Only for new senders, and without conclusive signals, would a DNSBL be used. The result is that you can keep communicating with folks you've been communicating with for years, even if their IP is on a blocklist.

I wonder if the large providers are doing something like this as well. I suspect many mail servers use a DNSBL early in an SMTP session.

Ditto. Although I keep thinking about going back to it.

99.9% of the time self hosting is fine. But then a critical business email is never received (like replying to an interview request or business proposal). The worst part is you never even know it failed to be received. The worst offenders are outlook.com and yahoo.com in my experience of self-hosting email for about 10 years. I stopped around 4 years ago after a critical email disappeared and impacted me financially.

Only way to guarantee your emails are always sent and received is to use a major email provider, sadly. Or hire a team to actively look after your domain and make sure large providers are not filtering your emails.

However, given my emails now are pretty much just for personal usage, I may look at moving back to self hosted. Greylisting is the superior approach to spam control imo and you can only get this with self hosted. Mox looks really great and I'll def consider it.

It's funny how difficult it is to get email into Google or Microsoft, when, as an email admin, I want to block @gmail.com and @outlook.com because 90% of email from those domains is spam.

Without a tech stack it is impossible to self-host email, so, it is the hard part. Just this week I had huge problems with an expected email not reaching either of my gmail or outlook inboxes. It just never came, despite the sender insisting they sent it. This isn't an isolated case.

With MXRoute and my own self-hosted email, I'm slowly moving away from the big ones.

>it's getting email delivered to your recipients using Google or Microsoft severe email servers.

That's why one ought to do ip warming on the ip and contact different big email provider to get the ip white listed. It is not impossible. Maybe ought to be a service to do all that bureaucratic stuff.

If you’re not sending a very large amount of mail you can just get an AWS account and send through them for almost no money.

> 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.

Also if you visit box.yourserver.tld/cloud do you have a fully working Nextcloud instance.

Email reputation is a complex topic, but generally as long as you

• don't use an IP range classified as "consumer" (known dynamic IP DSL/cable ranges)

• set up SPF

• set up DKIM

• don't send actual spam

…it generally gets through. Mox is so far the easiest solution for SPF/DKIM I've seen, but if you don't mind spending a weekend tinkering, it should be solveable with any email stack.

> In some cases, websites weren't even allowing email registration with a self-hosted email.

I never ran into that issue. Not much you can do there, other than writing the owner angry emails via gmail.

The largest issue is often where you are hosting it – the address/range might not be well trusted due to either how it is categorised (if it is address known to be assigned to residential accounts then all mail may be dismissed as junk from a compromised host without any inspection) or who has used it before you (if using an inexpensive VPS (or dedicated server) provider the addresses you have may have been used by a spammer in the past). I've had very few problems with my home server sending mail, but I'm with an ISP more known for commercial users (so they take keeping their ranges clean seriously, and they aren't listed in IP databases as residential), I've had these addresses for over a decade (back when you could get a /29 fairly easily if not using a cheap ISP) so no one has sent junk from them (actually a friend was infected by something that sent web junk out, but that goes over the primary address not the range the mail service is on), and so forth.

The easiest way to solve this if you aren't as lucky as I am, is unfortunately not a free solution: send via a 3rd party relay such as companies like mxroute offer – you still control your entire mail server, your store all the mail, etc, but someone else deals with final delivery of outgoing mail (a good provider will multiple outgoing feeds themselves and deal with resending in response to some types of rejection, as well as making sure all their outgoing routes are reputation clean). For small volumes this is actually quite cheap, potentially far less expensive than your admin time dealing with delivery failures yourself.

Other common issues are not having SPF records set properly, or not implementing DKIM signing. Both of these are now essential and have been for some time, whether you send directly or via a 3rd party MTA, so if you didn't verify those that could be your issue.

Also, some mail receivers don't trust brand-new domains (the newest domain my main mail server regularly sends for was registered in 2010) so if you tested the mail server with a throwaway domain that could be a significant part of the problem. If you want to use a throwaway domain for testing, at very least wait until after the 5-day “domain tasting” grace period. Also pick a throwaway domain name that is relatively long and otherwise unlikely to have been used before (and unlikely to have ever been used as a from address in junk messages).

Get a machine/VM at a hosting provider that takes their network seriously. Typically not the cheapest you can find.

And make sure all the DNS config is set correctly. Mox helps you with that.

I've done a few mox quickstarts at fresh VM's, and mail was accepted by gmail just fine.

You need to get a proper self owned ip range with your own WHOIS info for your mail server.

On google I found that one can get a IPv4 /30 subnet for about 11 USD a year.

We have largely the same goals, see the first issue on the tracker with the same question. (:

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.

I found very useful this mailserver for docker https://gioorgi.com/2020/mail-server-on-docker/

Easy to setup and mantain, no issue in the last 2 years (finger crossed)

If there's a decade where I'm not touching it, there's no way I will remember how to do that.

Checking the Gitlab summary, this is a wrapper around Postfix+Dovecot, with support for DKIM/SPF/DMarc authentication and rspamd spam filtering.

> 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.

> 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.

For me it's path-dependence ... we're already hosting a few sites, used to host stuff for a foundation, plus their site sent a lot of newsletters.

Nowadays I can wholeheartedly recommend Mailgun for outgoing mail. For personal/incoming ... well, Proton seems okay-ish.

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.

All per account. If account 1 marks a message (sender) as spam, account 2 is not affected. I am blocking at least one otherwise legitimate company that is incapable of unsubscribing me from the marketing mails (despite talking to their helpdesk). I block them now. But other accounts may want to still see their emails.

If you want to learn who the real bad spammers are, I think you need larger volumes of mail than a self-hoster will gather.

The network effect that mox can use is through a RBL/DNSBL, but then an external DNSBL is doing the learning/analysis and mox just uses it.

> 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.

I use thunderbird and iOS mail. With thunderbird, configuring an account is trivial with mox using autoconfig. Needs just an email address and password, the config is found automatically. I haven't gotten auto configuration to work with iOS/macOS mail or Outlook (with thunderbird-style autoconfig, microsoft-style autodiscover, or SRV-record style). Don't know what I'm doing wrong. I've seen apple products make requests to apple servers when trying to autoconfigure an account, but no requests from apple to me. I presume you they have some kind of allowlist. From Outlook I get some connection attempts from Microsoft, but they can't seem to set up a TLS connection (connection setup fails during negotiating; I've also seen them send invalid SNI names (trailing dots)). This shouldn't be hard... If anyone knows how to autoconfigure accounts with the mail clients that most of the world uses, let me know. (:

I'm wondering what kind of filters and settings you would configure on the client side. I would think you would do most on the server side. That doesn't mean it has to be integrated into a web client. Mox has an account web page where you can configure mailbox routing.

Once more urgent features/omissions are taken care of, I want to add a web mail client to mox (optional of course). A basic one should be doable.

I self-host a "traditional" mail stack using LXD containers. Webmail is Roundcube in one container, mail spool is Dovecot in another container (and the spool is actually independent of the container, and mounted inside), mail exchange is Postfix in a third container doing LMTP to the Dovecot container (and also has an independent mount for the temp spooling of email).

The Dovecot instance has Sieve available to it, and Roundcube has the sieve plugin installed and able to write server-side rules for filtering. Address book is stored in a DB, and exposed via nextcloud's carddav. Works in KMail, iOS mail, Thunderbird.

I dunno if you can consider Roundcube to be modern, but all I want from a mail client is the ability to read and compose email, so it works for my needs.

Open-Xchange documentation is sometimes little bit fragmented, but Installation guides are available, example for Debian 11: https://oxpedia.org/wiki/index.php?title=AppSuite:Open-Xchan...

Now, those mailbox.org and others use (probably) commercial version. which comes with additional functionality (like document converters for preview) and providers make their own customizations top of that anyway.

If it's managed, isn't it their mail server? I mean, I can use my own domain and such, but as posters above said, "data independence" is important.

Mailu, like poste, zimbra, univention, and a dozen other projects like it, suffers from being just a layer of glue scripts and leaky abstractions on top of very complicated dedicated software stacks – dovecot, postfix, rspamd, etc. are all complex beasts on their own, and have 30 years worth of accumulated configuration knobs to fiddle with.

Postfix and dovecot in particular are also service orchestration frameworks of their own and don't reaaaally mesh well with docker, nor do the authors care about "this silly new fad". Don't dare asking about help with it on the postfix mailing list e.g., Wietse will rip your head off and beat you with it.

So, no, after messing around with these sorts of stacks for over a decade now, I can't in good faith recommend it to anyone. Sooner or later the leaky abstractions flood your basement and you have to clean up the mess on your own.

Mox's approach of cutting out 95% of the complexity by rolling their own good enough solutions into one monolith is far saner for small setups.

> Would this mean integrated WKD (Web Key Directory) support for PGP?

Didn't know of that, thanks. I think this could be used to encrypt submitted messages before trying to deliver them?

What I had in mind when I wrote that line, was server-side signing. But I don't think it's such a great idea to have private keys on a server. It would be convenient for use with email clients that don't support signing themselves. But I don't use PGP or S/MIME myself at the moment. So my messages get stored in plaintext, are typically transferred over TLS (might want to start enforcing that!). With SPF/DKIM/DMARC and with SMTP (submission) authentication, sender addresses aren't typically forgable anymore, so signing is perhaps less important than it once was.

Thanks, added the prefix.

No. I'm not sure, but it feels not feasible to implement that inside mox, so would have to be checked with an external tool. ClamAV springs to mind, but I haven't looked into that topic. If anyone knows what the options are, and how one would integrate, I'm intrested in hearing about it.

In the past decade, I think I've received maybe a handful emails with dodgy attachments. Obiously malicious. It never occurred to me I should implement support in mox. Probably different for settings with non-technical users.

I wrote earlier that I don't have any issues self-hosting my own mail server. But this is most likely an exception that.

If your plan is to send out newsletters and other marketing content, you are really better off going through a company that specializes in that. Self-hosting email is really only practical for individuals hosting their own personal/family mail, or for small companies who have the resources to hire someone to manage the mail system for their own domain.

The TL;DR here is, if you _look_ like a spammer (lots of identical/similar messages from one domain to lots of recipients), other mail systems will probably treat you like a spammer.