Skip to content

Security Considerations

This page summarizes the key considerations for deploying a secure installation of KumoMTA.

Operating System

The .deb and .rpm packages that we provide are preconfigured to create a service account named kumod and grant that user write access to the suggested default spool and log locations.

The service packaging is designed to run as the kumod user. The systemd unit grants it the CAP_NET_BIND_SERVICE capability ambiently, which enables the service to bind the privileged SMTP port (25) without retaining full root privilege. Older versions of kumomta spawned with root privileges and then internally established the same configuration; retaining CAP_NET_BIND_SERVICE and dropping root privileges.

Spool, Log and DKIM Directory Permissions

The suggested default locations for these are:

  • /var/spool/kumomta
  • /var/log/kumomta
  • /opt/kumomta/etc/dkim

In the standard packaging these locations are deployed with owner kumod, group kumod and mode 2770 to constrain access to just the kumod user.

If you mount or otherwise select separate locations for these functions, it is recommended that you apply the same ownership and mode in order that other programs on the system are not able to exfiltrate information about the traffic, message content, or DKIM signing credentials.

Policy Directory Permissions

The suggested default locations for the policy files are:

  • /opt/kumomta/etc/policy

In the standard packaging these locations are deployed with owner kumod, group kumod and mode 755.

It is recommended that you avoid encoding secrets directly into files contained with the /opt/kumomta/etc/policy location and instead deploy using a secret manager such as HashiCorp vault, or alternatively, deploy those secrets in a similar way to the DKIM keys mentioned above.

Administrative Access

Administration is carried out via an HTTP listener that you must explicitly configure. The suggested default configuration for the listener is to bind only on the IPv4 loopback interface on port 8000, and for the loopback address to be considered to be a trusted host.

That means that any process or user on the local host can issue administrative commands to the kumod instance in the default configuration.

You can widen or restrict this access by changing the listen addresses on which you run http listeners and changing the trusted_hosts

SMTP Relaying

It is important to avoid allowing arbitrary sources of traffic to inject mail and relay it anywhere. The default configuration is to prevent relaying except for the relay_hosts defined in the SMTP listener.

You can further control relaying through a combination of SMTP Authentication and relay domains.

Authenticating Incoming Requests

See the following sections of the docs:

Inbound TLS

Both the SMTP and HTTP listener will automatically generate a self-signed certificate if you haven't explicitly provisioned a trusted certificate. This allows communication with the service to proceed on an encrypted connection, but without trust. The self-signed certificate generated for this purpose is held in-memory and will be regenerated when the service is restarted.

It is strongly recommended that you provision your own trusted certificates for your listeners.

Outbound TLS

The default configuration in the shaping helper for outgoing SMTP is to enable Opportunistic TLS, which is to make use of TLS if the destination host advertises it, but only if the certificate is trusted.

Unfortunately, a large number of destination sites have self-signed, expired, or mismatched certificates, which causes plain Opportunistic TLS to fail delivery to them. Many KumoMTA users deploy with OpportunisticInsecure TLS as a default instead: it accepts those same certificates, giving an encrypted but unauthenticated session with those sites. Clear text is used only when the destination does not advertise STARTTLS at all. The rationale is that an encrypted transport is more private than none, even though you cannot assert that the connection is to the intended destination.

Care needs to be taken when employing OpportunisticInsecure as it introduces the risk of a Man-in-the-Middle attack that can intercept the outgoing traffic.

There are three main ways in which you can manage that risk:

  • Use MTA-STS (which is enabled by default) to allow a destination site to publish its own choice on TLS policy via a well-known HTTPS endpoint. Sites that deploy MTA-STS can ensure that the TLS is set to required even if your default policy is opportunistic.
  • For well-known sites with working TLS, such as Google, override the opportunistic TLS with required TLS in your shaping configuration.
  • Consider enabling DANE, which is similar in effect to MTA-STS, using signed DNS records instead of publishing its policy via HTTPS. It requires working and trusted DNSSEC capability in your infrastructure. Since we can't guarantee that it will work out of the box without the operator explicitly confirming that functionality, this is not enabled by default.