Hacker News Reader

Comment by tgsovlerkhgsel | Hacker News Reader

There really needs to be

a) a docker container (or other standardized, easy to deploy technology) with a "mail server in a box implementing best practices"

b) a test for the stuff that Docker can't cover like DNS config, ideally with scripts to set it up on the most popular providers and clear copy&paste instructions for the rest.

People shouldn't need to fully understand DKIM, SPF, etc. - they should just be able to click a button, copy&paste generated DNS records, and be up and running.

Otherwise, commercial providers are just the only option that makes operational sense for most cases, _even if you know how to do it right_, because doing everything right manually step by step is still to much work to be worth it in many cases.

None of this seems _hard_, it's just tedious.

View on HN

Try https://github.com/tomav/docker-mailserver

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.

Agreed. A few years back when moving my personal domain from a failing provider I considered running my own email server on Digital Ocean; they had some great tutorials on setting up various parts and I followed a HN recommended tutorial. I was already happy setting up LAMP with a nginx reverse proxy, how hard could it be - I got it setup, and realised two things: Keeping everything running without getting compromised was going to take way too long compared to the benefit. Two, Google and MS wouldn't accept my email - not even to myself when I whitelisted it - it's a crap shoot.

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.

The push for me to use nixos was simple-nixos-mailserver which does exactly this while being fully configurable & extensible.

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

Doesn't seem to have external user auth mechanism than "declarative user management"?

A very promising project is https://github.com/foxcpp/maddy. It is an all in one server that can both receive and send email.

As mentioned in https://news.ycombinator.com/item?id=23960831 it's good for security to have SMTP server and IMAP server segregated, even separate physical machines, which you'll have a hard time doing when everything runs in the same process. What happens when maddy gets a security hole discovered.

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.

I believe a server wriiten in a memory safe language greatly reduces the risk of running such setup. To the point where it is an acceptable trade-off to get simpler maintenance.

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 sir, created in me hope for mail server in Rust. But this is just a Go Lang

If I had an infinite amount if time, I would sure write maddy in Rust. But as practice shows, there are only around 24 hours in a day.

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.

Oh when will this Rust hype end, November needs to come already.

Thanks for the tip.

> 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.

Yes, this is possible.

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.

even separate physical machines

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.

Memory safety helps, but isn't the only source of exploitable bugs.

You would not really want so many "private" ports exposed on a public facing machine.

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.

You can also just redirect receiving email from a public facing SMTP to an internal SMTP server which also runs IMAP.

This is actually how usual Postfix+Dovecot setup works in practice. Dovecot runs an LMTP server which is SMTP with some minor modificaitons. Postfix forwards messages to Dovecot's LMTP.

I use mailcow and it does both a) and b) very well. You can either selfhost or pay the developer to host it for you: https://github.com/mailcow/mailcow-dockerized

+1 For mailcow !

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 !

>People shouldn't need to fully understand DKIM, SPF, etc. - they should just be able to click a button, copy&paste generated DNS records, and be up and running.

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.

There are many more people who want to drive a car, than people who want to learn the minutiae of how it works.

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

Not everything is a car analogy.

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.

I have my own domain, my own bind and my own mail servers. I forward all the mail to google for reading and searching and the main value I get out of it is I actually understand how DNS and SMTP work. Which comes in handy once a quarter at work. I book marked TFA because I never got the newer (!) stuff setup like proper TLS and DKIM. It is very old setup from like 2005 or so and I think is grandfathered into Gmail somehow. At least my newest domain I treated worst than my older ones.

For A) I believe that is what https://mailinabox.email/ is trying to achieve

In search of self hosting email I tried out both MailInABox and Mailcow. MailInABox wanted to control DNS records which was a no-go. The primary driver behind the project seems to have arrogant attitude towards having users do DNS records themselves. Mailcow seemed nice but was guzzling up ram for seemingly no good reason. Finally tried out Mailu a few days ago which seems to work nice, albeit with limited testing.

Mail in a box suggests being the DNS server in an attempt to be more user friendly, there are a lot of DNS records to setup for mail. How ever external DNS is supported (see "System status & DNS" in https://mailinabox.email/guide.html)

The RAM intensive elements of mailcow are search and clamav, you can disable them both if you don't need them

If only it didn't come with so many things (Roundcube, NextCloud) I don't need.

I thought the same thing, but then I ended up using roundcube as my default non-mobile device mail client. And I just ignore the nextcloud bit.

(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.

There is: mailcow https://mailcow.email/

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.

Reply on news.ycombinator.com