The dane module handles DANE related DNS lookups and outbound STARTTLS enforcement and verifications.
DANE (DNS-Based Authentication of Named Entities) is a standard for improving transport security. RFC 7672 describes the use of DANE for improving SMTP security between MTAs.
Momentum has supported STARTTLS for a long time. The use of STARTTLS for establishing channel security (encrypting the channel) can be achieved via the use of tls, tls_verify configuration options.
DANE for SMTP security allows the remote side to enforce the use of STARTTLS whenever clients like Momentum connect to the site to transfer email. RFC 7672 describes various methods through which remote sites could advertise the availability of STARTTLS with them, and whether they require the connecting clients to always use STARTTLS when communicating with them. DANE requires that the DNS resolver support DNSSEC, a secure way of looking up DNS records. Google DNS (8.8.8.8) is an example of a DNS lookup service that supports DNSSEC.
Momentum 4.8 and above supports the use of DANE for enforcing SMTP security.
When DANE is enabled, Momentum must be configured with a DNS resolver that supports DNSSEC in order
for DANE to work properly.
If the new dane module is enabled and the new directive
use_dane for a domain is set to true
,
Momentum will lookup the remote site's STARTTLS preferences (through DNS resolution) and use that
information to influence whether STARTTLS is established or not with the remote site prior to
transferring email to it. If the remote site requires the use of STARTTLS, Momentum will only
transfer email to the remote site if STARTTLS was successful in establishing an encrypted channel
to the remote site. And, in accordance with the DANE standard, Momentum will attempt to verify
the certificate presented by the remote host during STARTTLS based on the fingerprints it obtained
through DNS TLSA records. If the remote site is strict about the use of STARTTLS,
and Momentum could not perform STARTTLS successfully (e.g, Momentum failed to verify that the
fingerprint of the certificate presented by the remote site matches the fingerprint of the
certificate specified in the TLSA DNS records), Momentum will not transfer email to the remote
server. Email is held in the queue until Momentum can establish STARTTLS successfully in accordance
with DANE protocol with the remote site.
See RFC 7672 for more descriptions on how certificate matching is specified via the use of TLSA DNS records. Please contact support if you have any further questions about DANE protocol.
DANE works independently from and takes preference over the configuration controlled STARTTLS behavior.
When MTA-STS is also enabled on a binding domain, MTA-STS policy will apply to MX selection for email delivery, but if secure TLSA record is available, only the DANE TLS validation will be applied to establish the STARTTLS connection. If DANE TLS failed, no fallback to other verification means (e.g. MTA-STS, or administrator configured STARTTLS behaviors defined by tls or tls_verify).
You need to enable the dane module in the ecelerity configuration file to use the feature:
dane {}
Note
With dane module enabled, you still need to have the following global/binding/domain scope configuration options to fully enable the feature application on email sending.
The following configuration is the minimum needed to enable DANE TLSA lookup and TLS verification for all domains:
dane {}
use_dane = true
domain command is updated to show the TLSA record if available,
and a flag of +dnssec
is added to each DNS record to indicate that they are DNSSEC
validated. An example is shown here:
Domain 'comcast.net' has 8 MXs and a TTL of 58 seconds +dnssec [50 mx2c1.comcast.net. TTL:7198] +dnssec TLSA '_25._tcp.mx2c1.comcast.net' has a TTL of 120 seconds +dnssec 3 1 1 29b116c43593748345aa7f4c43717e792f94137a88b93d674de2ce1162f98625 [96.102.18.146]:0 IPv4 (0.00ms con 0.00ms dlv)\ ...
Other DANE Related Configuration Options
Related Debug_Flags
- DANE