On Sat, Oct 15, 2022 at 08:31:58PM +0200, Gerald Galster wrote:
> > The most likely issue is a Windows regression with zero length session
> > ids. I don't think there's anything that can be done here, the client
> > indicates support for session tickets, and since OpenSSL is then going
> > to issue a ticket, it does not assign a session id even with the default
> > setting (which you probably did not change):
> >
> >
> > https://www.postfix.org/postconf.5.html#smtpd_tls_always_issue_session_ids
> >
> > smtpd_tls_always_issue_session_ids = yes
>
> True, I did not set or change it and the default is "yes" here.
>
> For the time being I'll disable session tickets (at least) for submission.
> The performance impact is negligible in my case.
>
> Thanks for having a look!
You're welcome. If you have a Microsoft support contract, you should
ideally file a bug report and refer to:
https://datatracker.ietf.org/doc/html/rfc5077#section-3.4
to note that the server behaviour (sending an empty session id when
issuing session tickets) is correct and expected. If Outlook is not
prepared to handle empty session ids, it should not enable session
tickets.
Are you on the latest version of "Office"?
Perhaps what happened in the Windows update is that session tickets got
enabled by default, behind Outlook's back as it were. It is also
possible that a newer version of Outlook handles this correctly.
One more PCAP file could shed light on this hypothesis. This would be
with tickets enabled on the server, and the client using "pre-update"
Windows.
--
Viktor.
