Hi John! This setting was moved into the domain level with the implementation of SSL/SNI support from within SmarterMail. You'll find it in the domain's settings on the Options page in the Security card now. We also identified an issue with this bypass setting that will be resolved in our upcoming release so keep an eye out for that!

Thanks, but sort of.

OK, so I found the setting and it was disabled. So if it is disabled, why is SmarterMail attempting to send with STARTTLS>

AND is on a gateway implementation.

OK, interesting observation. I had emails backing up in the the "waiting to deliver" so I did some testing. This is what I found:

If "Enable TLS if supported by the remote server" is NOT ENABLED, attempting to send to an email server that has a certificate problem FAILS no matter what the SMTP OUT protocol setting "Bypass certificate validation checks" is set to. 

HOWEVER, If "Enable TLS if supported by the remote server' IS ENABLED, then IF "Bypass certificate validation checks" is sent to ENABLED, then if the remote server does not have a valid certificate such as expired, then the email delivery continues per the bypass setting.

We learned today that TLS 1.3 is not supported by Windows Server 2019.  The OS downgrades the connection to TLS 1.2.

Only Server 2022 and higher supports TLS 1.3 as you’ve found out.

With .NET 8 for SmarterMail plus TLS 1.3, I would think it is wise for us to migrate to Windows Server 2022.