You can require that
TLS is enabled for email delivery to specific domains using the Destination
Controls page or the
In addition to TLS,
you can require that the domain’s server certificate is verified. This domain
verification is based on a digital certificate used to establish the domain’s
credentials. The validation process involves two validation requirements:
- The chain of issuer
certificates for the SMTP session ends in a certificate issued by a trusted
certificate authority (CA)
The Common Name
(CN) listed on the certificate matches either the receiving machine's DNS name
or the message's destination domain.
destination domain matches one of the DNS names in the certificate's Subject
Alternative Name (subjectAltName) extension, as described in RFC 2459. The
matching supports wildcards as described in section 3.1 of RFC 2818.
A trusted CA is a
third-party organization or company that issues digital certificates used to
verify identity and distributes public keys. This provides an additional level
of assurance that the certificate is issued by a valid and trusted identity.
You can configure
your Email Security appliance to send messages to a domain over a TLS
connection as an alternative to envelope encryption. See the “Cisco Email
Encryption” chapter for more information.
You can specify a
certificate for the appliance to use for all outgoing TLS connections. To
specify the certificate, click
Settings on the Destination Controls page or use
destconfig -> setup in the CLI. The certificate is a
global setting, not a per-domain setting.
You can specify 5
different settings for TLS for a given domain when you include a domain using
the Destination Controls page or the
destconfig command. In addition to specifying whether
exchanges with a domain are required or preferred to be TLS encoded, you can
dictate whether validation of the domain is necessary. See the following table
for an explanation of the settings:
Table 1 TLS Settings for
TLS setting set using the Destination Controls page or the
destconfig -> default subcommand used for
outgoing connections from the listener to the MTA for the domain.
“Default” is set if you answer “no” to the question: “Do you wish to apply a
specific TLS setting for this domain?”
TLS is not
negotiated for outgoing connections from the interface to the MTA for the
negotiated from the Email Security appliance interface to the MTA(s) for the
domain. However, if the TLS negotiation fails (prior to receiving a 220
response), the SMTP transaction will continue “in the clear” (not encrypted).
No attempt is made to verify if the certificate originates from a trusted
certificate authority. If an error occurs after the 220 response is received
the SMTP transaction does not fall back to clear text.
negotiated from the Email Security appliance interface to MTA(s) for the
domain. No attempt is made to verify the domain’s certificate. If the
negotiation fails, no email is sent through the connection. If the negotiation
succeeds, the mail is delivered via an encrypted session.
negotiated from the Email Security appliance to the MTA(s) for the domain. The
appliance attempts to verify the domain’s certificate.
outcomes are possible:
- TLS is negotiated and the
certificate is verified. The mail is delivered via an encrypted session.
- TLS is negotiated, but the
certificate is not verified. The mail is delivered via an encrypted session.
- No TLS connection is made
and, subsequently the certificate is not verified. The email message is
delivered in plain text.
If there is no
specific entry for a given recipient domain in the good neighbor table, or if
there is a specific entry but there is no specific TLS setting for the entry,
then the behavior is whatever is set using the Destination Controls page or the
destconfig -> default subcommand (“No,” “Preferred,”
“Required,” “Preferred (Verify),” or “Required (Verify)”).