Am 17.02.19 um 21:24 schrieb Viktor Dukhovni:
Hello Viktor,
> If you performed a "reload" to get that to take effect, that would
> also have flushed the TLS session cache. And perhaps disabling
> connection re-use is a distraction. It may well have been sufficient
> to just "postfix reload".
no, also "postfix stop; postfix start; postfix flush" (it's a low volume system
with only this message in the deferred queue) did not deliver the message.
but "smtp_tls_connection_reuse = no" did.
> This is more interesting. What OpenSSL version is your Postfix
> linked with?
a self-compiled openssl-1.1.1a (using a shlib_variant like you show me some
years ago)
> Please post the outputs of "postconf -nf" and "postconf -Mf", and
> information about the OpenSSL version, checking "ldd" to make sure
> you're reporting the version of the correct library.
https://andreasschulze.de/tmp/postconf_nf.txt
https://andreasschulze.de/tmp/postconf_Mf.txt
https://andreasschulze.de/tmp/ldd_smtp.txt
> If you re-enable use of the proxy, does the problem come back?
yes
> You don't need to send messages that reach the recipient. You can
> send "delivery probes" via:
>
> sendmail -f your-address -bv recipient-address
>
> These drop the connection after "RCPT TO", without delivering a message.
ok, so I start silent testing ...
https://andreasschulze.de/tmp/reuse_on.txt
https://andreasschulze.de/tmp/reuse_off.txt
> We might temporarily need to raise the TLS loglevel to 2 in the
> proxy just before sending a delivery probe. It should then be
> possible to see more of the TLS handshake details.
tests above run with "smtp_tls_loglevel = 2"
>>> postconf -F smtp/unix/chroot tlsproxy/unix/chroot
>> smtp/unix/chroot = y
>> tlsproxy/unix/chroot = y
>
> You should make sure your DNS is correctly configured in the chroot
> jail. Are any of the upstream resolvers perhaps not configured to
> do DNSSEC?
only one DNS resolver (@::1) is also configured inside the chroot jail.
Andreas
