------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1413 --- Comment #8 from Heiko Schlittermann <hs+e...@schlittermann.de> 2014-01-27 23:00:00 --- Hi Jeremy, Jeremy Harris <jgh146...@wizmail.org> (So 26 Jan 2014 21:31:31 CET): > ------- You are receiving this mail because: ------- .. > --- Comment #6 from Jeremy Harris <jgh146...@wizmail.org> 2014-01-26 > 20:31:30 --- > Is the patch still assumed operation? I've rebased it against 5a1b8443 and > run the testsuite past it without issue. now I installed exim 4.82 on my own systems and configured it as I wanted to do when I discovered the bug. begin transports smtp: driver = smtp … tls_verify_certificates = ${lookup{$host}dsearch{CERTS/$host-crt.pem}{CERTS/$value}fail} # probably better written as # ${if exists{CERTS/$host-crt.pem}{CERTS/$host-crt.pem}fail} And it *seems* to work as expected. If the expansion fails, we behave according to the docs (as if the option was not set). If the expansion succeeds, we send the mail encrypted or unencrypted, depending on the result of the verification. I'll give you some more information by the end of this week. (This generates another issue: wouldn't it be better to use encryption anyway, even if the verification fails and hosts_require_tls is unset? Some security is better than no security at all. And we do not have any security, because we fall back to unecrypted connections, if the tls_verify_certificates expands but the verification fails. Or did I miss the point?) Best regards from Dresden/Germany Viele Grüße aus Dresden Heiko Schlittermann -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##