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 older --client-- openssl versions which we saw remote machines on the internet connecting as. 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=3038User: guest / Pass: guest
Sent from Yahoo Mail for iPhone On Thursday, January 25, 2018, 9:43 PM, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote: > On Jan 25, 2018, at 9:30 PM, MK <ph...@rogers.com> wrote: > > I’d request considering allowing the SNI to be enabled per port. Each port gets its own entry in master.cf, so you will certainly be able to enable or disable SNI support for a given TCP endpoint. > While using it in production we found a very small number (<1%) of mail > servers > sending to our server didn’t like SNI- likely ancient mail servers. This is rather intriguing... How would they even know you had SNI? The effect of SNI is present a certificate selected on the basis of the supplied hostname hint. Otherwise, everything looks exactly the same, so it is hard to imagine how said servers "didn't like" SNI. Perhaps your server responded to some unexpected SNI names by aborting the TLS handshake? Postfix won't do that. For SNI names that don't have a matching configuration, Postfix will respond with a default certificate, it'll be up to the client to either accept that or not. -- Viktor.
