I installed stunnel (SSL encryption wrapper, as discussed earlier in this forum) in front of Mercury. It installs as a service and is working pretty fine. While Mercury operates unencrypted for both send and receive, the encryption is done by stunnel, using TLSv1.2

Be careful with your port assignment. While the clients use 110 (POP3), 143 (IMAP) and 25 (SMTP) to connect to Mercury, I chose 109 and 587 for Mercury -> stunnel connection, just to avoid double usage on my Mercury host.

After 12 years of using Mercury 32, today it started giving me the above error.  About 100 emails queued and I can't get them out.  I'm using MecuryC and I just can't get that to send out emails anymore, even when I try a different outgoing server.  I checked with my ISP and they could see a login, but no emails were sent.

What do I need to do to get this working again and how can I rescue the queued messages?

Ron Castro

Turn on session logging to find out what the real problem is.

Good idea!  I did that and when I turned on MercuryC I found that the POP login was fine, but then I got the following:

 08:31:33.234: --- Thu Oct 16 08:31:33 2014 ---
08:31:33.234: Connect to 'mail.sonic.net', timeout 30.
08:31:35.453: 22: Error -32 activating SSL session (locus 6014, type 4, code 0, 'Bad server key agreement parameter signature')
08:31:35.453: --- Connection closed normally at Thu Oct 16 08:31:35 2014. ---
08:31:35.453:

 What does 'Bad server key agreement parameter signature' mean and how do I fix that?

I think I found the problem, although I'm still confused about why it happened.  I reverted to the ancient port 25 for outgoing email, dumped SSL on the SMTP and all the backed up emails in the queue started sending.  I assume something changed at the ISP that caused SSL to no longer work?

Most likely your ISP updated their SSL software to a version that no longer is compatible with the encryption library used in Mercury 4.74. V4.80 will be using OpenSSL that should work with all current SSL libraries.

Any idea on when 4.80 will be available?

[quote user="Ronc"]Any idea on when 4.80 will be available?
[/quote]

It has been in beta for some time but there are still some issues to be sorted.

I would like to join the discussion as it seems we have the very same problem.

We had permanant Mercury crashes since last Tuesday. I was out of the office, and troubleshooting by phone did not help.

Today, back in the office I found that Mercury crashes every time when MercuryD POP3 client tries to connect to our ISP. Session logging says:

08:55:38.562: --- Fri Nov 28 08:55:38 2014 ---
08:55:38.562: Connect to 'sslmailpool.ispgateway.de:995', timeout 30.
08:55:38.750: 22: Error -32 activating SSL session (locus 6014, type 4, code 0, 'Bad server key agreement parameter signature')
08:55:38.750: --- Connection closed normally at Fri Nov 28 08:55:38 2014. ---
08:55:38.750:

We turned to SSL about a year ago without problem. I am still in discussion with our ISP if they did change anything this week...

I went back to unencrypted now and it works. However I would like to use SSL in future.

 Regards,

Bernward

Since I run on unencrypted POP3 email downloading, I also receive Mercury notifications first time ever [H]

This because I opened port 110 on the firewall.

The answer from my ISP is the recommendation to use TLS. I tried both MercuryD settings "SSL encryption using direct connection" and "SSL encryption using STLS command" but both did not work.

However MercuryC SMTP client (for sending mails) works fine with SSL encryption.

Regards,

Bernward

[quote user="bmpan"]The answer from my ISP is the recommendation to use TLS. I tried both MercuryD settings "SSL encryption using direct connection" and "SSL encryption using STLS command" but both did not work.

However MercuryC SMTP client (for sending mails) works fine with SSL encryption.[/quote]

MercuryC with SSL will work only for the next time. More and more servers deactivate SSL and switch to TLS only. We can only hope that David releases the long awaited Mercury32 version 4.80 or 5.0 until the final switch to TLS is done...