Thanks Joerg for the response. I eventually did the same. Great backward compatibility is maintained.

 At that time the mails just dropped all of a sudden.and didn't have time to test any upgrades in my working config.

Update to v4.8 solved it.

 Thanks Thomas but I'll have to try the Apache OpenSSL DLLs in a test environment over the weekend. 

Hi,

Don't know whether it's interesting for David and his supporting programmers. I've just read the following article with HEISE.de, a german security news page: IETF will alte TLS-Versionen verbieten (unfortunately in german). But they've linked to following english page: TLS-OldVersions-diediedie.

Is Mercury using already the newer standards? I remember different discussions where users asked for new SSL standards for Mercury ...

Kein Problem [:D]

22:25:00.367: --- 13 Jun 2018, 22:25:00.367 ---
22:25:00.367: Connect to '81.169.145.97', timeout 60 seconds.
22:25:01.368: >> 220 smtpin.rzone.de ESMTP RZmta 43.10 ready (mi19)<cr><lf>
22:25:01.368: << EHLO mail.?????.net<cr><lf>
22:25:01.384: >> 250-smtpin.rzone.de greets 80.153.123.24<cr><lf>
22:25:01.384: >> 250-ENHANCEDSTATUSCODES<cr><lf>
22:25:01.384: >> 250-PIPELINING<cr><lf>
22:25:01.385: >> 250-8BITMIME<cr><lf>
22:25:01.385: >> 250-DELIVERBY<cr><lf>
22:25:01.385: >> 250-SIZE 104857600<cr><lf>
22:25:01.385: >> 250-STARTTLS<cr><lf>
22:25:01.385: >> 250 HELP<cr><lf>
22:25:01.385: << STARTTLS<cr><lf>
22:25:01.401: >> 220 Ready to start TLS<cr><lf>
22:25:01.492: ... SSL/TLS session established
22:25:01.492: ... ECDHE-RSA-AES256-GCM-SHA384, TLSv1.2, Kx=ECDH, Au=RSA, Enc=AESGCM(256), Mac=AEAD<lf>
22:25:01.492: ... Peer's certificate name is '/C=DE/O=Strato AG/OU=Rechenzentrum/ST=Berlin/L=Berlin/CN=smtpin.rzone.de'.
 

Other direction:

22:25:46.061: --- 13 Jun 2018, 22:25:46.061 ---
22:25:46.062: Accepted connection from '212.227.15.19', timeout 30 seconds.
22:25:46.063: Connection from 212.227.15.19, Wed Jun 13 22:25:46 2018<lf>
22:25:46.064: << 220-mail.?????.net ESMTP server ready.<cr><lf>
22:25:46.080: >> EHLO mout.gmx.net<cr><lf>
22:25:46.084: << 250-mail.?????.net Hello mout.gmx.net; ESMTPs are:<cr><lf>250-TIME<cr><lf>
22:25:46.085: << 250-SIZE 41943040<cr><lf>
22:25:46.085: << 250-AUTH CRAM-MD5 LOGIN<cr><lf>
22:25:46.085: << 250-AUTH=LOGIN<cr><lf>
22:25:46.085: << 250-STARTTLS<cr><lf>
22:25:46.085: << 250 HELP<cr><lf>
22:25:46.165: >> STARTTLS<cr><lf>
22:25:46.166: << 220 OK, begin SSL/TLS negotiation now.<cr><lf>
22:25:46.239: ... SSL/TLS session established
22:25:46.239: ... AES128-GCM-SHA256, TLSv1.2, Kx=RSA, Au=RSA, Enc=AESGCM(128), Mac=AEAD<lf>
22:25:46.240: ... No peer certificate presented.
 

Thanks, Thomas.

Gruss von der Ostsee 

Hi Thomas,

I am currently using Mercury Mail V 4.62 that was shipped with xampp.

Currently, mail provider has deprecated TLSv1.0 due to which handshake fails.

Is there a quick fix to enable TLS v1.1 atleast?

I checked the ini file but I don't see any option.

Thanks. 

Hi travick,

Why you don't update to Mercury v4.8 which will update the SSL libraries as well to v1.2 as Thomas wrote? The update is recognizing a former installation and will keep all settings.

[quote user="travick"]Currently, mail provider has deprecated TLSv1.0 due to which handshake fails.

Is there a quick fix to enable TLS v1.1 atleast?

I checked the ini file but I don't see any option.

[/quote]

I use the latest

OpenSSL DLLs from the Apache Project (www.apachelounge.com) in Mercury v4.80,

because I think the Mercury v4.80 OpenSSL DLLs are completely outdated and

safety-critical.

It may be that the Apache OpenSSL DLLs behave differently during the handshake