Re: [PLUG] Self-hosted email server in Docker

[Rich Kulawiec via plug <plug@lists.phillylinux.org>]

On Sun, Sep 08, 2024 at 04:32:06PM -0400, JP Vossen via plug wrote:
> I read the (short) article but am not familiar with "Mailcow" and I
> didn't look into it.  As we've discussed, running your own mail server
> is not trivial for a variety of reasons, and this doesn't really talk
> about that.  Still, maybe interesting.

Interesting, yes; but there are some problems with this (based on
a quick read/skim of the basic documentation):

1. Anyone who can't run a mail server from the command line isn't
qualified to run a mail server.  This is the harsh, cold reality we
live in thanks to a combination of abuse/attacks and a combination of
ill-conceived anti-abuse/attack mechanisms that have been rolled out
as inadequate substitutes for competence and diligence.  It's quite
difficult to get everything right, where "right" is, unfortunately,
not only a moving target but a topic of frequent disagreement.  I say
"unfortunately" because email is *still* the best communications mechanism
on the Internet; nothing else comes remotely close and there are, at
the moment, no signs on the horizon of anything that will.

2. One of the essential parts of running a mail server is configuration
control/change management, e.g., if you modify the MTA config file or
the virtual user table or the anti-spam rules (or all of them in concert),
you need to keep track of exactly what you did, when you did it, and
why you did it -- and you need to be able to back out changes cleanly.
This is incompatible with GUI-based mail systems, because there's no robust
way to integrate them with the revision control system of your choice.

3. The current trend of developing/building everything to run in VMs is a
Bad Thing.  Yes, it's convenient, and yes, it allows skipping over lots
of due diligence, and all that, but it also incurs the overhead (not
just performance hit but complexity, security risks, etc.) of using VMs.

This thing apparently uses 11 Docker volumes, and well, that's just nuts.

4. The documentation says that this requires 10G of disk space.  For
comparison, my entire email setup including the source code, installed
binaries, and configuration files fits in 40M.  Frugality is an essential
virtue of competent system adminstration, and burning 10G for a mail
server is antithetical to that.

5. The list of features includes this:

	"Allow mailbox users to toggle TLS enforcement for inbound and outbound messages"

Permitting users to tinker with security mechanisms is, and always
has been, an astonishingly bad idea.

	[ Which is one of the numerous reasons why "spam folders" are a
	worst practice in mail system engineering.  Maybe I should give
	a talk about that. ]

6. I note that the list of features doesn't seem to include a list of which
RFCs this complies with.  I would be interested to know if its stock
configuration complies with the relevant set of RFCs and/or if it refuses
to allow anyone to configure it in a way that does *not* comply with those
RFCs.  (I'll presume that it complies with most of the relevant RFCs
because of the components it uses...although there are people out
there who have found ingenious ways to override sensible as-shipped
configuration settings with broken or insane ones.)

7. This sentence:

	"mailcow relies on many well known and long used components, which
	in combination result in an all around carefree email server."

is six kinds of wrong.  One of the major problems that we currently
face is that a *lot* of people, including some of the ones that run
some very large operations, have taken a "carefree" approach and
do not pay attention to what their mail servers are doing and do not read,
think about, act on, and reply to email to their RFC 2142 role addresses.
Encouraging people to think that any email server can be or should be
"carefree" is not only wrong, but destructive: it makes the problem worse.

TL;DR: I think what we have here is a project from a bunch of
well-intentioned people who lack significant long-term diverse [1] experience
with mail system engineering and operations, and are thus blissfully
unaware of how the real world works (or doesn't, as the case may be).

---rsk

[1] The word "diverse" is there because it's important.  There is,
unfortunately, an oft-repeated but wildly incorrect mantra that it's
necessary to have experience with mail systems handling 500M+ users
to truly understand scalability issues and how to deal with them.
This is absolute nonsense.  If you can handle a mail system with 50K
users *correctly*, then you can handle one with 500M the same way:
it doesn't require any refactoring.

What is vastly more important is learning how to handle mail systems
operating in different environments (e.g., business, academic, government,
nonprofit, etc.) with different operational requirements, with different
MTAs, with different operating systems, with different threat models, etc.
People who only work in one environment for a long time (no matter how
large it is) don't acquire this experience.  That's not their fault
of course, but it does mean that there's a large collection of problems
they've never had to solve.
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug