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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/