On 21 Jul 2015, at 09:49, A. Schulze <s...@andreasschulze.de> wrote: >> Should I remove "smtpd_tls_mandatory_exclude_ciphers = 3DES" >> and look how the cipher use change over the next days ? > > immediately after I removed "smtpd_tls_mandatory_exclude_ciphers = 3DES" > some servers fail to establish TLS. At least one was a Exchange 2010 Version > 14.03... > > :-)
I suspect this is a problem with either your configuration, or your TLS stack. Exchange 2010 should do better, even in it's default configuration, as the minimum OS stack is Windows Server 2008, which supports TLSv1 with the 'ECDHE-RSA-AES128-SHA' cipher if the relay server supports it. Review your cipher ordering, I'd say, and optimise for your client profile. To get an idea of what Windows Server 2008 supports out of the box, with a default Schannel configuration; https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=7&platform=Vista The same for Windows Server 2008 R2; https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=8-10&platform=Win%207 Note that neither supports DHE ciphers, only ECDHE, so if your TLS stack does not make these available, you're causing part of the problem :-) Schannel on 2008 R2 (possible 2008, don't have data) does support DHE GCM ciphers because they're in the default IE 11 profile; https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=11&platform=Win%207 But your stack might not support those. Check the output of 'openssl ciphers -v', with whatever cipher selection you use, Postfix default or otherwise? Alternatively, run cipherscan[1] against your submission port to get a clear picture of the active cipher set the Exchange SMTP client would see, for example; $ cipherscan -starttls smtp mail.example.com:587 The latter will give you the most accurate results. Mvg, Joni -- [1] https://github.com/jvehent/cipherscan