Environment: DirectAdmin with CustomBuild, Exim built from the shipped exim.conf template, version 4.5.63.
The problem is one line that is not there.
In the official template the remote_smtp transport sets:
tls_verify_cert_hostnames = *
but it never sets tls_sni. Without SNI, a receiving host that serves several domains behind one IP answers with its default certificate. The name on that certificate does not match the host Exim is delivering to, the hostname verification fails, and Exim logs the delivery with CV=no. Delivery still happens, but the TLS session is effectively unverified, and that is what ends up in the logs and in any report built from them.
Measured on one of our servers over a 24 hour window:
Before adding tls_sni = $host to remote_smtp: 758 deliveries logged with CV=no.
After: 1711 deliveries with CV=yes against 5 with CV=no.
The remaining 5 are genuinely misconfigured remote hosts, which is the expected result.
Two notes for anyone hitting the same thing:
exim.variables.conf.custom takes variables only. A transport option cannot be added there, so the fix requires a full custom exim.conf under custombuild/custom/exim/, which then has to be kept in sync with every vendor template release by hand. Our copy sits at 4.5.63 while 4.5.69 is already out.
Request: please add
tls_sni = $host
to the remote_smtp transport in the official exim.conf template. It is a one line change, it is what the matching tls_verify_cert_hostnames setting already implies, and it removes the need for every affected admin to fork the whole template over it.
The problem is one line that is not there.
In the official template the remote_smtp transport sets:
tls_verify_cert_hostnames = *
but it never sets tls_sni. Without SNI, a receiving host that serves several domains behind one IP answers with its default certificate. The name on that certificate does not match the host Exim is delivering to, the hostname verification fails, and Exim logs the delivery with CV=no. Delivery still happens, but the TLS session is effectively unverified, and that is what ends up in the logs and in any report built from them.
Measured on one of our servers over a 24 hour window:
Before adding tls_sni = $host to remote_smtp: 758 deliveries logged with CV=no.
After: 1711 deliveries with CV=yes against 5 with CV=no.
The remaining 5 are genuinely misconfigured remote hosts, which is the expected result.
Two notes for anyone hitting the same thing:
exim.variables.conf.custom takes variables only. A transport option cannot be added there, so the fix requires a full custom exim.conf under custombuild/custom/exim/, which then has to be kept in sync with every vendor template release by hand. Our copy sits at 4.5.63 while 4.5.69 is already out.
Request: please add
tls_sni = $host
to the remote_smtp transport in the official exim.conf template. It is a one line change, it is what the matching tls_verify_cert_hostnames setting already implies, and it removes the need for every affected admin to fork the whole template over it.