It’s pretty good, I use it for my own server. It still requires some config, but better than running all the services from scratch.

Email has serious economies of scale and keeping such a critical system operational, on a small scale, was going to be some deal of stress.

So I just went with my hosting providers Plesk-fronted setup, which matches your para.3 description.

https://gitlab.com/simple-nixos-mailserver/nixos-mailserver

To me maddy would feel like sleeping on live electrical wires, only they are insulated by a thin layer of paper. Hope the isolation does not get scratched anywhere while you sleep. Even a non-dockerized, traditional setup like postfix+dovecot has better isolation.

Depending on how many targeted attacks you get in a day, you may pull apart the monlithic server and run inbound processing, filtering, IMAP access and outbound queueing as separate processes or even on separate systems.

(Probably i should put a better wording on https://foxcpp.dev/maddy/faq/)

> you may pull apart the monlithic server and run inbound processing, filtering, IMAP access and outbound queueing as separate processes or even on separate systems.

Can this be done without forking source code? E.g. just configuring two instances.

Thanks for the link to FAQ. Actually, simple, no bloat’ little dependency software definitely has some appeal.

This page shows how to configure maddy to only handle SMTP: https://foxcpp.dev/maddy/tutorials/smtp-only/ You can follow it but swap Dovecot for another maddy instance, configured as shown here: https://foxcpp.dev/maddy/tutorials/imap-only/

This works because maddy implements both client and server for Dovecot's SASL delegation protocol.

Alternatively you can configure pass_table to read from shared SQL database. Hm, maddy-tables(5) man page is not rendered on the website but you can look at sql_query module.

That being said, my project greatly benefits from Go concurrency features and simple I/O primitives. Also there are libraries written by emersion for nearly everything.

I think that is overkill for self hosting. Also as the author says below, Go is more memory safe than C/C++ in that there is no use after free and buffers are bounds checked.

A machine which has IMAP open tends to look like it has some good stuff.

I just forward incoming emails to an internal SMTP server which also serves as IMAP server, so MX records won't simply reveal your IMAP server as well.

A simple `docker-compose up -d` does the job. Then you just have to configure your records (SPF, MX, DMARC, ...) and it's all set.

A really nice work from the mailcow's team !

I oppose this. People should know what they are configuring. This applies to all stuff related to mailservers.

You probably learn more by setting it up the "hard" way (without containers) so that in case of failure you at least have a little insight in how the components work.

If it breaks, then you get someone else to fix it / get a better product is all they need to know.

But if you want ... it's like having a drivers license.

Or: you only "drive" self-driving cars. In case of emergency you don't know what to do. Perhaps an even better analogy.

(This is admittedly a very small deployment for two users and 3-4 domains on a $5/month VPS).

A lot of the other stuff I evaluated at the time (3-4 years ago) came with yet more stuff.

Automatically checks DKIM, SPF and DMARC settings for your domain, comes with docker and can be upgraded by running a single script, and has a webgui and spam protection.