Not sure its quality, but battling with postfix & dovecot's 20+ years of legacy cruft, I felt compelled many times to just throw them aside and build something like this on first principles - simple single binary mail server with modern protocol support, sans all the archaic UNIX-account timesharing-era sendmail bullshit that still lives on in the mainstays.
Going to have a look at this one, despite now having moderately deep postfix & dovecot knowledge.
That's not my experince - I use postfix and dovecot for years and they are rare examples of high quality software to me. I don't see any cruft. They are flexible which make learning and configuration harder compare to opinionated software where most decisions made for you by a developer and you have not choice but to accept them. I myself view sometimes see flexibility as a disadvantage but IMHO they strike a good balance. Postix often criticized by Exim user for not being flexible/configurable enough. And they don't force to use unix accounts, it's just one of options.
Having said that I would agree that using a mail server which combines all in one package is easier than unix way with multiple specialized parts combined. For a novice it could be a challenge to stichs (configure) multiple parts together, especially if you don't know how to test each part separately and blidnly follow some how-to.
Where you can find plenty of legacy cruft is mail standards and implmenting them correctly is not an esty task that's why I trust Postfix and wary of anything new until it battle tested on a large number of servers.
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.
OpenDKIM has been working fine for me for the last 10+ years. It's also in the default repos of my distro.
> 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.
SASL works fine for me with Postfix and Dovecot, including sending restricted to authenticated users. Also CRAM-MD5 was recommended over PLAIN everywhere even back when I set this up.
Like fts-flatcurve, an archive plugin for dovecot that can find stuff in 30 years worth of mails in a second, over IMAP in Roundcube. Or rspamd settings to blacklist not a single IP but an entire ASN of misbehaving colo clients. IMAP with namespaces is also a true pain to configure. Or setting bzip2 compression for an auto-expunged journal for spam, and archive without expunge. Painful.
If you made it this far, you will find that your IP address is tainted. So choosing a hoster that keeps his backyard clean from spammers is necessary, otherwise you will suffer by association. Did I mention SPF records in DNS.
So I consider our server a piece of art. 30 years in operating systems certainly helped.
And postfix is exceptionally well documented software. One of the best. It's easy to script config modifications thanks to `postconf` and do all kinds of interesting stuff with milters or policy servers, etc.
https://github.com/trusteddomainproject/OpenDKIM/commits/7c7...
Did you do this by hand / manually, or use a 'pre-canned' solution like:
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.
# handle "from:<>" special case
R$*<>$* $@@ turn into magic token
# basic textual canonicalization
R<$*<@$+>> $@$1<@$2>
R$*<$+>$* $2 basic RFC822 parsing
# make sure <@a,@b,@c:user@d> syntax is easy to parse -- undone later
R@$+,$+:$+ @$1:$2:$3 change all "," to ":"
R@$+:$+ $@$>6<@$1>:$2 src route canonical
R$+:$*;@$+ $@$1:$2;@$3 list syntax
R$+@$+ $:$1<@$2> focus on domain
R$+<$+@$+> $1$2<@$3> move gaze right
R$+<@$+> $@$>6$1<@$2> already canonicalIt hasn’t given me many issues so far! Nice to see new options popping up, though!
I think this might be a matter of personal preferences. Personally I find GMail very confusing, and not that user friendly.
FastMail UI is so much more intuitive. For me.
When I do need it, however, it's there, humming away happily.
But hey, at least it has a Copilot bar thoughtfully filling that useless vertical space on my screen!
[0] mailu.io
Hey it could be worse, at least it’s not sendmail.
My exim config became10x smaller after I started using upstream directly.
It's among the simplest (/least complicated) mail servers I've used, and I have to waste basically zero time on it. Running backup & update every couple months takes <5 min.
However, I noticed: when I showcase it to some people, some of them mistake the very simple minimalist web interface for being ‘outdated’ or similar - it appears that to be "modern", things are required to be extremely bloated, and even technical people look down on fast (seriously: try it) clutter-less design.
1. Being plagued by spam,
2. Being considered spam by major mail services (where most of one’s recipients will usually reside)?
Do you face these problems? How do you manage? Are there any potential problems I don’t see?
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.
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.
> 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
This isn't reliable as true catch-all adresses (i.e. any local part works) are easily detected at which point spammers can just use whatever. I also don't find this too useful because usually you either can't afford to stop doing business with the company (in which case you get to be angry but can't take any real action) or you could have just used a temporary address in the first place.
This may be true in theory, but in practice, on my domain at least, it has never happened.
[1] https://support.google.com/a/answer/12943537?hl=en
[2] https://www.namecheap.com/support/knowledgebase/article.aspx...
They took away the free "bring your own domain" around 13 or 14 years ago.
The design is ugly. It could easily be made much more beautiful while adding zero clutter.
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.
If your ISP provides you with an e-mail setup that you can use with a conventional mail client where you enter IMAP4 and SMTP credentials, chances are you can use that for SMTP sending. I.e. from the perspective of sending mail, your ISP can't tell that you're a server; it thinks it's just Outlook or Thunderbird connecting to it.
Receiving mail is no problem; your ISP just must not be blocking port 25.
It's handy to give yourself mobile access. When I send mail from my phone, it connects to port 537 of my own mail server which provides authenticated SMTP over TLS. It forwards to the aforementioned ISP. (I can't connect directly to my home ISP's SMTP server from my phone because the phone is on a mobile network unrelated to that ISP; the ISP's SMTP forwarding servers are firewalled so only the subscriber addresses can talk to them.)
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.
When I say I'm self-hosting, I mean I have a machine under a table right here in my home: True Scotsman's cotsman's self-hosting.
I drop SMTP connections from servers that simply do not have matching forward and reverse DNS. This rule eliminates like 90% of spam. It's a good rule and I won't make any exceptions. There's no way to contact me. Your bounce message tells you what you have to do: get your DNS ducks in a row.
That's assuming your residential ISP even bothers to assign a generic PTR record to your IP.
Even that doesn't work all the time. hotmail is currently bouncing emails from me[0] even though Microsoft's own sender reputation thing[1] says my IP is in good standing.
[0] with a link to [1] just to rub it in.
Residential IPs are spammy, so if for some reason you've decided you're going to let SpamAssassin to handle them post-delivery, it would make sense to give them a high score.
If the residential IP is in the MX record for the domain, even more so if the domain passes DKIM, why not?
However, if the host passes this check, and all other tests such that we decide to accept the mail for delivery (to be further processed by SpamAssassin), at that point why would we want to apply any score in SpamAssassin regarding the residential IP. We already decided to pass it.
Big providers often only support their own forms and ignore open sources trust providers.
Small providers often do not maintain their email services which will simply auto spam your mail/domain, when it does not come from the big 10 providers.
* web.de
* gmx.net
I also have to say that I always used a hetzner root server. Moved multiple times due to an upgrade.
I ALWAYS had to manually apply for removal of my Webserver. It worked for Yahoo. At that time it did not work for Gmail and Microsoft. I no longer was blocked but if I was writing for the first time to a recipient, I landed in the spam folder.
The software I used mailinabox and mailcow. Both had self checks. All green. I also used external scanners to check my config, all fine. You can check my GitHub (razemio). I even contributed to some issues for mailinabox.
This is not only true for selfhosting but also small providers. As an example:
* mailbox.org (auto spam Gmail and microsoft 2018)
All of this was a long time ago. Maybe I am just depressed from the bad experience and the FAQs are telling the truth. However it is hard to believe for me.
I am selfhosting since 1997 and I am working in programming / DevOps.
I set up a mail server with NixOS 5 times in a row with 5 different Hetzner Cloud IPs and each of them arrived fine at Google.
Also works for Microsoft services?
> It is a common misconception that it is impossible to run your own email server
... the FAQ then goes on to give all the reasons that argue it's really really hard and probably not worth it for most people.
Use your email provider's SMTP, even if it's you yourself.
Now suppose you contact that server and complain about being rejected.
Wouldn't it be ironic if they respond like this: "We receive e-mails from gmail just fine; fix the problem yourself, or use gmail".
This is how self-hosted e-mail people throw each other under a bus and let gmail win, while pretending to hold self-hosting as a cherished value.
(They would most likely be right about having to fix the problem yourself, unless they imposed some locally authored and highly unreasonable/dichkeadish filtering rule. The superfluous rhetoric about gmail would be almost as obnoxious as their rule, though.)
Sorry, but that's FUDish. The reality is if you do a proper email setup (DKIM, Reverse IP, etc.) you will be fine.
If you happen to actually get an IP that somewhat recently happened to be an email server, that was also sent out spam, which isn't something that's likely at all then you'll notice very quickly (just send an email to to gmail, etc.) and what you'll do then is tell your hosting provider you'd like another IP address, because it's not fit for your purposes.
I've been running, moving, switching IPs, providers, domains since 2005 and still am and there is just SO MUCH FUD. It's not hard. It's a one time thing. Personally I never ran into IP reputation issues ever. These are email addresses used in a professional capacity (B2B, communication with governments, etc.) as well as private use ones.
Pretty much every ISP, every university, etc. runs their own email server. Many companies do. Many private people do.
I have run them on the side for those 20 years now, partly as a hobby and so far the uptime was higher than Gmail's and since I use them for private, professional and sometimes for government communication I am dogfooding it and I would have very much noticed if anything bounced.
I have gotten bounces when a setup was initially broken, like when I do something like sending a test email to Gmail and that was off.
The reality is that IP and domain reputation aren't really great ways to filter spam anyways. Yes, it adds, but what makes you think that nobody sends emails from Gmail, a university or other stuff? What makes you think that spammers use static domains, etc.
Heck, not even DKIM and SPF are any guarantee. People will spam you from servers with extremely good reputation. Looking at my spam box most of them are from situations where accounts obviously simply haven't been blocked yet.
No serious spam filtering is done with IPs or domains being an "all or nothing" thing.
Also it's a two-way street. If a user of some email provider doesn't get their email and it becomes known people will be wary of it. And nobody expects the email landscape to stay static. There are newsletter and transactional email services all over the place, lots of marketing platforms running their own email servers and so on.
It's not like everyone does something magic, nor does everyone have connections, money or time to talk to all these companies. An email service not accepting emails won't exist for long.
And something that's also important to realize: If you do start using a transactional email service they oftentimes will make you pay EXTRA for a custom IP so you DO NOT share it with others, so you get BETTER reputation than the cheap one. And you configure your own domain with it. So why wouldn't these emails get delivered? And many of those don't run their own data centers and not all of them have their own IP blocks (though some have).
It's just if you couldn't even do regular private emailing, emails would not be the thing every website uses for login and communication.
> The reality is if you do a proper email setup (DKIM, Reverse IP, etc.) you will be fine.
You're not getting reverse DNS on a dynamic home IP.
> Pretty much every ISP, every university, etc. runs their own email server.
Yes? And what did I say: if your ISP has mail servers for you, it can simplify things greatly if you use them.
Smaller providers will generally not black hole legitimate message like Hotmail does. They have (paying) customers awaiting those messages. Junk folder? Sure, that can happen sometimes.
> You're not getting reverse DNS on a dynamic home IP.
I don't think anyone here is suggesting running a mail server on a dynamic IP.
> And what did I say: if your ISP has mail servers for you, it can simplify things greatly if you use them.
Only if you want to be using their domain and if you're not sending (too many) automated messages.
> Only if you want to be using their domain
No, that's simply not how SMTP routing works.
So you want some third party provider to be delivering mail on behalf of a domain for which they don't have even have the basics like DKIM and SPF set up, and hope for better deliverability than you could easily obtain with your own server?
Your SPF record, created by you, indicates that the certain forwarding servers you have chosen are authorized to deliver mail for your domain.
When you change SMTP providers, you update that.
E.g. a year ago I switched from Shaw to Novus (two Canadian service providers). I edited my server's SMTP credentials to the new Novus server and user ID, password and changed the SPF record to bless Novus servers as being my delivery agents. That's it; mail was flowing through thew new configuration.
The ISP doesn't know anything about my domain or any of its DNS records.
Yes, they have better deliverability than I could obtain with my own server directly, because my server is on a dynamic subscriber IP which makes it a pariah in the world of mail delivery. Sending from it directly to mail exchangers world over is a nonstarter.
I could pay for some server in a cloud data center somewhere. What for? I have no issues with mail delivery.
DKIM though.. ?
But I get your point: it might beat a home server on a dynamic IP on deliverability. Both options seem troublesome.
In my SPF record I have novus.ca.
So I don't care what IP addresses Novus's mail servers use, as long as they identify as <host>.novus.ca.
DKIM-signed messages can pass through SMTP hops. I'm not briefed up on the details of DKIM, but to my best current understanding, the originating domain signs the body and certain headers (not all of them) with its private key. When the message passes through multiple SMTP hops, some headers get added, like "Received: ...". I believe, these headers do not invalidate the DKIM signature. The relays just cannot be messing with the body of the e-mail, Subject:, From:, Date: and such. SMTP relay is not like a mailing list repost.
I'm now looking at some raw e-mails with DKIM signatures. It looks as if the signatures plainly specify the names of headers that are included in the signature, via a field that starts with h=, listing colon-separated header names.
I registered for their Postmaster Tools, which says
No data to display at this time. Please come back later.
Postmaster Tools requires that your domain satisfies certain conditions before
data is visible for this chart.
Refer to the help page for more details.
Outlook was even worse, and I just told my Outlook users to change providers.
Eventually I capitulated and got Google Workspace, and now everything gets delivered perfectly.
At 25+ years of hosting email through multiple hosting providers, this has been my experience multiple times. To be fair, happening less often with DKIM et al, but those are relatively new inventions.
Worked for a company self hosting famous brand emails. They would get blocked too. Imagine telling the band manager of a famous classic rock band that their email to their label was being rejected due to being black listed for spam.. (cc’ing the managers team)
Stop fooling yourself, it does not work fine. If it did you would not rely on that google outlook or yahoo account
Personal/private/family email can be easily self-hosted. You just need to know a few things to get it set up properly.
Getting a dedicated server with an ISP that does a decent job at keeping their IP blocks clean for email is about the best you can expect. Setup the appropriate SPF/DKIM/DMARC and get along. There's really not too much more to be done these days. Even the big guys don't always get along.
Almost all cloud providers with dynamic-load ephemeral IPs will show up on ban lists eventually due to vulnerability scanners, bad spiders, and spam/voip drops. However, it is far more common for Spamhaus free tiers to quietly go sideways when no one is looking.
Gmail/Outlook have their own peer policies that serve their own business posture. Google does require administrators register in their clown system as a user to exchange email, but it is effective policy that adds nuisance cost to people spinning up 30 servers a day to spam people.
Firewall Rate-limits are effective on small single-domain servers. A modern email server in Go that is isolated from each user space greatly simplifies the possible setups. =3
One of the server sends and receives emails for the forum, sometimes up to 1000 messages a day. It was set up 5 years ago.
Maybe this is a serious issue when you use popular VPS providers/IP ranges, but I use smaller providers, and just don't remember any email-related issues everybody are talking about.
For me, email self-hosting as easy as installing mail-in-a-box (for sending+receiving) or just plain exim/postfix (for sending only), with proper configuration.
We also have receipt tracking, which isn't perfect, but shows a >93% open rate.
We did have an issue delivering to a specific provider, but that was resolved by updating our DKIM with a more robust key length.
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.
Same.
> No issues.
Many issues.
I beg to disagree, as I've been running my own E-mail and sending from my own IP address for [checks notes] the last 25 years or so.
I send mail from several domains out of my mail server. The PTR record for that host actually doesn't match any of the forward hostnames.
If your client uses MS for email and doesn’t receive your invoices, it becomes a big deal.
https://news.ycombinator.com/item?id=35691618
In the end I set up a gmail account just to route all my outgoing mail through, with a whitelist of specific servers I know won't reject me for no reason (i.e. a few very small email services or friends who also self-host). Defeats half of the purpose but what can you do? There's nothing else I can possibly do to make my emails reach hotmail inboxes - I've exhausted all of their phony support channels and advice articles and clearly they just want me to go away and stop self-hosting.
It does mean that you are slightly less than perfectly self-hosted, in some sense.
If your mail server is in a position that it can send mail directly to any mail exchanger in the world, rather than going through a forwarding host, there is the advantage in that it can use end-to-end TLS.
- What happens when one of the big cloud providers arbitrarily start putting your emails in spam?
Are there solutions to this? It feels like the biggest value provided by "big email" are these two things
i spent some time today buying a new domain and setting up mox on a hetzner vm. the IP was on 3 blacklists on first check, after fixing the reverse dns it's on 2, one of which is apparently fake? dkim and dmark seem to be working, sending a mail to protonmail succeeds the checks, and yet it lands in spam - however, i'm confident once the domain is older than "just now" and i've set up DNSSEC (takes 1-3 days for this to start working in my country apparently) things will improve.
worst case i'll have to request a blocklist to unblock me, but i'll see.
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.
Mail server still gets blocked by random domains. Nope. Done with hosting email. Everyone assumes you are spam and won’t accept your mail unless you pay them (to be your mail provider).
Mixing email with the drive service in the account is actively hostile.
Honestly, I don't think that DKIM/DMARC has made the situation any better. In fact, spamassassin and rspamd often seems to work better than their spam filters in identifying actual spam.
That presumes the email is accepted into the spam folder rather than being rejected outright at SMTP time.
uceprotect bans entire subnets & ASNs if just one IP is suspected of sending spam.Apparently, you can pay to get your IP whitelisted for some time but it will be back on the list again. Its probably a scam/shakedown operation.
As these lists discourage self-hosting and benefit large email providers, they take their own time for fixing these issues.
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.
Nothing changed.
They just ignore the reports.
Thanks!
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"
> Another is 2FA. It would be relatively easy to implement in the web interfaces, but not with SMTP (submission) and IMAP. Most clients can at most do cram-md5 for authentication mechanism (old). I don’t know any clients doing the safer scram-sha-256-plus properly (with mutual verification and TLS channel binding, mox implements it). Interested in hearing what the thoughts are on these topics.
specifically for mox there was some things i would have liked to see: explain how the webmail isn't accessible on the public ip by default - i don't know how many of you want to be in a specific vpn for checking your email, but i sure was surprised i couldn't reach it, but had to activate it in config (and first figure out how to even do that). mox also doesn't redirect to https by default - imo it should, since it already includes the convenient automated certificate setup (which worked great).
maybe it is intended for a different environment, but since it recommends not running another webserver on the same host, i really don't want to access the webmail from the local server or by http. i like most of my services being available behind a reverse proxy, there it would make more sense. maybe i'll look into that variant later, but the documentation isn't quite as complete as i'd like.
No, not currently possible. I think it needs milter-like functionality in the smtp server. Would be good to have eventually.
To be honest though, throughout those decades, I learned a vast amount about how email flows. That knowledge is irreplaceable.
My recommendation is to try your own until you really, REALLY understand it. Then move to a paid solution.
I like Chasquid for its straightforward codebase and the hook system that you can use to customize it further.
https://www.linux.org.ru/forum/general/16654099?cid=16658164
I have 6ish email accounts I need to monitor, and outside of Outlook (and the various hellish variations of it), I'm yet to find a good client like all smartphones seem to have - all inboxes in one client presented together. I recall having a number of issues with Thunderbird a few years ago when I last tried it, but I don't remember why.
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]".
How do I configure a second mox instance as a backup MX?
Unfortunately, mox does not yet provide an option for that. Mox does spam filtering based on reputation of received messages. It will take a good amount of work to share that information with a backup MX. Without that information, spammers could use a backup MX to get their spam accepted.
Replying the same day is considered quick for places with C level.
I am also thinking about synchronizing all the data to another machine. It would allow a manual failover procedure. And it's nice to have another machine (IP) for outgoing email in case the primary IP gets on a block list. But this is all future work.
you can have several hosts with the same MX priority, and only spin up actual service when necessary. given modern health check tools and raft-consensus filesystems, it's very possible to build a robuse mail network on the cheap.
It's not exactly the same. When a backup MX has accepted the message, it takes responsibility of the message, and will have to send a DSN when it is rejected for being spam. Mox never "delivers" messages to a spam mailbox (it's that behaviour from the bigmail providers I don't like and undermines trust in email!). Mox either accepts a message, or rejects it at the SMTP level. When the backup sends to the primary, and the primary wants to reject, the backup would have to send a DSN to the potential spammer. Not great, and not something we have to do now.
But still, if it's only needed for emergencies, when the primary is down, it probably isn't too problematic. And the backup mx (with primary offline) can always be more strict, requiring dmarc-like alignment before accepting (to prevent backscatter if the primary rejects later on).
I didn't find anything about sub-addressing in the features list. Is it a supported feature?
Also, with a version number starting with 0.0. I'm left wondering if Mox is already stable enough to be entrusted with my precious email.
Other options i'm considering are mailcow running in docker.
Yes, assuming you mean addresses like user+<anything>@domain. The "+" is configured by default when you add a new domain. See https://www.xmox.nl/config/#cfg-domains-conf-Domains-x-Local....
> Also, with a version number starting with 0.0. I'm left wondering if Mox is already stable enough to be entrusted with my precious email.
It's been suggested to just increase the version number since it's more stable than a 0.0.X might suggest. I'm currently considering mox at release number 14. I'm still on the fence about it. Ideally people make the decision on the merits of stability, not based on the looks of the version number. But I understand it's used as a signal for how stable software is (but mileage will vary!).
At least I'm trying hard not to break anything, so upgrades will work for all installations.
Yeah, this one was interesting. It looks like microsoft updated their TLS stack to TLS 1.3, but incorrectly, breaking TLS connections to Go TLS servers. I don't know how to contact Microsoft about it, but others have raised issues with Microsoft. Mox got a workaround (disabling session tickets for SMTP) so Microsofts TLS stack wouldn't abort the connection anymore. This is a downside of being a small guy: You have to work around the bugs of the big guys.
Absolutely, if you feel that the software is already usable and is not lacking essential features, i'd suggest dropping the second zero in the current version number.
I noticed the roadmap section on your "Features" page, that also helps. I consider SIEVE server side filtering to be pretty essential.
I was looking at Horde's Imp, Kronolith and Turba so far - https://www.horde.org/apps - they seem OK but is there anything else in this area?
They're thinking of doing this already and apparently have some pox/prototype code, and a user has suggested a thing in the meantime.
So I ended up writing my own of course; no need for all the fancy features, just PLEASE let me receive email over SMTP and deliver them locally with 'dma'. Pfew.
Of the growing number of self-hosting options, I'm not sure how many of them are designed to scale, or to what scale they can scale...
Last I checked, you can't run mail servers on typical cloud providers (like Azure, Oracle) and cheap VPSs are almost guaranteed to have "dirty IPs" (used for spam and thus blacklisted).
My talk at FOSDEM was about this for a good part, https://fosdem.org/2025/schedule/event/fosdem-2025-5364-mox-....
If you have suggestions on how to make it less choreful to maintain, I'm interested in hearing it! Also if you had specific issues about maintenance/updates.
Secondly the documentation/instructions could be clearer for non-typical use cases, for instance catch-all emails. I have an Exim server with two domains pointing to it, I have catch alls on both, but the second domain is delivered into a folder in the first (it's used similar to SimpleLogin - for signing up to services). I assume this is possible with Mox but I'm not sure.
Having said that, I love Mox and I'm slowly moving all the email I host for other people onto it because it just seems to work.
This isn't possible yet. For me, the builtin filtering has been enough. But it's worth investigating what it takes to ask spamassassin for a classification. Could you open an issue at github for this?
> the documentation/instructions could be clearer for non-typical use cases, for instance catch-all emails
Agreed, documentation is in need of improvement. So far I'm often pointing people at https://www.xmox.nl/config/. Searching there typically pops up a config option. But it's not the easiest to find functionality that way. The admin web interface also needs to be made less spartan.
The catchall is possible, by configuring an address "@$yourdomain" with an account.
> because it just seems to work
This is certainly the goal. And I think we'll only get better over time!
Reading mox FAQ, it looks close enough to the ideal: https://www.xmox.nl/faq/#hdr-how-do-i-stay-up-to-date
I'm currently running a more classic setup with postfix and dovecot, because the updates and security fixes are managed by Debian. Once things are configured, I don't need to do anything using unattended upgrades (other than upgrade Debian itself when the LTS version goes out of support, that is!).
At this point it is easier for me to not touch what I have, but in my next mail server I will consider mox!
This is a good point. It would be great to have mox packaged in more distributions. I spoke with a package maintainer about this. They understandably need to be able to upgrade unattended from old versions to a new version. In the past year, admins have had to run an upgrade command here and there (e.g. to reparse all the messages after the parsing code changed). I hope to make all this more automatic this year. That should make it more appealing for packagers (and for all non-distro-using admins too!).
I think a new debian LTS release will be coming up soonish, we probably won't make that.
I understand, and appreciate, the modular philosophy behind OpenSMTPD, etc., but in practice it is quite frustrating and difficult to piece it all together - especially if you add rspamd, etc.
Speaking of which, how is spam handled ? I see this in the FAQ:
"Mox does spam filtering based on reputation of received messages."
... but it is not further elaborated.
Also:
I assume that the web service can be fully disabled and Mox can be run with no httpd but that is also not specifically called out ... can it ?
https://www.xmox.nl/features/#hdr-junk-filtering
I'm very happy with how the filtering works for me. Most email gets classified because of being a known sender. The first-time senders will go through the bayesian classifier, which keeps most spam out. For me, 1 spam message gets through every 2 days. If ham is incorrectly rejected as spam, the sender will hear about it, because mox will keep soft-rejecting the email, eventually resulting in a bounce.
> I assume that the web service can be fully disabled and Mox can be run with no httpd but that is also not specifically called out ... can it ?
You can run without the web interfaces. I think you can set it up without a public web server, but the admin interfaces are pretty convenient (though still spartan!), you could keep those internal. The webserver is needed for ACME, for MTA-STS, and for autoconfig. Btw, mox can also serve static files and do reverse proxying. The mox website is hosted by mox. I added webserver functionality (relatively tiny functionality/code compared with the email code!) so people wouldn't have to run another webserver, which greatly complicates the setup (with reverse proxying).
Mox is currently a single process handling all connections, including deliveries over smtp, imap connections, and webmail and other http requests, which isn't great. User connections should probably be in a separate process. I'm not too afraid of the mox process being taken over (by a bug being abused, I don't think that's easy/common in software written in Go), but of course it will be a good line of defense against that. Resource limit enforcement of separate processes would perhaps be even nicer to get.
I haven't gotten around to really designing privilege separation, but I'm forseeing some complications around handling http requests (of the webmail, pass each request on to the user process? Have to figure out how to do that with the http library), and message database access (the database files can only be open by a single process, need to do quite some back and forth to the user process in various places).
For performance, I imagine it only helps to have an integrated server. Performance isn't really top of mind, I don't think mail servers are commonly highly loaded, at least not for the smallish scale servers. Btw, mox does not require a lot of resource (eg RAM) to run.
Btw, I don't think it's better to have separate _components_ as in separate software packages. Integrating this functionality into one software package prevents all kinds of complexity that would otherwise arise in the integration points. Integrated software also allows for new/user-friendlier functionality.
Does it include shared folders? I look forward to seeing one of these projects include either that or NNTP support. Then we can get rid of Slack.
Perhaps someone can rewrite it using JMAP in the future...
It actually lifts the IMAP protocol to be used by web apps easily.
Definitely trying this!
I'm focusing on functionality/protocol support now. User/admin-friendliness and making it more attractive will come later. Mox will become irresistible to the masses then!
I thought it looked refreshing. Efficient, light, and no-nonsense. So you're right, it does match the intended audience.
Hosting your own email servers sounds good, until:
- Gmail and MS fling your emails in junk, despite ranking 10/10 on mailtester.net
- You have to search for old emails through RoundCube's byzantine UI (and eventually giving up)
Sometimes you can contact them and ask to be removed from whatever list or be allowed.
In my experience that lasts about a week, then blocks again.
I eventually gave up.
Tons of bots out there looking for SMTP serveres too, .
i.e
person@fred.com and person@mary.com are completely separate domains/imap accounts on the same server?
Someone has already been working on JMAP support in mox. I'm currently in a refactor of the storage layer, keeping history of (deleted) mailboxes too. Should address storage requirements for JMAP.
That definitely is an extract challenge with JMAP, keeping enough tombstone information to accurately calculate the `destroyed` ids.
Oh wait, yes, that'll never happen.
I'm pretty happy with forwardemail.net as a mail server, I selfhost snappymail to access it through a web browser. Not sure I want to take the step to selfhosting an email server, but I love the idea of cutting that external dependency.
That means that you do either one of two things:
- keep using forwardemail.net SMTP credentials in all your e-mail clients, such as snappy. Only point those clients to your own server for IMAP4 access (accessing the mailboxes where mail is flowing into your own server).
- or else, point SMTP to your own server, and configure your SMTP server to use forwardemail.net as the next host. There are some advantages in that you have your own SMTP endpoint that you can use with multiple devices. In my case, my phone can talk to my own SMTP server for sending mail, and my SMTP server talks to my residential ISP's SMTP server. My phone cannot talk directly to my residential ISP server, because it's not inside their network; it's on an unrelated mobile network. So my SMTP server acts as mail forwarding proxy for the phone.
- Sine you keep using forwardemail.net for sending, your reachability is not impacted.
Sending SMTP through forwardemail.net is covered in their FAQ. It looks like they have a few configuration hoops to jump through:
https://forwardemail.net/en/faq#do-you-support-sending-email...
I'm guessing you know about this because you must be using that with your snappy setup. What catches my eye is that they have some configuration bits where you declare your custom domain. That's not always necessary. For instance, in my setup, my ISP knows nothing about me and my domain. I just connect to their SMTP server, and use whatever From: header I want in my e-mails. The SMTP envelope address is one assigned by the ISP. I also noticed the bit at the bottom of that FAQ about their "manual review process on a per-domain basis for outbound SMTP approval" which supposedly takes 24 hours.
The current way of thinking is "It looks outdated", then the page is updated to look "modern" and that normally entails removing all relevant bits of information. I was going to attempt to find the Microsoft Exchange landing page, to show you what a modern landing page for a mail server looks like, and how utterly useless that is. Sadly the modernity has hit Microsoft hard and you can now only find the page for hosted Exchange/Microsoft 365 (https://www.microsoft.com/en-us/microsoft-365/exchange/email). Granted the page looks more inline with modern webdesign and it fucking pointless, there's not one bit of useful information.
Securing a mail server is full time plus job. Proton is great and free with their domain and cheap with yours.
No, it's not. I say that because I am the sysadmin for two mail servers (postfix/dovecot) with hundreds of users that have been chugging along for 30 years or so with no significant security incidents -- and since I know what my full-time job entails, I can tell you that on a day-to-day basis mail requires an absolute minimum of maintenance.