Mail Server

This repo contains a helm chart for installing a fully functioning Mail server with support for:

• SMTP and SMTP-over-TLS/SSL
• IMAP and IMAP-over-TLS/SSL
• (optional) POP3 and POP3 over tls/ssl

It expects to have an LDAP server available (installed separately) to identify and authenticate users. There are no "system" or non-LDAP users.

It can handle multiple "local" domains which are considered equivalent: the users will have access to all of them.

The first domain in the list is used for DNS names of the various components.

To receive incoming email, MX records must be set up in the associated domains, pointing to the smtp service. Note that this helm chart will not set up the MX records.

If the LDAP entry for a user has a mail attribute (configurable), any incoming mail for the user will be forwarded to that address (if the address is local, it goes to his/her inbox).

Prerequisites

You need to have ownership (or at least: control) of the domains the mail server will provide mail service for, as DNS records and SSL certificates are needed.

An LDAP server must be available to list/authenticate users. The mail server requires read-only access to the LDAP server to list users.

It expects to find Cert-Manager already installed and a suitable certificate Issuer (or ClusterIssuer) present which can issue SSL certificates for the various components on the first domain. The defaults assume a ClusterIssuer named letsencrypt.

External-DNS is useful too, as this will set up the necessary DNS A records for the services.

The k8s cluster must support storage with accessModes of ReadWriteMany, as multiple pods need simultaneous access to the same files.

To make use of Vertical Autoscaling, the necessary CRDs/operator must already be installed on the cluster.

Caveats

Running a mail server on the internet can be complicated and intricate. At the technical/conceptual level, it is not that difficult, but the presence of spammers have necessitated various anti-spam measures which complicate things.

Typically this results in trouble delivering mail to remote domains as they treat the email as suspected spam. The onus is on the administrator (YOU) to convince remote domains that the mail they receive from you is actually legitimate rather than spam.

Setting up DKIM and SPF records should help with this. It may also be necessary to regularly monitor various email blacklists and take the appropriate action if the outbound IP address appears on them.

mxtoolbox.com is a good resource for checking the configuration of your mail setup.