Self-followup to correct an omission.
On 2008-06-20 at 20:46 -0700, Phil Pennock wrote:
> begin transports
> smarthost_smtp:
> driver = smtp
> port = ${extract{port}{$address_data}{$value}{\
> ${extract{submission}{$address_data}{587}{25}}\
> }}
> hosts_require_tls = ${extract{tls}{$address_data}{*}{+tls_required_to}}
> hosts_require_auth = ${extract{user}{$address_data}{*}{+authenticate_required_to}}
> helo_data = ${extract{helo}{$address_data}{$value}{MYHELO_TO_SMARTHOST}}
In answering a mail from M G Berberich, I realised that I wasn't setting
any client-side server verification in my own laptop configuration.
To do verification (ie, make the TLS worthwhile) you need a collection
of the CA certificates which signed the certificates that you care about
(or signed intermediate CAs, etc). For GnuTLS, these need to be all in
one file, for OpenSSL they can either be in a file or in a directory
(which has the hash->certificate symlinks typically generated by
c_rehash). For me, using OpenSSL, this means /etc/ssl/certs/ which has
the usual CAs and my own private CA.
What I've chosen to do is to require verification on smarthost_smtp but
not on remote_smtp. So direct-to-arbitrary hosts have no more
protection than they ever had, against someone who can hijack a TCP
session or fake DNS, but do have protection against passive
eavesdropping.
For connections to smarthosts, there is assumed to be a trust
relationship present, and the list of smarthosts is small enough that I
can verify that I have the certificates required. So suddenly there's
more security for outbound email in the usual case.
So this is added to smarthost_smtp above:
# For an explicitly configured smarthost, where we've configured tls, it's
# reasonable to require that we have the TLS certs for verification, too.
tls_verify_certificates = ${extract{tls}{$address_data}{/etc/ssl/certs}{}}
Oh, note also that the use of submission=yes and tls=yes in the
smarthosts file is perhaps misleading. What matters is that
'submission' or 'tls' be present, at all. tls=no will be treated the
same as tls=yes. The only way around this would be to make the
expansion string much more complicated.
You can replace =yes with ="" if that helps keep it clearer that
presence is what matters, not the value.
A full-fledged feature offering, rather than a private use thing, would
allow tls=no to actively disable even trying TLS, since not specifying
tls at all in this smarthosts config just means that TLS is not
required, not that it will not be used. This is left as an exercise to
the reader.
-Phil
