Mail-in-a-Box turns a fresh Ubuntu 18.04 LTS 64-bit machine into a mail server appliance by installing and configuring various components.
This page documents the security features of Mail-in-a-Box. The term “box” is used below to mean a configured Mail-in-a-Box.
Nothing is perfectly secure, and an adversary with sufficient resources can always penetrate a system.
The primary goal of Mail-in-a-Box is to make deploying a good mail server easy, so we balance ― as everyone does ― privacy and security concerns with the practicality of actually deploying the system. That means we make certain assumptions about adversaries. We assume that adversaries …
On the other hand, we do assume that adversaries are performing passive surveillance and, possibly, active man-in-the-middle attacks. And so:
Additional details follow.
The box’s administrator and its (non-administrative) mail users must sometimes communicate their credentials to the box.
These services are protected by TLS:
The services all follow these rules:
When using the web-based administrative control panel, after logging in an API key is placed in the browser’s local storage (rather than, say, the user’s actual password). The API key is an HMAC based on the user’s email address and current password, and it is keyed by a secret known only to the control panel service. By resetting an administrator’s password, any HMACs previously generated for that user will expire.
Console access (e.g. via SSH) is configured by the system image used to create the box, typically from by a cloud virtual machine provider (e.g. Digital Ocean). Mail-in-a-Box does not set any console access settings, although it will warn the administrator in the System Status Checks if password-based login is turned on.
The setup guide video explains how to verify the host key fingerprint on first login.
If DNSSEC is enabled at the box’s domain name’s registrar, the SSHFP record that the box automatically puts into DNS can also be used to verify the host key fingerprint by setting
VerifyHostKeyDNS yes in your
ssh/.config file or by logging in with
ssh -o VerifyHostKeyDNS=yes. (source)
fail2ban provides some protection from brute-force login attacks (repeated logins that guess account passwords) by blocking offending IP addresses at the network level.
The following services are protected: SSH, IMAP (dovecot), SMTP submission (postfix), webmail (roundcube), Nextcloud/CalDAV/CardDAV (over HTTP), and the Mail-in-a-Box control panel & munin (over HTTP).
Some other services running on the box may be missing fail2ban filters.
fail2ban only blocks IPv4 addresses, however. If the box has a public IPv6 address, it is not protected from these attacks.
The basic protocols of email delivery did not plan for the presence of adversaries on the network. For a number of reasons it is not possible in most cases to guarantee that a connection to a recipient server is secure.
The first step in resolving the destination server for an email address is performing a DNS look-up for the MX record of the domain name. The box uses a locally-running DNSSEC-aware nameserver to perform the lookup. If the domain name has DNSSEC enabled, DNSSEC guards against DNS records being tampered with.
The box (along with the vast majority of mail servers) uses opportunistic encryption, meaning the mail is encrypted in transit and protected from passive eavesdropping, but it is not protected from an active man-in-the-middle attack. Modern encryption settings (TLSv1 and later, no RC4) will be used to the extent the recipient server supports them. (source)
If the recipient’s domain name supports DNSSEC and has published a DANE TLSA record, then on-the-wire encryption is forced between the box and the recipient MTA and this encryption is not subject to a man-in-the-middle attack. The TLSA record contains a certificate fingerprint which the receiving MTA (server) must present to the box. (source)
Domain policy records allow recipient MTAs to detect when the domain part of of the sender address in incoming mail has been spoofed. All outbound mail is signed with DKIM and “quarantine” DMARC records are automatically set in DNS. Receiving MTAs that implement DMARC will automatically quarantine mail that is “From:” a domain hosted by the box but which was not sent by the box. (Strong SPF records are also automatically set in DNS.) (source)
While domain policy records prevent other servers from sending mail with a “From:” header that matches a domain hosted on the box (see above), those policy records do not guarantee that the user portion of the sender email address matches the actual sender. In enterprise environments where the box may host the mail of untrusted users, it is important to guard against users impersonating other users.
The box restricts the envelope sender address (also called the return path or MAIL FROM address --- this is different from the “From:” header) that users may put into outbound mail. The envelope sender address must be either their own email address (their SMTP login username) or any alias that they are listed as a permitted sender of. (There is currently no restriction on the contents of the “From:” header.)
As with outbound email, there is no way to require on-the-wire encryption of incoming mail from all senders. When the box receives an incoming email (SMTP on port 25), it offers encryption (STARTTLS) but cannot require that senders use it because some senders may not support STARTTLS at all and other senders may support STARTTLS but not with the latest protocols/ciphers. To give senders the best chance at making use of encryption, the box offers protocols back to TLSv1 and ciphers with key lengths as low as 112 bits. Modern clients (senders) will make use of the 256-bit ciphers and Diffie-Hellman ciphers with a 2048-bit key for perfect forward secrecy, however. (source)
The box publishes a SMTP MTA Strict Transport Security (SMTP MTA-STS) policy (via DNS and HTTPS) in “enforce” mode. Senders that support MTA-STS will use a secure SMTP connection. (MTA-STS tells senders to connect and expect a signed TLS certificate for the “MX” domain without permitting a fallback to an unencrypted connection.)
When DNSSEC is enabled at the box’s domain name’s registrar, DANE TLSA records are automatically published in DNS. Senders supporting DANE will enforce encryption on-the-wire between them and the box --- see the section on DANE for outgoing mail above. (source)
Incoming mail is run through several filters. Email is bounced if the sender’s IP address is listed in the Spamhaus Zen blacklist or if the sender’s domain is listed in the Spamhaus Domain Block List. Greylisting (with postgrey) is also used to cut down on spam. (source)