On 2018-04-20 at 19:16 -0400, Viktor Dukhovni via Exim-dev wrote:
> In Postfix we have a notion that is the "next-hop" domain,
> which is normally the envelope recipient domain, but when
> a smarthost (or domain whose MX records are used for routing)
> is specified, then the next-hop domain is the smarthost.
>
> This provides a "secure" name for TLS policy lookup, and is
> not subject to insecure DNS downgrades. This is available
> for peer name matching, and will also be available for
> client-side SNI when I get that implemented (shortly).
>
> Is there anything similar in Exim?
Yes: when you define a "smarthost" Router, you use "manualroute" as the
driver, and choose the Transport to go with it.
It's absolutely reasonable and normal in Exim to:
1. Have two similar Transports, referenced by different drivers (you can
use one with expansion options but that can increase complexity,
often it's most maintainable to have a clean separation)
2. Define a remote_smtp_smarthost Transport which just sets
"tls_sni = $host" in that case.
None of which is deriving an insecure value from DNS. But yes this does
complicate the issue of "default", since it's a minor layering violation.
I think then that, to minimize insecure configs, we should:
A. Set the default tls_sni to be $domain, accept the layering issue.
B. Update the default supplied Exim configuration to set tls_sni in the
smarthost example
C. Include a warning in README.UPDATING about the change and encouraging
people to make the change for smarthost configuration, explicitly
noting that this is a safe change to make before upgrading.
---------------------8< untested exim fragments >8----------------------
begin routers
smarthost:
driver = manualroute
domains = ! +local_domains
transport = remote_smtp_smarthost
route_data = smarthost.isp.example
no_more
begin transports
remote_smtp_smarthost:
driver = smtp
hosts_require_tls = *
tls_sni = $host
tls_require_ciphers = something:stronger:than:normal
---------------------8< untested exim fragments >8----------------------