Skip to content

Security Considerations

This page summarizies 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 is launched as the root user in order to bind to the privileged SMTP (port 25). The service immediately on startup, before taking any other action, drops all of the root privileges except for CAP_NET_BIND_SERVICE (which is required to bind to port 25) and then switches its user id to the kumod user.

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, there are a large number of destination sites with poorly maintained TLS, so many kumomta users choose to deploy with OpportunisticInsecure TLS as a default, which will try to use TLS if available, but will allow communicating in clear text if there are any issues trying to establish the connection. That rationale for this choice is that having an encrypted transport is more private than not having it, even if that means that you cannot assert that the connection is to the intended destination, especially if you are prepared to send the message in clear text as a fallback anyway.

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.