> On Apr 20, 2018, at 7:41 PM, Phil Pennock <pdp@???> wrote:
>
> 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.
Question about this "$host". Are smarthost settings ever subject to
MX lookups, so that the actual remote SMTP server is one of the MX
hosts of the smarthost domain?
In both Sendmail and Postfix, when the relayhost is not enclosed in
"[]", the SMTP server used is obtained indirectly via MX lookups,
but when the relayhost is enclosed in "[]" then that's the verbatim
SMTP server to use. In either case the "next-hop" domain is the
specified relayhost (before any MX lookup).
The plan for client-side SNI support in Postfix is to allow global
settings of the form:
smtp_tls_server_name = <empty> | "next-hop" | "hostname" | <some.fqdn>
where <empty> (the default) leaves SNI disabled, while "next-hop" and
"hostname" are respectively the next-hop domain and MX hostname.
Per-destination settings would have a similar keyword in the TLS policy table.
If there's a sound way to do something similar, IMHO that's about the
right approach, with the user choosing no-SNI, a literal value or
whatever the next-hop domain is (recipient domain or smarthost when
applicable) or the MX host when that's the right value.
Note that insecure choices of SNI are not disasterous, it's just the
hint you send to the remote server, you're still validating the cert
you get based on whatever the policy is for that.
Of course I'm entirely unfamiliar with how context is managed in Exim,
and what's available in expansions and when, so perhaps there's not
an easy way to expose the original smarthost name as "next-hop" and
have that be the envelope recipient domain otherwise.
--
Viktor.
