Mox – modern, secure, all-in-one email server

You may have just forgotten the pain of the learning curve? Admittedly postfix & dovecot are way more sane than rspamd. But their whole default config (and something like 50% of the options and documentation) are oriented around UNIX system accounts for each of your mail users, which seems insane and 80s-era to me (let's go dial up to the mainframe at 300 baud and see if we have any mail). It takes dozens of pages of documentation to orient yourself away from all that, understand Postfix's "address classes", that you generally want "virtual mailboxes", etc. No support for DKIM, except through sendmail-invented "milters", of which Postfix heartily recommends you to OpenDKIM, a project which hasn't been touched in 10+ years, doesn't support EC signing, is not packaged on most distros, is documented on a outdated non-https site with sparse even more out-of-date plaintext documentation, referring you to a defunct FTP site to download the code, etc. And milter requires setting up a UNIX or inet socket and tedious configuration, etc. etc.

Poor support for SASL, at least for mail users looking to god forbid send an email and relay it to the internet, and password-protect against random spammers doing the same, referring you instead to Dovecot SASL - also legacy cruft (partly the SASL protocol designers' fault), SASL has numerous "mechanisms" but nearly everybody uses just the PLAIN mechanism, ensuring a TLS channel is established first, which is about 10 lines of code to implement.

Just a ton of unnecessary legacy cruft IMHO.

Using this now, and love it. For easy mail reception and sending, mail-in-a-box does it all for you (if you don't mind opinionated, but stable) and Stalwart does it all for you and is highly configurable, including an oauth2 server and more. Keen to try Mox, but I think it went viral and their website accidentally got ddos'ed.

Is it known to be compatible with OpenBSD as-is, or with minimal tweaking?

OpenDKIM is unmaintained and does not support Ed25519 signatures.

Comparison between Mailcow and Mox:

Mailcow (from https://docs.mailcow.email/getstarted/prerequisite-system/#m...):

  A single SOGo worker can acquire ~350 MiB RAM before it gets purged. The more ActiveSync connections you plan to use, the more RAM you will need. A default configuration spawns 20 workers.
  *RAM usage examples*
  A company with 15 phones (EAS enabled) and about 50 concurrent IMAP connections should plan 16 GiB RAM.
  6 GiB RAM + 1 GiB swap are fine for most private installations while 8 GiB RAM are recommended for ~5 to 10 users.

I checked with htop, and my Mox process currently takes <100 MB.

Manually - I want as slim/minimal/resource-efficient a setup as I can, and to understand what I'm configuring.

It is a rite of passage. That config system…

Btw, I ended up disabling webmail. I don't the users really need it. Nothing will compare to the Gmail experience anyway, so might as well just encourage people to use proper Mail clients like Mail.app or Mail on iOS.

Seconding for mailu. I've had a mailu server running for at least a couple of years that requires very little on-going maintenance, but I don't use it daily or for anything personally mission critical.

When I do need it, however, it's there, humming away happily.

> 1. Being plagued by spam,

An overstated problem IMO. Even just Thunderbird's client-side filtering works well enough to mostly ignore it and just occasionally go sweep through the spam folder to see if anything was caught inadvertantly. If you run your own server you can also setup whatever spam filter you want but personally I care more about real people being able to contact me than I care about never seing any spam (subjects only, pretty easy to tell what is worth openingn from subject + sender).

> 2. Being considered spam by major mail services (where most of one’s recipients will usually reside)?

Which may or may not be a problem for a personal mail server. Personally I have never had any problem with Gmail (YMMV) which at this point covers pretty much everyone I know who doesn't run their own server. Microsoft doesn't like my server due to others on the same block but so far I have decided that's not my problem.

personally - gmail is extremely plagued by spam. sure it goes into the spam mailbox most of the time, but enough non-spam email goes there too so you still have to check it. the current plague for me is "your package is awaiting delivery" spam - almost daily.

for being considered spam - i've had like 3 irl things set up on my old self-hosted mail, and these 3 arrived, even though while testing shortly after making the setup i did end up in spam. i don't know if companies have a whitelist of "if a user has this email on his account, don't send to spam" or something, but it hasnt been an issue.

i don't usually email too many individuals, in my social circles emails is not for that and has pretty much died long ago.

Due to the decent success i've had, i've spent some time today setting up mox to potentially replace my other solution - it is a bit of a process, many dns entries to make, and DNSSEC in my country seems to only update once a day so i'll see if i can enable it tomorrow, but so far it's working (but as usual, the first test email lands in spam.) i assume delivery will improve as soon as the domain is a bit older - i imagine most big mail services block email from a domain created the same day the mail is sent.

1) No. 1 spam email once per... 2-3 weeks. And Mox, which I run, comes without any spam filter.

2) Perhaps sometimes. The Mail-tester shows, nonetheless, a rate close to 10.

6-7 years or running my own email

And now compare this to one downside of the likes of gmail: one day you may get locked out of your email.

  > I’m honestly curious, what’s the point of a personal mail server nowadays?

With a catch-all domain, you can email <anything>@example.org, and I will get it. I don't have to first generate some addy.io or simplelogin.io or Firefox Relay alias; I can simply enter <company name>@example.org or <service>@example.org when registering on a website, hell I do that even on physical (paper) forms.

Later on, I can decide to add an alias with special configuration, e.g.: email arrives at <tax department>@example.org? → Route to "High importance" mailbox; I receive a Newsletter from a company I never heard of → <company name>@example.org sold my email address (and they can't strip the marker off, which they easily could with the +suffix).

  > Isn’t it the case that today they have two huge disadvantages:
  > 1. Being plagued by spam,

My spam folder currently contains 0 elements.

And I don't even have any advanced spam filtering or reputation blacklists or anything similar setup.

  > 2. Being considered spam by major mail services (where most of one’s recipients will usually reside)?

I do not remember mails of mine not reaching their intended receiver very often - while this might happen once a year (that you send an email and one second after get a "your message could not be delivered" response), I actually hear about this more often from peers using the largest email provider in the DACH region (GMX), so apparently I rank better? It's usually a misconfiguration from the receiver setting up some scam DNS blocklist (e.g. UCEPROTECT). Wouldn't call this a problem of the mail server though, and as I said, even some rather large (commercial) providers have the same issue.

Generally speaking, if you do things right, email will go well for you - this "doing things right" has simply for a long time been quite hard (when postfix/dovecot was prevalent where you need n-number of different third-party software packages, e.g. OpenDMARC). Nowadays, with the modern mail servers available, like Mox (or Stalwart, or Maddy) doing "things right" is very simple: Choose an hoster/ISP with good IP reputation (e.g. check with https://multirbl.valli.org/ if they are on any blocklists), setup your (modern) mailserver, and you're golden.

And this will come with a nice number of advantages:

- you have your own domain, so you're portable

- you control and are able to customize your email infrastructure (how many mailboxes do I want for my use cases, how would I like different aliases to be mapped to them, catch-all/wildcard, applying scripts on these mailboxes, etc)

- privacy/security: Your email (which I consider deeply core to the modern internet infrastructure and ones digital identity (due to controlling the login to basically all websites)) lives on your infrastructure, and no-one but you can access them

- selfhosting is fun, and one gains lots of knowledge about inner workings of the internet with it

Are you referring to the projects website or the webinterface (https://www.xmox.nl/screenshots/#hdr-admin-web-interface)?

Looking at this picture for example https://www.xmox.nl/files/admin-domain.png I could call the design many adjectives, but 'ugly' would not be among them.

Mox's FAQ addresses this question:

https://www.xmox.nl/faq/#hdr-won-t-the-big-email-providers-b...

Won't the big email providers block my email?

It is a common misconception that it is impossible to run your own email server nowadays. The claim is that the handful big email providers will simply block your email. However, you can run your own email server just fine, and your email will be accepted, provided you are doing it right.

If your email is rejected, it is often because your IP address has a bad email sending reputation. Email servers often use IP blocklists to reject email networks with a bad email sending reputation. These blocklists often work at the level of whole network ranges. So if you try to run an email server from a hosting provider with a bad reputation (which happens if they don't monitor their network or don't act on abuse/spam reports), your IP too will have a bad reputation and other mail servers (both large and small) may reject messages coming from you. During the quickstart, mox checks if your IPs are on a few often-used blocklists. It's typically not a good idea to host an email server on the cheapest or largest cloud providers: They often don't spend the resources necessary for a good reputation, or they simply block all outgoing SMTP traffic. It's better to look for a technically-focused local provider. They too may initially block outgoing SMTP connections on new machines to prevent spam from their networks. But they will either automatically open up outgoing SMTP traffic after a cool down period (e.g. 24 hours), or after you've contacted their support.

After you get past the IP blocklist checks, email servers use many more signals to determine if your email message could be spam and should be rejected. Mox helps you set up a system that doesn't trigger most of the technical signals (e.g. with SPF/DKIM/DMARC). But there are more signals, for example: Sending to a mail server or address for the first time. Sending from a newly registered domain (especially if you're sending automated messages, and if you send more messages after previous messages were rejected), domains that existed for a few weeks to a month are treated more friendly. Sending messages with content that resembles known spam messages.

Should your email be rejected, you will typically get an error message during the SMTP transaction that explains why. In the case of big email providers the error message often has instructions on how to prove to them you are a legitimate sender.

Using an ISP's SMTP is an incredibly obsolete and problematic concept. Poorly authenticated with even worse deliverability. It was a bad idea even 10 years ago and it's just horrid right now.

Use your email provider's SMTP, even if it's you yourself.

This just isn't true, of course you can, you just need to use a hosting provider or ISP that allows it. Plenty do.

hetzner allows outbound smtp by request. the process is relatively painless and quick.

I am sending and receiving emails on a small rack server in a datacenter for 40+ domains, and have had no real issues with deliverability. YMMV but I believe the reputation problem is heavily skewed against cloud providers such as VPS hosts more than anything.

Been running my own mail server since 1999 or so. No issues.

> It's practically impossible to > send SMTP from your own IP address.

I haven't had any problem in that regard in over 20 years of running a mail server on an old PC, on residential ISP connections. SPF, DKIM and rDNS config seemed to keep all the big players happy.

Which just made me realise I don't even have valid rDNS anymore, but it still works.

https://www.mailreach.co/

Those are the two problems caused by "big email". I've used hetzner, ovh and mythic beasts and had no issue with blacklisted IPs, and if you follow the Mox instructions you will be trusted and shouldn't get put in spam

For your first point, the key is an IP range that isn’t on a blocklist. Pick a very reputable hosting provider (not AWS/GCP/Azure), who has strict no-spam rules, and check out some spam reports from their ranges. Hetzner I’ve heard is good, digitalocean as well, but your mileage may vary.

For your second point, you live with it. I haven’t found a solution, at least. I’ve never landed in spam for corporate offerings (cloud O365, google workspace or whatever they call it now) or (very rare these days) anyone self-hosting with rspamd or equivalent, just regular personal mail (hotmail, gmail, iCloud, etc). That’s usually pretty easy to detect and work around (“hey I sent you an email” “oh I didn’t get it” “did you check your junk?”) Irritating, but not the end of the world.

I’m going to try hosting from my residential IP sometime this year, now that I have sufficient redundancy in terms of power and networking. I don’t know if I’ll have better or worse luck than with hosting providers’ IP ranges, though.

I self host on hetzner. ticket to support to open 25 and mailbox on a 5euro machine.

If people just want to stick it to the Man by moving out of the cloud, then the solution might be "medium email": hosted by a commercial provider, so you don't have to do all the admin, but not self-hosted.

My ISP, Zen, in the UK, gives static IPs. That, combined with residential fiber and a thin client makes excellent mini server at home.

I've self-hosted email on and off since the mid 2000s and my impression is that with the widespread adoption of DKIM/DMARC, the large providers have toned down the spam-by-default treatment of small/unknown email servers. Even Microsoft a bit, though you still have to get your IP whitelisted to send to outlook.com addresses usually.

This doesn't seem to be a problem anymore. What is a problem, though, is big tech companies spamming us incessantly and doing almost nothing to prevent that.

I get 10-20 spam E-mails a day from AWS, Google and Microsoft. Forwarding spam to their abuse@ contacts doesn't seem to do anything. And I can't block them, like I would a smaller spammer.

the FAQ claims it does have a web interface; is it not really functional, or something else? never used it myself

https://stalw.art/docs/faq#does-it-have-a-web-interface

Email hosting is absolutely the lowest maintenance of everything I host. For anyone else reading this, if you follow 'mox quickstart' it will help you set up your DNS correctly so you don't have the above experience.

It's good to hear you are working on 2FA that is certainly one of the biggest requests we receive lately for our self hosted email, and has almost pushed me to switch to cloud based services.

With regards to thunderbird and 2FA, it appears that there are some third party solutions, i don't quite understand how they work, looks like they are using SAML or something. https://www.miniorange.com/thunderbird-2fa-mfa-two-factor-au...

To give you an example for the BEC filters we are using, we use the postfix header checks with a negative lookhead regex. For example:

  # /etc/postfix/header_checks 
  # block impersonations
  /^From:\s"?Firstname.*(Lastname)?"?.*?<(?!(.*@domain1\.com|.*@domain2\.com|.*@domain3\.com|personal\.email\.account@gmail\.com)>).*$/ REJECT Sorry the server is busy right now.

We also use the mime header checks to block some bad attachment types (this is kind of oldschool there are certainly more modern approaches)

  # /etc/postfix/mime_header_checks 
  # block bad attachments
  /^\s*Content-(Disposition|Type).*name\s*=\s*"?([^;]*\.(ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta|htm|html|inf|ins|isp|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ops|pcd|pif|prf|reg|scf|scr\??|sct|shb|shs|sh|shm|swf|vb[esx]?|vxd|wsc|wsf|wsh)\b)(\?=)?"?\s*(;|$)/x REJECT Attachment name "$2" may not end with ".$3"

I'm not really interested in these setups that combine postfix, dovecot, opendkim etc. Those aren't what I consider modern all-in-one email servers.

The first screen shot is an e-mail from Ian Lance Taylor, the author of, arguably, the best UUCP implementation, and how I sent/received most of my e-mail up until 2010. It was really, really good at dealing with spotty wireless connections like CDPD and spotty early cellular hotspots. All my company's e-mail would come into an SMTP server, and then the last mile was UUCP to our individual laptops.

Story time: Back in maybe '93, I had a UUCP connection to a provider in Colorado. I was calling in from Nebraska (I had moved out there temporarily, but it had always been a long distance call). One day the e-mail stopped flowing. After a bunch of debugging I found that it would connect, and then sit there waiting for data packets from the remote end. I got ahold of the provider and the issue was they were using the SunOS UUCP, which stored all the files for all feeds in a single directory, and some of their users didn't call in regularly, some I get the impression were getting e-mail and not calling in anymore. Eventually this directory filled up to the point where the OS couldn't scan it within the UUCP timeout.

They ended up throwing hardware at the problem, but I suggested that they switch to taylor-uucp. Taylor stored the queues in a per-endpoint set of directories, so you didn't run into the large directory problem unless your UUCP endpoint was the offending one. However the provider replied that "tayloruucp doesn't work well with larger providers." So I asked Ian Lance Taylor about that, and he replied "That's news to [one of the largest national, probably international UUCP providers]".

In certain contexts, waiting for redelivery is unacceptable performance. Some people lose lots of money if they aren't in the loop. Imagine a group email chain, the CEO is asking questions, everyone is responding immediately - except you.

backup MX systems are useful, but the above faq is ... naive. it's fairly simple to deploy a backup mx that does not accept mail unless the higher-priority mxes fail a health check.