Editing Mail Server Installation

The previous deployment of a mail server as a home grown kubernetes deployment finally broke when the underlying centos7 container was discontinued.  This solution surfaced recently, and after some challenges in adapting to this environment seems to be working properly.  Like the previous solution, it uses docker containers; but the author only provided a docker compose deployment method, so it requires a VM to keep it contained.

The solution is called "MailCow", and is located on GitHub:

 https://docs.mailcow.email/getstarted/install/

The package contains multiple docker containers that implement all the basic services required to support the mail server -- including a webmail application (that I couldn't get to work).

== Pre-requisites ==
Per the documentation, MailCow is best installed in its own system, so a small VM is the best hosting solution.  They recommended ubuntu, but my [[Basic Debian Installation]] worked just fine.  Preparing for this deployment is straightforward:

# Create a VM with 2 cores, 4 GB RAM, and 100GB in a single storage volume 
# Install Debian in the VM as described in [[Basic Debian Installation]]
# Create a static DHCP IP assignment (or use a static network configuration) for the mail server to provide a consistent IP address
# Create a DNS entry for the server as 'mail.williams.localnet' with CNAMES for 'imap' and 'smtp'

== Installation ==
The instructions for MailCow are very comprehensive and easy to follow:

# Follow the instructions in the documentation to install docker
# Clone the MailCow GitHub repo
# Generate a config file -- edit to specify the hostname and to disable the "Let's Encrypt" certificate generation (it will generate self-signed certs as needed)
# Edit config files as needed to accept mail from the local systems (10.0.0.0/24) as specified in <br/> `https://docs.mailcow.email/manual-guides/Postfix/u_e-postfix-unauthenticated-relaying/?h=relay`
# Start the server as specified in the docs (NOTE: it takes several minutes to get things initialized, so be patient).

== Follow-up ==
Reconnecting Thunderbird to the new server is a manual process, but not massively eventful.  This more robust server did require a modification to the standard SSMTP mail client configuration (the source domain needed to be specified), and it has become obvious that I need to actually switch back to a more robust postfix mail deployment on each server in the environment.  It is definitely overkill, but the SSMTP client is not very robust or fault tolerant.