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.
Same. There is a large vocal contingent who confidently declare in any online space that hosting your own email is impossible these days. And yet, those of us who have been for years are managing it just fine.
Yes, it takes some understanding of how things work. Mine has been chugging along for longer than I can actually remember with very little maintenance needed, aside from regular package upgrades. The only time I ever had an issue with mail providers rejecting mail from my domain was when my wife started sending out school newsletters containing links to a shady URL shortener, but that was fixed pretty easily.
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.
It doesn't look like it supports mailbox sharing or public folders, which are very helpful for collaborating in a SMB, especially with shared email addresses (e.g., sales@business.com).
Do you know how this is typically used/configured? Do accounts get this shared account (mailbox(es)/folders with messages) as folders in their own account? So next to your own Inbox and Trash, you would have Sales/Inbox and Sales/Trash? If you delete a message from Sales/Inbox, does it automatically go to Sales/Trash? How is that done? Perhaps IMAP namespaces?
I have figured folks can just add another account (IMAP connection) to their mail client. Either a shared account (e.g. sales@), or account of a colleague. And then the account (mailbox) is shared.
Perhaps it's because webmails are just for a single account and folks would have to have multiple mail browser windows open? Or business folks are just not used to this approach? Or perhaps they want an admin to inject some shared mailbox into an existing account without requiring any user action?
Public folders sound a bit like a mailing list, from what I just skimmed from Exchange documentation. I presume the message flags (Seen/Read) are per-user? So it's more like delivery to each members copy of the public folder, instead of an actual shared folder?
I use dovecot and there is a lot of configurability for shared and public folders.
Public folders are much nicer than having to add separate IMAP accounts; users can subscribe to whatever public folders they want/need from a list. All subscribed folders show up underneath the root namespace folder. I have about 6 types of inboxes based on business roles (sales, pr, hr, it, etc). I have many more folders, beyond general inboxes, that get filled based on sieve filter rules. For example, voicemail alerts get filtered into a special voicemail folder.
Dovecot lets you configure whether the read state is shared or per user.
We use a system where people can flag messages as to whether they are taken for action, are critical, or are completed. These show up in Thunderbird/Roundcube mailbox list as color coded, and this aids in people knowing if emails have been dealt with.
You still have strict control for access/permissions on a per-mailbox basis, with ACL.
All of this could have been done with shared folders under a "shared" user account (either one or multiple shared account, such as sales, hr, etc) with similar results.
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.
Sieve is becoming a commonly requested feature. (;
For now, mox supports delivering to mailboxes with configurable rules, search for "Rulesets:" on https://pkg.go.dev/github.com/mjl-/mox/config. You can edit the config file (if you're the admin), or use the account web interface to add/remove/edit rules. I use it to get mail from mailing lists to the right mailbox.
That is most often caused by reputation issues around the IP where your mail server lives. If you host it at home or in any “residential” block of addresses, then most definitely. Same if hosted on a VPS or with a provider whose address space may have been burned by spammers spinning up machines and then redeploying them when they start getting blocked. As someone said further down below, you can still host at home and use Amazon SES as your verified outbound relay. I do that with the Axigen free email server, and I have no issues with reputation.
1. I was very careful to make sure that the IP address I was assigned was not on any blacklists.
2. I don't know if it actually helped. But after setting it up, I got a whole bunch of family/friends to email me from their gmail/hotmail/o365 addresses first, and then I replied to them. The theory was that gmail/hotmail wouldn't mark me as spam if their own addresses were initiating the conversation. Seemed to have worked well.
I have had only one case of my email getting completely blackholed (not put in spam, just rejected outright) is when I emailed a friend with a @amd.com address. Right now, I am still using gmail for essential professional emails, but slowly getting all my online-services converted to the new email address.
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!
What's revolutionary is that mox implements the entire stack itself as tightly coupled monolith.
With mailu and everything else you get a gargantuan stack of half a dozen massive, enterprise scale servers that are held together with duct tape and prayers. They can scale out to hundreds of thousands of users, but if anything breaks they expect there to be dedicated sysadmin staff to fix it, and gluing leaky abstractions on top doesn't really solve these fundamental architectural challenges.
I suppose it's mostly from a technical perspective: Single code-base, single binary, written in modern language (Go).
There are advantages to an integrated solution: The junk/nonjunk flags you set in your mail client are used to assess incoming email (based on full sender/domain/orgdomain/spf/dkim/ip/ipsubnets). I'm not sure how common/feasible that is with solutions that combine mail server components. I've used postfix & dovecot before mox, I admittedly didn't closely look into it but assumed that combo cannot do that.
With component-based solutions like Mailu, the junk/non-junk categorization you do in your mail client (via folders, not flags) indeed does inform the training of the spam filter used on incoming mail.
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.
Wireguard itself can help you out with the task of forwarding traffic or creating an overlay network. There's also ngrok and tailscale for forwarding traffic and doing NAT traversal. Except for wireguard, these are commercial platforms, the open source alternatives I know of, are (respectively):
I don't think there's anyone using this kind of tools for emails, the technical limitations elude my understanding TBH. This comment might be border to off-topic, but I think the tools fill in the niche use-case you just mentioned. Have fun!
> all these systems try to bring something new to the table
That's great, I just wish that they all didn't have to hurdle the same (very high) bar before they can get to the "something new" part.
> some tunnel magic that forwards all traffic coming in from the internet ... to my local side of the tunnel, and vice versa
Yes! I considered that too. It'd kinda be like tailscale funnel, which mostly targets web hosting scenarios. Hilariously, they poked fun at the $5/mo vps idea in their article about funnel back in November [1]:
> Yes, you could spin up a $5/month VM somewhere and forward a port from its public internet IP to your tailnet with one line in your rinetd.conf file. But is that fun? Do you really need a(nother) Linux VM in your life?
(we're definitely being called out here lol)
Sadly, funnel wouldn't work in our case because we need an unshared static IP. But that hint about rinetd could help, from the man page [2]:
> it is able to redirect a large number of connections without a severe impact on the machine. This makes it practical to run services on machines inside an IP masquerading firewall.
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
The way I look at it is that we're gonna have email for a long time, realistically at least another 50 years, probably 100. So if we're stuck with it, we might as well make it as painless as possible.
I totally agree that we should look for better protocols, for example Matrix looks like it could eventually be a good replacement for email. But whatever email is replaced with will definitely need some kind of way to interface with email during the transition, and a pre-built mail reverse proxy / IP gateway will only help with that.
> 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.
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.
Big providers, especially Microsoft, have become extremely heavy handed the last year or so. Now, if a single IP address in a /24 is sending spam, Microsoft will just block the entire /24. And we've had so much difficulty getting Microsoft to walk back that block and not reinstate it later on that we've completely given up providing any type of email service (whether that be day-to-day email needs or transactional emails). I've spent hours on calls with Microsoft support trying to remedy this and it's just impossible once it happens (and I've had it happen multiple times to multiple IPs and had multiple MS techs confirm this is what is happening)
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.
I had a family member work at a company that blocked gmail. They were a lotus notes shop tied with MS AD, and their admin was very anti-google. "Gmail is a cesspit of spam" or something like that. But... then was all in on MS. "MS is great - they have no spam problems". Which is just... wrong.
So... I couldn't email my family member at their work from my gmail. Not a big deal for me, but I know it impacted their ability to work with some clients and providers. And then... sure enough, they were getting spam from MS-hosted stuff (outlook.com, azure hosted stuff, etc).
He might have thought he was getting one over on google or something like that - I'm sure they didn't give a toss about it.
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.
" 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."
That's been the opposite problem for me. I can see my email leaving my client, see it hitting my SMTP server, and I can see Gmail accepting it. The client cannot find the emails. Not in their Spam folder either. I have no issues sending to my test Gmail account or my friends, but new people? Forget it. Google simply loses the email. I"ve tried to contact them to no avail (no surprise) and the usual answer I get from others is "well, just use gmail. nobody self hosts anymore."
>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.
I use Amazon SES to send system-generated messages from a couple of tiny websites I ran on EC2. When applying I needed to specify the volume, and put in a generous number in case the sites got a busy day - maybe 100-200/day (when realistic traffic probably averages single digits/day).
I use sendgrid to send mail I host on Linode I manage with Cloudron which works with sendgrid and others out of the box. Cloudron is a cool paid server management app but their free tier includes email. Literally give the app your DNS provider details and API key, your sending service details (or internal smtp if you hate it when people actually recieve your email) and the rest is 100% automatic. The free tier limits how many one-button-press apps you can install. They're all regular open source apps, but they nicely maintain docket images for them all and the setup, including DNS for subdomains, is automatic and really smooth. I havr nothing to do with them but I was surprised by how smooth it was.
There’s more services that have free tiers but I doubt that is sustainable and I’m really not interested in periodically rushing to fix things if the next service starts turning the thumbscrews.
> 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.
As anecdotal personal experience, I switched off Google Calendar for a couple of years and couldn’t do it. There were too many missing conveniences that weren’t handled by the generic protocol. Invitations and RSVPs frequently got lost, updates to existing events weren’t really recognized, and invited mailing lists didn’t unfurl into individuals.
I switched back to using Google Calendar as a backend. It would take a lot for me to try a switch again.
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?
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.
I did all of this when self hosting for a few years. It was mostly fine, but for a couple of undelivered emails. Those were just enough that I lost trust in the system and eventually stopped running my own email.
People mostly expect email to be fully reliable. It’s not, but that doesn’t stop people treating it like that. As a result, even if you only fail to deliver 1 in 1000 emails, that could have significant consequences. Gmail et. al have a high enough deliverability rate that most people can get away with treating it as reliable.
I’m not saying people shouldn’t self host, but I think they need to be very aware of how it will change their trust of email.
IMO, what needs to happen is for people to see the 1 in 1000 as a problem with Gmail et al. rather than a problem with someone hosting their own STMP server.
Generally speaking, people I know who self-host their email do not have problems. However, inevitably there is the 1 in 1000. IMO, unreached recipients using Gmail et al. are likely to see the problem as with the self-hosted sender, not their own third party email provider.
One idea is to have a backup for emergencies. That is, a Gmail user could have an alternative, self-hosted means of receiving email on port 587 or 2525. By default, this mail drop accepts mail from no one. When there's a 1 in 1000 problem, the recipient could add the sender to a list of acceptable senders, either temporaily or permanently. The sender can then use the alternative instead of Gmail.
To be honest, in the last 20 years or so of self-hosting emails, the most common failure points were
• Gmail marked an email as spam, but still delivered it. Easily cleared up, no hard feelings on either side.
• Someone else self-hosts some abysmally maintained Exchange 2003 setup that just about barely works with GMail and Office365, after the MSP irresponsible for it gets enough verbal beatings. Impossible to get to work.
Your right, but email is never fully reliable. How many times have you lost things into your gmail/outlook/etc's spam folder?
And with the amount of genuine spam being sent FROM GMAIL to my backup gmail address, it's unthinkable to actually check through the spam folder with any regularity.
> In some cases, websites weren't even allowing email registration with a self-hosted email.
I've seen that once or twice, but it was because my self-hosted is on a .one domain. There are (not surprisingly) a few organisations out there that validate against the old set of top-level domains (.com, .net, etc, and the country codes). They just won't accept any of the new top-levels as real!!
I think "consumer" is being contrasted with a business contract offering static ip.
You should know because it is currently blocked - found by using mxtoolbox.com for example.
Or, suspect it will be because the ip to your residence is not a designated static ip. (In practice it may be ipv6 and never changes but applying a PTR to the ip requires assistance from the ISP and it would likely be outside of the contract.)
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).
My own question is similar to one of the comments on the issue, how likely is it to have integrations with other authentication services? SSO was mentioned there, but I'm looking more specifically for integration on top of Ory products.
I added "implement oauth2 support" to the todo list from that comment. Shouldn't be too hard. If anyone has tips for simple-to-setup-oauth2 setups to test against, let me know. Is oauth2 support enough to get SSO covered? SASL (as used by SMTP/submission and IMAP) supports other methods (openid, saml), but I don't know clients that support that.
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).
This is generally true. Patiently documenting steps as well as logging any corrective and preventive actions (something that I learnt when studying for ISO 9001) is prudent.
I (mostly) stopped documenting in prose and used ansible instead. It's a bit more work, but it paid off numerous times since then. The prose that's still left, because it's really really to cumbersome to implement, is left in the comments of ansible files.
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.
Not sure I need to be in that scale , I can leave with some downtime , I am not Google, and it's a low cost solution , re outgoing emails I can rate limit with some Redis counters and maybe ratio limits on send / received emails.
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.
My use case would be creating one AWS SES or Sendgrid credential that is authorized to sending mail for an entire domain, and then a mail server like mox would then further authorize which users could send emails as who (and probably filter by only allowing the correct email in the From: header for example)
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.
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.
IO.OX (used at mailbox.org and strato, among others) is "alright", but I haven't seen much material about self hosting 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.
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.
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.
Looks good, but since it's a young project I would suggest to anyone interested to consider Mailu [1], which is a mature project and looks easier to configure.
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.
> nor do the authors care about "this silly new fad"
In fairness, if you have chosen a platform that potentially introduces its own issues that isn't their problem unless they want it to be.
A friend of mine has a project out there that only has official builds and build instructions for plain debian-based Linux, and he finds demands for direct docker support to be irritating (far worse than demands for a supported native Windows build ever were). And demand is the right word: many don't just ask, and some seem to get personally offended when he responds that he doesn't use docker much himself so wouldn't be comfortable offering support for it directly.
Sure, it's the author's right to choose what to support and what not. But I'd argue that software openly hostile to docker is probably not the best choice as central piece of your docker-compose based emailling setup, if the alternative is a single golang binary designed for use with docker.
> But I'd argue that software openly hostile to docker is probably not the best choice as central piece of your docker-compose based emailling setup
What are you referring to? Because Mailu isn't Docker-hostile, quite the opposite: it is distributed as a set of Docker containers. And dspillett didn't mention what was his friend's project about, it could be totally unrelated to email.
> 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.
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.
this is great. i'll be needing mailserver to send out a lot of emails so self-hosted makes only financial sense. was pondering of making my own but didn't got to it yet. great that this is in Go as well.
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.
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.