Hi Viktor, Is this on the roadmap for 3.4 or for a long-term roadmap?Just curious.Thanks for all the amazing work on Postfix. -M
From: Viktor Dukhovni <postfix-us...@dukhovni.org> To: Postfix users <email@example.com> Sent: Thursday, January 25, 2018 10:23 PM Subject: Re: SMTP SNI Support > On Jan 25, 2018, at 10:06 PM, MK <ph...@rogers.com> wrote: > > OpenSSL implementations (OpenSSL 0.9.8 mainly which is used in Debian 8 > and others of that era of a few years ago) can't handle a server with SNI > certificates and fails to connect. This is not an accurate description of the problem. The real problem is that the target server returned a warning alert when it could not find a matching certificate for the requested SNI name, instead of quietly returning a default certificate and not making a fuss. As I mentioned before, Postfix will not be so silly. Perhaps surprisingly, for once common sense also prevails in RFC6066: https://tools.ietf.org/html/rfc6066#section-3 The ServerNameList MUST NOT contain more than one name of the same name_type. If the server understood the ClientHello extension but does not recognize the server name, the server SHOULD take one of two actions: either abort the handshake by sending a fatal-level unrecognized_name(112) alert or continue the handshake. It is NOT RECOMMENDED to send a warning-level unrecognized_name(112) alert, because the client's behavior in response to warning-level alerts is unpredictable. If there is a mismatch between the server name used by the client application and the server name of the credential chosen by the server, this mismatch will become apparent when the client application performs the server endpoint identification, at which point the client application will have to decide whether to proceed with the communication. Going further back, the original specification, outdated by RFC6066, did recommend sending the alert: https://tools.ietf.org/html/rfc4366#section-3.1 If the server understood the client hello extension but does not recognize the server name, it SHOULD send an "unrecognized_name" alert (which MAY be fatal). This design error is likely the source of the problem. File bug reports against outdated server-side SNI implementations that follow the obsolete RFC4366. The RFC6066 behaviour is by far more sensible. > Incorrect openssl behaviour is noted here. debian exim4 for example would > fail to connect to the smtp server when sni was enabled among other random > servers on the net . They were rare, but our solution was to not have sni on > port 25 anyway and run it only on port 587, where clients typically have a > much faster upgrade cycle. For the most part servers were okay but those > linked with problematic versions didn’t like it. > > Tons of details and the particular patch here: > > https://rt.openssl.org/m/ticket/history?id=3038 Thanks for that. It clearly explains the interoperability failure. This will not be an issue for Postfix. -- Viktor.