On 2012-04-15 at 21:13 +0100, Jeremy Harris wrote: > Anyone recall what happened to Steve Haslam's TLS patch from > ten years back? Introduced a tls_verify_hostname smtp transport option, > among other things - which has come up on my radar. > > Ref: http://www.exim.org/lurker/message/20020911.100440.23a73e82.ca.html
tls_verify_hostname seems to be accomplished via tls_verify_certificates, the documentation for which was updated a version or two back to be clearer about what's covered. That's OpenSSL-only, though, and the semantics for remote SMTP hostname verification are not well-defined. Do you verify the email domain, which is the only trusted information? One server can handle many domains. Or do you verify the hostname you talk to, derived from the email domain over untrusted DNS? Not without DNSSEC, unless you want the verification to be a charade: the point being to tie a server-presented identity to something *verifiably* linked to an identifier which was trusted/supplied by a human. Given a choice between presenting deceptive security or leaving things as they are, with "this is susceptible to MitM and there's no good solution yet", I prefer the latter; to change, we'd better have DNSSEC support in Exim first. $tls_peercn -- we have $tls_peerdn, is the difference merely that $tls_peercn extracts the correct field from the string? I suspect that we'd be better off with DN parse routines exposed as expansion operators (or items), which would help with LDAP too. TLS debugging: I'm all in favour of more detailed information in debug logs. -Phil -- ## List details at https://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/
