Am 17.02.19 um 16:10 schrieb Wietse Venema:
> How do those 'other' connections differ from what is shown above?
I don't see differences. This tlsproxy process handled a connection to gmail,
outlook.com and some other destinations. All unverified because I did not
configure the matching root certificates.
Interesting: it also handled later an other connection to an other destination
that *could* be verified using DANE (verified connection established to ...)
> What I see is an SMTP client deferring delivery with a NEW TLS
> connection. That is different from your earlier report about a
> REUSED connection.
>
> Can you confirm that the SMTP client will not deliver to this
> destination with NEW and REUSED tlsproxy connections?
cannot check that without bothering the receiver with annoying test messages.
Will ask for permission...
> The error message suggests a problem in the certificate trust chain,
> like an unknown root certificate.
that's the point I started with subject "DANE issue..."
The destination don't need any certificate chains. The destination can be
validated using DANE.
> What is the output from:
>
> postconf -F smtp/unix/chroot tlsproxy/unix/chroot
smtp/unix/chroot = y
tlsproxy/unix/chroot = y
Andreas
