Maytls, maytlsclient, maytlsserver, musttls, musttlsclient, musttlsserver, notls, notlsclient, notlsserver, tlsswitchchannel Options

Transport Layer Security
The,  ,  ,  ,  ,  ,  ,  ,  , and   channel options are used to configure STARTTLS use for the various protocols supported by the MTA, including but not limited to SMTP, LMTP, and MTQP.

Note that prior to 7.0.5, the LMTP server  did not support TLS use; as of 7.0.5, the LMTP server does support TLS, configured via the same ,  ,  ,  , channel options used to configure SMTP server TLS support.

The ManageSieve server only supports the server subset of the TLS options since there is no ManageSieve client.

is the default, and means that STARTTLS will not be permitted or attempted. It subsumes the  channel option, which means that TLS use will not be attempted by the SMTP/LMTP/MTQP client on outgoing connections (the STARTTLS command will not be issued during outgoing connections) and the   channel option, which means that TLS use will not be permitted by the SMTP/LMTP/MTQP server on incoming connections (the STARTTLS extension will not be advertised by the SMTP/LMTP/MTQP server nor the command itself accepted).

Specifying  causes the MTA to offer TLS to incoming connections and to attempt TLS upon outgoing connections. It subsumes, which means that the SMTP/LMTP/MTQP client will attempt TLS use when sending outgoing messages, if sending to an SMTP/LMTP/MTQP server that supports TLS, and  , which means that the SMTP/LMTP/MTQP server will advertise support for the STARTTLS extension and will allow TLS use when receiving messages. Note that  settings mean that the MTA will want to use TLS with remote sides that support STARTTLS, while allowing remote sides that do not have STARTTLS support to communicate without TLS; but   settings do not inherently mean that the MTA will "fall back" to non-TLS use when TLS negotiation is attempted but fails: failure of TLS negotiation will result in that connection being closed as a failed connection (recorded with an "X" record). As of 8.0, with  set, the MTA&#x27;s client will attempt a new connection to attempt sending  without TLS in cases where the remote SMTP/LMTP server advertised TLS support but where the actual TLS negotiation failed; prior to 8.0, a failure in the TLS negotiation would immediately abort the delivery attempt for the message. This support is not available in MTQP.

Specifying  will cause the MTA to insist upon TLS in both outgoing and incoming connections; e-mail will not be exchanged with remote systems that fail to successfully negotiate TLS use. It subsumes, which means that the SMTP/LMTP client will insist on TLS use when sending outgoing messages and will not send to SMTP/LMTP servers that do not successfully negotiate TLS use (the MTA will issue the STARTTLS command and that command must succeed), and  , which means that the SMTP/LMTP server will advertise support for the STARTTLS extension and will insist upon TLS use when receiving incoming messages and will not accept messages from clients that do not successfully negotiate TLS use. When  or   is on a channel, then unless TLS has been successfully negotiated all MAIL FROM: attempts will be rejected with the error: 530 5.7.0 No STARTTLS command has been given. The  channel option is used to cause incoming connections to be switched to a specified channel upon a client&#x27;s successful TLS negotiation. (This includes either successful STARTTLS use on a "regular" port, or negotiating upon connection to a "dedicated to TLS" port, usually port 465, configured via the Dispatcher&#x27;s   option in Unified Configuration, or its TLS_PORT option in legacy configuration.)    takes a required value, specifying the channel to which to switch.

Note that TLS library initialization is performed for any SMTP/LMTP channel which has any TLS usage permitted (or required). In particular, TLS library initialization will be performed by the TCP client for a channel marked merely. (This overhead is normally fairly neglible.)

Note that these options affect only TLS use negotiated at the protocol level via STARTTLS; they do not affect potential TLS use triggered by connection to a port dedicated to TLS use such as with the   Dispatcher service option.

See also:
 * msexchange Option
 * ssl_ports Option
 * sslnicknames Option
 * TCPIP channels
 * LMTP back end TCPIP channel
 * TLS and SASL channel options
 * Channel options