From this page, you can configure Transport Layer Security options for the MTA.
TLS seamlessly ensures transport email encryption for email delivery over SMTP between supporting servers.
TLS Settings
LibraCyber ESG acts both for receiving and sending emails, so TLS can be configured on both sides: you can define different policies on receive (server) or when sending (client).
The default policy for incoming and outgoing connection can be one of the following:
- none (no TLS when receiving emails)
- may (try to negotiate a TLS connection, this is the default)
- encrypt (force a TLS connection when receiving an email and if it fails do not accept incoming mail)
Warning: according to RFC 2487 encryption MUST NOT be enforced in the case of a publicly-referenced SMTP server. You will reject legit email traffic in doing this.
Setting up the SMTP Supported Ciphers parameter, you can choose the minimum TLS cipher grade that the MTA will use. This setting allows restricting the available ciphers and protocols. To learn more about supported TLS protocols and ciphers for each cipher grade you can read the Supported TLS Ciphers knowledge base.
: For a publicly-referenced SMTP server the default is to fall back to plaintext if no shared combination of cipher/protocol can be negotiated with the remote party. This means that by restricting the list of ciphers there are higher chances of falling back to plaintext.
Per-destination SMTP/TLS client policy maps
A different TLS policy can be specified for next-hop destinations. This settings will override the default settings for outgoing connection.
Each policy is defined by 3 parameters:
- Destination (the next-hop destination as domain, mail server or IP address. When specifying a mail server or an IP include it in square brackets [1.2.3.4])
-
Policy
- None (no TLS)
- May (opportunistic TLS. The optional “ciphers”, “exclude” and “protocols” attributes are available)
- Encrypt (mandatory encryption. Mail is delivered only if the remote SMTP server offers STARTTLS and the TLS handshake succeeds. At this level and higher, the optional “protocols”, “ciphers” and “exclude” attributes are available)
- Dane (mandatory encryption. Mail is delivered only if the remote SMTP server offers STARTTLS and the TLS handshake succeeds. At this level and higher, the optional “protocols”, “ciphers” and “exclude” attributes are available)
- Dane-only (mandatory DANE TLS. The TLS policy for the destination is obtained via TLSA records in DNSSEC. If no TLSA records are found, or none are usable, no connection is made to the server)
- Fingerprint (certificate fingerprint verification. At this security level, there are no trusted certificate authorities. The certificate trust chain, and expiration date are not checked. Instead, the optional “match” attribute lists the server certificate fingerprints or public key fingerprints. The digest algorithm used to calculate fingerprints is SHA256. Multiple fingerprints can be combined with a “|” delimiter in a single match attribute)
- Verify (mandatory server certificate verification. Mail is delivered only if the TLS handshake succeeds if the remote SMTP server certificate can be validated (not expired or revoked, and signed by a trusted certificate authority), and if the server certificate name matches the optional “match” attribute)
- Secure (secure-channel TLS. At this security level, DNS MX lookups, though potentially used to determine the candidate next-hop gateway IP addresses, are not trusted to be secure enough for TLS peer name verification. Instead, the default name verified in the server certificate is obtained directly from the next hop or is explicitly specified via the optional match attribute. The match attribute is most useful when multiple domains are supported by a common server, the policy entries for additional domains specify matching rules for the primary domain certificate. While transport table overrides routing the secondary domains to the primary next-hop also allow secure verification, they risk delivery to the wrong destination when domains change hands or are re-assigned to new gateways. With the “match” attribute approach, routing is not perturbed, and mail is deferred if verification of a new MX host fails)
- Attribute (specify an optional policy attribute)
Note: the digest algorithm used to calculate and verify certificates fingerprints is SHA256.