(In reply to Magnus Melin [:mkmelin] from comment #8)
A valid certificate problem that occurs all the sudden (for a known host) should be very uncommon for mail, I'd assume (in comparison to web servers).
Common scenarios are:
- server certificate expired because it hasn't been renewed in time
- captive portal at a hotel
- MITM attempt at a WiFi hotspot
I guess the "new" behaviour would be that the connection just fails?
You mean silently fails? I think the user should get informed when a connection fails. And just saying "connection failed" doesn't help the user to investigate the cause. If we want users to understand what's going on, or to get help, they need to be able to learn about the details of the failure. That's what that listener is about. Today, we can get a push notification from the core SSL/TLS communication to the JS user interface, which includes all the interesting details. The intended change removes this convenience. Instead, Thunderbird must identify all code locations in which SSL/TLS connections are performed, and setup appropriate failure handling, that queries those details from the core SSL/TLS.
An alternative, and more general approach to poking around in the protocol implementations could be to have a trouble shooter to help you find the issue for connection issues. Part of that would be checking certificates.
IMHO that isn't simpler. You'd require a central place in Thunderbird that keeps track of all the various connections, and which is able to iterate over all of them. For some protocols, performing the SSL/TLS handshake requires knowledge of the protocol. For example, with all STARTTLS variants, it's necessary to start with a protocol specific plaintext handshake, and only afterwards, if the initial conversation with the server has reached a certain point, in which the server has shown its ability, the socket can switch to start the SSL/TLS protocol.
IMHO, if we don't get a callback, adding the error handling into the protocol code is necessary. We don't need individual user interaction for each protocol. Each protocol implementation only needs the code to check for the kind of connection failure, and if it's found to be related to a bad certificate, call common Thunderbird code that handles SSL/TLS errors.
OTOH, from a quick look we might be able to just add needed logic to nsMsgProtocol::OnStopRequest (and some slight adjustments)
Thanks for this hint, I'll have a look.