I've had a lot of discussions with technical-minded peers about how the only real options for email on your own domain are fastmail or gsuite, which work out to about the same amount of money for a family of 5+, which is a surprisingly large amount (imo worth it).
This looks like something worth combining with alps for easy self-hosted email. I might give it a go and ditch gsuite!
I've been using a docker mail server pre-configured for years without issues. I switched from DigitalOcean to Vultr and finally landed on Hetzner. Always had no issues delivering or receiving messages from/to the big guys.
I'm also addicted to watchtower to keep it automatically updated without hassle.
I moved from DigitalOcean to Hetzner, and Gmail started marking all my emails as spam, most likely due to bad IP reputation. I moved to Zoho Mail  (at €10.80/user/month), which doesn’t have problems like these, and requires less work to manage.
With mailcow  it's pretty simple to setup your own email server in about half an hour with all the security included and having your email not being treated on reception as spam. It also ships with a webmail interface (SOGo ), rspamd UI and an admin interface for your server.
I used to be a Kolab  user and "promoter" for many years but the project seems stalled a bit recently and although it is still being worked on and developed, it is lacking documentation for the latest releases.
I have moved to mailcow recently and am amazed at how easy it is to setup and maintain as opposed to Kolab.
The thing I miss from Kolab in mailcow is the integrated LDAP storage and custom built UI (if anyone knows a good and reliable LDAP administration UI as a web app, please let me know!), which I got used to using for user authentication in other services. Luckily, there are some efforts in LDAP integration into mailcow , although, still not mature yet and not that tightly integrated.
There are a lot of smaller providers (but not fly-by-night, like dreamhost and 34sp which both have >20 years record) which will give you a domain with up to e.g. 100 emails for $5-$10/month, which is significantly cheaper than gsuite or fastmail.
Another good alternative is migadu (who sponsored the webmail you linked above, and IIRC are already using it). They do charge about $20/year for a micro plan that lets you have any number of addresses and domains , with some throughput limits, and $90/year for a full plan without those limits. Something similar to the micro plan was free until recently - personally, I'm on the $90 plan with a few domains and emails, which would have cost about 10 times on much on gsuite and fastmail.
I've been running a couple postfix mail servers on aws for about a decade for my ecommerce company, transactional messages only. It needs to be properly configured, which is non-trivial. Over the years it has been necessary to request IP unblocks from a few providers. Delivering mail to microsoft domains (hotmail, outlook, msn, live) has been problematic, so those messages only are now being delivered though SES. Incoming messages are forwarded to free gmail accounts. I spend 20 minutes a week blocking spam, we get very little now. We use about 15 rbl lists, but I also manually block client domains, sender domains, and do some header checks. Email is important to me and I enjoy doing it this way. It's super cheap, I can use several domains, and I have full control of the mail process.
Not sure if Maddy covers this use case specifically (I didn't see it covered in the documentation, but I figure it actually is possible).
I'm hoping to use a Golang-based application as a simple SMTP Relay, which also allows for ranges of IP addresses to be whitelisted to connect openly to it from within our campus network.
Basically, the scenario is as follows: a number of internal services are older and may not support the authenticated route so we can use Sendgrid directly and send emails securely, so instead we currently have them routed to an internal Windows server which is running an older piece of IIS functionality (it's an SMTP Server in Windows that can be turned on). That piece is configured to be open (so it can receive messages on Port 25) but is also limited to a set of IP address ranges that internal servers are using (so that it's not generally usable by just anyone inside our network) and is configured to send those received messages out using Sendgrid.
And I'll probably need to follow up with the developer again (or try and make the contribution back to the project on my own), but the main issue it had was that the IP range whitelisting wasn't available (and even whitelisting by specific IP addresses seemed problematic, so in my testing I had to keep it completely open for it to work as expected).
If Maddy can fulfill the need instead though I can give it a shot ;-).
There is no IP whitelisting feature in maddy. I believe it is possible to do it using whatever off-the-shelf firewall you have on your system. Could you elaborate on the reasons it is not a viable way for you?
Fantastic job to both of you! Really appreciate the high quality work you folks have been doing on maddy and the email libraries. Are you guys running migadu as well? I might just switch if you are related.
Most people don't realize, but you can actually send email from a custom domain with a free Gmail account. You have to go through a 5-minute process for each sender address, but I used it fine for ~10 years.
I recently switched to Fastmail, and one of the features I like about them is that they support wildcard sender aliases, so if I sign up for a service with email@example.com, when I hit reply to any emails to that address, it automatically sends from firstname.lastname@example.org even though I've never specifically registered that identity with Fastmail.
This is not the same thing. I agree with the link, in that it is most definitely a hack. This only works because your domain registrar is handling email for you to begin with, which is undesirable for many reasons.
Also, while aliases in gmail work generally, I find they leak the main gmail account address, which makes them significantly less desirable.
I've been testing zoho mail for the last few months (in order to find a decent alternative to g suite, and not-so-expensive as fastmail)...and so far, zoho has been performing quite well. I certainly can not complain about the price; as i'm able to use their "lite" plan at $12 per user oer year.
I recently set up simple standard setup (postfix/dovecot/spamassassin) and it works fine. There's small amount of spam, like few mails per week, nothing to worry about. I can receive and send mail just fine.
Though I admit that for someone who did not tinker with UNIX for years, configuring this kind of setup might be daunting.
Personal mail could be solved by some kind of daemon which provides SMTP, IMAP, built-in spam detection, DNS checks, some simple administration web interface and works with 0 configuration for typical use-cases. Maddy could be this project, so I would be happy to replace all those daemons with a single binary. I hope that they'll implement spam detection, as rspamd is a separate daemon which requires redis, so in the end it's still a complex setup with lots of moving parts.
I've tried to self-host email for my domain a couple times over the past few years, and I always end up falling back to a paid host for this reason; I rarely use email these days, but when I do (or usually when I'm expecting an email from a recruiter or other business-related sender) I need some sense of confidence that it will go through correctly. The lack of ability to confidently send via self-hosted setup definitely feels intentional, which sucks.
A lot of this is due to newness and perhaps bad IP reputation. You can fix the reputation by requesting your removal from blocklists. The newness should be fixed after a few years - have you run it on the same IPs for those 15 years? In my experience after a year or so the problems go away (admittedly this is on a much larger scale than personal email).
I’ve used greylisting for the last five years or so. I stopped doing so completely and moved to Fastmail. Greylisting delays, while unnoticeable with the contacts I frequently communicate with, were very annoying with new and one-off contacts, especially all sorts of confirmation emails from bank etc, which would often expire before greylisting allowed them in. Sometimes, emails were sent through cloud mailing systems, so coming from a different host each time they’d hit greylisting again and again and again.
I pay $20/yr for unlimited accounts, 50GB of storage with mxroute. I've been quite happy with it. $30/yr for domain + email is worth it considering how important your address is for absolutely everything on the web
You're right; I was being too broad in my critique.
Intellectually, I don't like domain DNS on the same box; practically speaking? It works and works well -- so well that it's often easier to disable per-domain DNS where my sites are hosted and just point A records over to the sites from MAIB.
It's hit and miss. I've been running hosted mail services for years, both for myself and for a handful of other people and businesses.
SPF and DKIM are pretty much required now, as are TLS/SSL. From there, it turns into a dice roll. Gmail is terrible about this; they have a totally opaque and very frustrating engine that sometimes filters messages into a junk folder and sometimes doesn't. Outlook.com uses a somewhat more traditional internal RBL, but they are happy to block network segments and they don't offer any way to query their blacklist or request removal from it, so you could do everything right but a neighboring VPS or IP will get you blacklisted anyway. Comcast will simply accept delivery of messages and then disappear them depending on an arrangement of the stars that I haven't quite figured out yet. And those old sbcglobal/Yahoo services users... just, uggghh.
A popular solution is to rely on a third-party service to handle your outbounds. Sendgrid specifically is really bad, they carry way too much junk traffic, so don't go with them if you decide to try this out.
I have a post banging around in my head that's titled "Email is fractally broken", and getting outbound non-spam messages to reliably land in other people's inboxes would be a significant part of that writeup.
I happen to be running a test with them this week to see what deliverability looks like on their end. So far only 79% of their messages have been accepted for delivery by remote service providers. These are non-spam, non-transactional, typical business correspondence messages.
In their activity feed right now, SendGrid traffic is being blocked by comcast, GoDaddy, iCloud, and a cornucopia of smaller services.
On the receiving end, I've had to deal with waves of spam from SendGrid for years, and it's especially difficult because they carry a mix of spam and legitimate traffic, so blocking them causes complaints and not blocking them also causes complaints.
I have been self hosting my emails for many years on cheap dedicated servers (previously kimsufi by OVH and now Hetzner).
Never had any issues with sending mail. But I've been careful with the initial setup and have all the expected requirements covered : no open relay, SPF, DKIM, reverse ip, TLS,...
Been using the tutorial at workaround.org as basis for building the stack (postfix, dovecot, rspamd,...) and, while the initial learning curve was high, once its been set up, its been a really very stable setup requiring practically no maintenance whatsoever.
Not saying that's for everyone, just saying it works for me.
I guess I was lucky at the dice roll mentioned by other comments.
Ah yeah, and testing your outgoing emails using a service like mail-tester.com is very very useful. I aimed for and reached a perfect score 10/10.
I run my own mail server and have never experienced such issues. The important thing is that your mail server is not an open relay and you set up DKIM and SPF. Oh, and never run a mail server with an ip originating in a residential area, you'll get blacklisted almost instantly by virtually any mail provider.
It isn't even necessarily 'residential' IP's. It's IP's that don't have a valid reverse dns, preferably one that is also forward resolvable. Most ISP's won't let you set your reverse DNS on 'residential' connections, so it ends up being a blocker. Now you could set up a vpn tunnel to a vps provider that lets you set your reverse dns, and then things get a bit easier.
So prereqs -
1) Valid reverse DNS on your sending IP. Preferably with a hostname that is also forward resolvable.
2) SPF Records
You're right, that's the basic ingredient #1 I forgot to mention. Functional rDNS is essential. You don't want to have your mail server running at home anyhow. A friend of mine had a janky setup at home until I convinced him it's a bad idea.
These anecdotes are heartwarming but in the end useless as advice. If your mail is getting through it only means that there are no spammers on your network, i.e. you are lucky. Having an abusive mailer on your network (IP subnet, ASN, or even sharing your registrar) could happen at any time, with unknown impact to your IP reputation and deliverability of your mail.
If it wasn't an effective feature for classifying spam, then people wouldn't use it. But, in reality, it's incredibly effective because the only people who want to use residential IPs and rent-a-server IPs for running mailers are criminals and a much smaller population of dorks.
I agree lists are definitely effective but its a cat and mouse game sort of with a lot of overhead. We can still use ip lists for accepting/rejecting mail but that should be the lowest priority check with very less weight.
Lists are like the DRM kind of tech, where the genuine user has the real headaches (pay a service to filter my mail, cant self host etc) while the spams are still flowing through.
Yes and no. It certainly is possible to get good deliverability, but you gotta play by the rules (which is: all the RFCs). But when you do, there are also a lot of poorly configured email servers out there that don't comply to the RFCs at all, so email services need some tolerance to processing email from badly configured sources. It is almost always a compromise.
It is easy to get an email server running initially, but hard to get all the auxiliaries (SPF, DKIM, DMARC, MTA-STS, TLSRPT, BIMI, etc) set up correctly. It's even harder to debug deliverability issues, since there is 0 feedback on why your email is not being delivered. To a point where it inspired me to build an email hardening monitoring/validation service .
At the risk of being downvoted by people who are frustrated by email deliverability (and it is frustrating, I know): when you have email deliverability issues, it is almost always because you did something wrong on your end. Remember that false positives in spam detection hurts the $EVIL_BIG_CORP receiver as much as it does to you as a sender.
This server seems really promising as it integrates all required functionality into one application, where as compared with most other MTA's (postfix, sendmail, etc) its about a 20 step process to get it all setup correctly (dkim, spf, etc)
> Status update: JMAP is a big complex protocol that is not used by any popular clients and has no server libraries available for Go. IMAP is a big complex but also widespread protocol that is well-known, supported by any email client and has server library available for Go. Some of IMAP disadvantages come from incomplete client implementations, not protocol flaws, as JMAP developers want to convince you. I do not expect wide JMAP adoption in next several years, therefore the decision was made to prioritize improving IMAP implementation.
> If somebody insists on having JMAP, I recommend looking at Cyrus email server, perhaps write a Go library for its SASL delegation protocol so it could be used with maddy just as easy as Dovecot.
Its a bit of a mess and it needs a write-up, but it should be a reasonable start to making more jmap servers. (This does not implement the jmap application protocol, but it does generate fantastic json from any email blob, incl attachments, snippets, html and text output. And thats crazy difficult to implement correctly.)
I had similar issues where I wanted to remove IMAP complexity from client app, so I created a daemon proxy that sits between client and an IMAP server and “translates” REST API requests to IMAP commands: https://github.com/andris9/imapapi
Putting aside issues with sending mail to recipients using third party providers, have you been able to receive mail reliably from (a) senders using third party providers or (b) senders running their own SMTP.
I've been able to receive nearly 100% from the big guys. For folks that run their own I run into less issues these days. I'm still on Postfix. Some of the client and header checks used to (c2005) be too strict. But! When it failed, there were logs I could see.
If you run your own, you'll want to get some log checking tools to make sure things are tidy.
No issues at all. It comes down to the way they have set up their own mail servers. Incoming email is being checked for DKIM, DMARC, etc and then handled based on that. Logs are also super helpful in determining what went how in the reception process.
Yes, and yes, no problems ever with receiving mail on my self-hosted systems. exim4, self-signed cert. Sending is what may be difficult but personally I only had very minor trouble with that (VPS on a reputable provider, all set up properly).
Hetzner. I once was blacklisted at MSFT and filled out their online form, which solved the problem within a day or two. The only provider that doesn't accept my mail (for years already) is AT&T but this is something I can live with (I rarely have to send something to AT&T, as I am only dealing with locals).
The web's answers for a suitable antonym seem inappropriate  (all referring to "small" rather than "many parts". I reckon megalithic is the way to go.
Although I've been hosting my own mail server (postfix/dovecot) for years I must admit that I treat most of its parts as a single black box. My head just doesn't grok the entirety of processes and the various sub components (spam, grey listing, filters).
I prefer monolithic every day. It's not hard to provide plugins that allow custom filtering/ spam etc, so the end result can easily be the same.
Especially for personal /small business servers, simplicity wins everytime IMHO.
Default configuration runs everything as a single daemon. This has been done to minimize any management overhead, avoid the complexity and performance overhead introduced by IPC.
It is definitely possible to split things apart though - this is not something of a hard design decision. This is what LMTP is for, right? maddy can work as both LMTP server and client and also supports both server and client parts of Dovecot's authentication delegation protocol.
So you can do something like that:
1. maddy instance running SMTP on port 25, running inbound filtering and then doing transparent LMTP forwarding to ...
2. maddy instance running LMTP on some unix socket, delivering to local storage and providing access to it via IMAP, authenticating users using ...
3. maddy instance running Dovecot auth's protocol on some unix socket providing authentication service using some DB.
4. maddy instance running Submission, managing queue of outbound messages, trying delivery by forwarding them to ...
5. maddy instance running LMTP on some Unix socket, actually attempting outbound delivery.
In fact, you can also put any of these on separate VMs/containers or even physical systems. And if we add some load-balancing capabilities to SMTP client then it can be used to scale message processing (though a single daemon can already handle quite a lot of emails and users without problems).
Postfix's architecture is the classic UNIX style of "do one thing and do it well", of composable processes.
So it's not a monolith, it's a composite. If that makes sense.
Sure, the components of postfix are not standalone tools, they are very much like systemd. One codebase (monorepo, yaay, old is new), sharing a lot of common internal code.
In the end multi-process composite (like oracle and postgresql RDBMSes) or a multi-threaded monolith (like MySQL or anything that runs on a JVM) is not that big of a difference nowadays. Both can be performant, both can be maintained well/efficiently by big teams and by a one-man-army (see how postfix is mostly maintained by Wietse Venema).
As someone who uses and loves Caddy, I'm very excited about a mail server with a similar philosophy. I'm rooting for you!
That said, Caddy's killer feature for me was automatically configuring certs, that's what made me switch from Apache back when we were moving everything to HTTPS. I still don't fully understand how certs work, but fortunately I don't really need to. Until Maddy does this, it won't be a good comparison.
Also I would really appreciate some documentation for making this work with Caddy handling TLS certificates for me. I guess I'll file a bug about that.
Does anyone know of a mail server (imap) where the developper can be in control of the mail source? I wanted to expose one of our tool to mail clients, something that handles all the imap talk and gives you onread/onmark/ondelete/... events, but I found very little libraries or servers for that kind of usage
What's the license for project? It's a bit odd to see a serious opensource project without any license specified as it prevents adoption for at least some of potensial users. I for example pay close attention to licensing as a personal user. It's just too risky to invest my time learning to use project which can any time in the future become paid or restricted in other way.