On 16/02/2021 10:28, Jeff Abrahamson wrote:
I have a client that's triggering these errors in my logs (and is
therefore unable to send even though he can read mail ok):
postfix/submission/smtpd[310140]: connect from [...]
postfix/submission/smtpd[310140]: SSL_accept error from [...]: -1
postfix/submission/smtpd[310140]: warning: TLS library problem:
error:14209102:SSL
routines:tls_early_post_process_client_hello:unsupported
protocol:../ssl/statem/statem_srvr.c:1685:
postfix/submission/smtpd[310140]: lost connection after STARTTLS
from 53.6.119.80.rev.sfr.net[80.119.6.53]
postfix/submission/smtpd[310140]: disconnect from [...] ehlo=1
starttls=0/1 commands=1/2
Searching on the error string isn't helping me particularly, and I'm
not sure how to discover what SSL version is being attempted. That he
can read mail suggests to me that it's not really an SSL version
issue, but I see that dovecot is not being as strict.
I'd like to do what I can to verify/understand and not just relax
constraints blindly.
On my server I've set this, which I thought was permissive enough but
not too much:
smtpd_tls_mandatory_protocols = SSLv3, TLSv1
Thanks for any pointers.
(Fwiw, the client is running thunderbird on Windows 10. Hopefully
that's not relevant.)
Those are terrible settings, probably the opposite of what you want. For
auth clients I have:
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
This refuses anything below TLSv1.2, and works fine with clients running
Thunderbird on Windows 10.
Thunderbird v78 disables TLSv1.0 and TLSv1.1 by default for good safety
reasons. This is almost certainly the reason for the errors you are
seeing - your server is trying to force the client to connect with
outdated protocols (SSLv3 or TLSv1) and the client refuses.
