On Wed, Dec 04, 2024 at 12:13:13PM +1300, Tim Harman via Postfix-users wrote:
> FIXED!!!!
>
> smtpd_tls_session_cache_timeout = 0
This is very odd, because:
- Session tickets are either successfuly decrypted or not.
- If yes, the TLS handshake proceeds more quickly, and
the client can detect the fact that the handshake was abbreviated
(session resumed), if it cares to check.
- If not, the server ignores the client's ticket, and performs a
full handshake.
Regardless, the TLS handshake was actually completing, and the client
even sent a second SMTP EHLO. So it is **very** surpising that at
that point the client suddently decides it does not like the TLS
session it got.
> This is instantly resolved the issue
>
> Previously I had smtpd_tls_session_cache_timeout = 604800
>
> I noted that turning this to 0 also disabled session tickets, and I'd read
> this: https://github.com/mjl-/mox/issues/237 (After searching MailOp)
This seemed to be about TLS handshake failures, not connection loss
after a successful handshake... Did I misunderstand?
> So there must be something going on in the version of Debian I have (10)
> where TLS session tickets aren't working/negotiated/stored correctly.
No, that's unlikely. I am curious whether you also had a (stateful
resumption) server-side session cache configured, or just the timeout
(tickets only)?
The duration you were going with was needlessly high, no client should
be holding on to your tickets that long. Is there more detail anywhere
that you found explaining how/why MSFT email servers (mis)handle tickets?
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
