------- 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+exim@???> 2014-01-27 23:00:00 ---
Hi Jeremy,
Jeremy Harris <jgh146exb@???> (So 26 Jan 2014 21:31:31 CET):
> ------- You are receiving this mail because: -------
..
> --- Comment #6 from Jeremy Harris <jgh146exb@???> 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
