Difference between revisions of "Maytls, maytlsclient, maytlsserver, musttls, musttlsclient, musttlsserver, notls, notlsclient, notlsserver, tlsswitchchannel Options"

From Messaging Server Technical Reference Wiki
Jump to: navigation, search
m (Bulk update)
m (Bulk update)
 
Line 8: Line 8:
 
Note that prior to 7.0.5, the  [[LMTP back end TCPIP channel#LMTP_back_end_TCPIP_channel|LMTP server]]  did not support TLS use; as of 7.0.5, the LMTP server does support TLS, configured via the same <code>maytls</code>, <code>maytlsserver</code>, <code>musttls</code>, <code>mustlsserver</code>, channel options used to configure SMTP server TLS support.   
 
Note that prior to 7.0.5, the  [[LMTP back end TCPIP channel#LMTP_back_end_TCPIP_channel|LMTP server]]  did not support TLS use; as of 7.0.5, the LMTP server does support TLS, configured via the same <code>maytls</code>, <code>maytlsserver</code>, <code>musttls</code>, <code>mustlsserver</code>, 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.  
+
The ManageSieve server only supports the server subset of the TLS options since there is no ManageSieve client.  
  
 
<code>notls</code>is the default, and means that STARTTLS will not be permitted or attempted. It subsumes the <code>notlsclient</code> 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 <code>notlsserver</code> 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).  
 
<code>notls</code>is the default, and means that STARTTLS will not be permitted or attempted. It subsumes the <code>notlsclient</code> 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 <code>notlsserver</code> 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).  

Latest revision as of 17:13, 13 February 2020


Transport Layer Security (maytls, maytlsclient, maytlsserver, musttls, musttlsclient, musttlsserver, notls, notlsclient, notlsserver, tlsswitchchannel)

The maytls, maytlsclient, maytlsserver, musttls, musttlsclient, musttlsserver, notls, notlsclient, notlsserver, and 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 maytls, maytlsserver, musttls, 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).

Specifying 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.

Specifying 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 musttls or 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.

The 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.


See also: