On 10/13/2011 6:39 PM, Simon Brereton wrote: > smtp_tls_CAfile = ? > smtp_tls_cert_file = ? > smtp_tls_key_file = ?
Typcially these would be set to the same cert & keys as used by smtpd. >> Not needed, you neither ask for nor verify client certs. > > Should I be? And if so, how do I do that? Bearing in mind, I think > I'd only want to verify them if they are actually used. With opportunistic TLS there is no need to verify client certificates -- you're willing to accept an unencrypted connection, so it doesn't matter if an encrypted connection uses an invalid certificate. Also, some clients choke on a certificate request, so it improves interoperability to just ignore them. The only time you care about the client certificate if if you are setting up a "secure" channel with another server that requires verified TLS. This is not needed with a general-purpose MX. > > But the errors in my log are down and so for now I can live with it > unless anyone has anything more to add. The problem with TLS/SSL is > one always has the horrible suspicion one has left a gaping back-door > open... As a general rule, you shouldn't care very much. TLS generally either works (noted in the log with tls_loglevel=1), or doesn't work (no mail is transferred), or isn't used (noted in the log by an absence of TLS logging at tls_loglevel=1). Since this is opportunistic use-it-if-you-can-but-not-required TLS, on a very basic level it doesn't matter if it's used or not, which is why tls_loglevel default is 0. The only place you should really care about encryption is if your own clients submit SASL authenticated mail -- the far most common auth mechanisms are PLAIN and LOGIN which really should be protected inside a TLS connection. This is commonly controlled by using "smtpd_tls_auth_only = yes", and if you use the recommended submission port, setting '-o smtpd_enforce_tls=yes' on the submission entry in master.cf. In these cases, if TLS isn't used or doesn't work, the client can't transfer mail. -- Noel Jones
