Maytls, maytlsclient, maytlsserver, musttls, musttlsclient, musttlsserver, notls, notlsclient, notlsserver, tlsswitchchannel Options
Transport Layer Security (
tlsswitchchannel 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
mustlsserver, 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.
notlsis the default, and means that STARTTLS will not be permitted or attempted. It subsumes the
notlsclient 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
notlsserver 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).
maytls causes the MTA to offer TLS to incoming connections and to attempt TLS upon outgoing connections. It subsumes
maytlsclient, 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
maytlsserver, 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
maytls* 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
maytls* 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
maytlsclient set, the MTA'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.
musttls 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
musttlsclient, 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
musttlsserver, 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
musttlsserver 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.
tlsswitchchannel channel option is used to cause incoming connections to be switched to a specified channel upon a client'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's
ssl_ports option in Unified Configuration, or its TLS_PORT option in legacy configuration.)
tlsswitchchannel 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
maytlsserver. (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
ssl_ports Dispatcher service option.