Lets talk about security for a minute

  • November 27, 2023

Email has evolved considerably in the last decade, but modernization efforts at the server level have lagged behind front-end marketing tech. There are many outdated deployments using insecure methods of accessing and securing email today. It doesn't have to be that way - there are modern solutions that won't break your budget. 

There are several ways to improve the security posture in your on-prem MTA.  Separating your keys and credentials from your sending environment is an important step.  This can mean storing your TLS certificates and DKIM keys in a remote secrets vault like HashiCorp Vault . It could also mean managing your SMTP and HTTP Auth credentials in a separate datastore or integrating a user directory system for authentication. Upgrading your systems with DANE, MTA-STS and Ed2219 DKIM keys will also enhance your security.

KumoMTA has a built-in keysource function that allows you to retrieve your secrets from a remote, secure store to protect you from physical theft or local intrusions. For DKIM signers, TLS certificates and keys, and HTTP or SMTP Auth credentials, this is essential in any modern email deployment.  If you are using MTA infrastructure that does not allow you to separate your secure keys from your sending environment, you should probably think about changing vendors.

HTTP or SMTP Authentication can be performed with a remote datastore like this.

local request = kumo.http.build_client({}):get 'https://example.com/'
local passwd = kumo.secrets.load {
  vault_mount = 'secret',
  vault_path = 'example.com-passwd',
}
request:basic_auth('username', passwd)
local response = request:send()

Now you can put your SMTP_Auth and HTTP Basic Auth credentials in a separate secure location and look them up when needed.

DKIM signing messages requires a crypto key, but leaving that on the sending server opens you up to potential compromise.  The example below allows you to store your DKIM key in a remote vault and call it when needed.

local vault_signer = kumo.dkim.rsa_sha256_signer {
  key = {
    vault_mount = 'secret',
    vault_path = 'dkim/' .. msg:from_header().domain,
    -- for greater security, store these as environment vars
    vault_address = "http://10.3.2.1:8200"
    vault_token = "hvs.MysuperPrivateTOKEN"
  },
}

DANE can be enabled for better security of email delivery.  DANE allows a sender to verify the end-point of the intended target cryptographically.  Setting this enables KumoMTA to validate that the TLSA hash retrieved via DNSSEC matches the TLS certificate that is presented by the receiving system. KumoMTA includes DANE with a simple configuration shown below.  Adding enable_dane = true to your shaping configuration turns this on per domain or system-wide. Setting the name_servers to a local cache will improve performance too.

kumo.on('init', function()
    kumo.dns.configure_unbound_resolver {
        options = {
            validate = true,
        },
        name_servers = { '127.0.0.1:53' },
    }
end)

While we are on the topic of DKIM, we should discuss the ability to sign with Ed25519 elliptical keys. Elliptical keys allow for having much smaller keys but higher cryptographic strength.  This means a smaller key in DNS can provide better security.  While some MBPs still don't recognize Ed2519 keys, it can be valuable for the providers that do use them.

[domain."example.com"]
  selector = 'dkim_ed25519'
  headers = ["From", "To", "Subject", "Date", "MIME-Version", "Content-Type"]
  algo = "ed25519"
  filename = "/full/path/to/key"  
  policy = "SignAlways"       # Sign and relay

There are many systems deployed in public cloud that were designed to operate in a closed environment behind a corporate firewall. These often make assumptions based on pre-cloud thinking and may not include any kind of authentication on their API and other access methods.  KumoMTA was designed to be deployed into public or private cloud.  As a result, access is restricted only to localhost unless intentionally configured otherwise. TLS can be enforced for SMTP and HTTP connections and is always required for SMTP_Auth injection.  

The other advantage to separating your secrets from your servers is that you can centralize the keystore. With KumoMTA, your whole cluster of MTAs can reference a single secure secrets vault, reducing errors and management effort while improving your overall security posture.                

Read the Docs | Join the Discord | Read the blog | Follow us