Thanks for the great Hermes patch for Eudora. We're currently using it with office365 e-mail and POP is working well with TLS v1.2. Unfortunately Microsoft has begun deprecating TLS v1/1.1 over the past few weeks and we're having issues with SMTP. No matter what settings I choose, e-mails are still being sent with TLSv1 (image attached). This causes the server connection to fail until we hit a server that hasn't been "upgraded" to remove TLSv1/1.1 capability yet. Changing to port 465, which I don't believe is supported by smtp.office365.com, leads to a timeout.
Right now we're able to limp by because a few of office365's many SMTP servers are still working with TLS v1/v1.1 so we can keep trying to resend over and over until we hit one that works, but that's taking longer and longer as they "upgrade" more servers so I'm afraid eventually we'll be completely out of luck.
All that said, is there any way to force Eudora/Hermes to send e-mails with TLS v1.2? I feel like I'm missing something simple.
There is a way to force a Hermes-updated Eudora to send with TLS
1.2. However it is rather complicated and I can offer a better
solution in the form of an updated version of the Hermes QCSSL DLL with
an enhancement to handle this particular difficulty.
Drop the three DLLs in this zip into your Eudora directory to replace
the existing ones (while Eudora is not running). Make sure that
your Office 365 persona is configured for "Required STARTTLS"
for both sending and receiving and all should be well. This is very
new and not widely tested but it works very reliably for me.
This enhancement works by detecting a persona's use of the Office 365
servers and overriding the default configuration with a configuration
made especially for Office 365 -- in particular forcing TLS 1.2 for both
sending and receiving. Only QCSSL.dll has actually changed; the
other two DLLs are the same as in the original Hermes package.
Pete Maclean
At 03:44 PM 1/25/2022, Chris Kilroy wrote:
Hi,
Thanks for the great Hermes patch for Eudora. We're currently using it
with office365 e-mail and POP is working well with TLS v1.2.
Unfortunately Microsoft has begun deprecating TLS v1/1.1 over the past
few weeks and we're having issues with SMTP. No matter what settings I
choose, e-mails are still being sent with TLSv1 (image attached). This
causes the server connection to fail until we hit a server that hasn't
been "upgraded" to lose TLSv1/1.1 yet. Changing to port 465,
which isn't supported by smtp.office365.com, leads to a timeout.
Right now we're able to limp by because a few of office365's many SMTP
servers are still working with TLS v1/v1.1 so we can keep trying to
resend over and over until we hit one that works, but that's taking
longer and longer as they "upgrade" more servers so I'm afraid
eventually we'll be completely out of luck.
All that said, is there any way to force Eudora/Hermes to send e-mails
with TLS v1.2? I feel like I'm missing something simple.
This solution worked for me on Windows 7 and Windows 10 with Godaddy's Exchange Office365 smtp/pop server. I did though have to install the Hermes Eudora 7 edition, as our old Eudora 6 would not work with this solution.
Thanks again!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Needed this update for Xfinity/Comcast as they are requiring TLSv1.2 as of April 17, 2023.. Made the update along with the ini changes and sent them a test email, reply came back with success reporting the connection was using TLSv1.2 ! Thanks for your work on this!
Bill
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Pete, adding my thanks to your updated DLL. I had spent hours trying to get it to work prior.
The outgoing messages now send every time with TLSv1.2. However, with the updated DLL I'm getting a separate issue on receiving.
When I check mail, I get the "server SSL rejected" certificate error. I then agree to trust the error in future sessions. This may repeat a few times as I keep hitting different servers. At some point I get the status line error "SSL Negotiation failed, Certificate bad, destination host name does not match but ignoring this error because certificate is trusted. The connection with the server has been lost cause 206"
If I then check the last SSL, it shows failed because of a bad cert, but repeats the message about 'ignoring this error because cert is trusted". The Cert info mgr shows the skull and crossbones. I add the cert to trusted.
I've been keeping track of which servers/certs get rejected, I'm up to over 50.
Every 5th or 6th attempt works, even though the notes in the SSL popup still show the cert error is being ignored (without an accompanying status error). In other words, sometimes I can check mail and sometimes not, even with the exact same situation (certs forced trusted).
I'm over my head and don't know if this is related in some way to the updated DLL files and which ones.
Any help would be appreciated.
Many thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will look into this but it may take me a few days as I am
rather overloaded at present.
Pete
At 11:42 PM 2/15/2022, B. Beor wrote:
Pete, adding my thanks to your
updated DLL. I had spent hours trying to get it to work prior.
The outgoing messages now send every time with TLSv1.2. However, with the
updated DLL I'm getting a separate issue on receiving.
When I check mail, I get the "server SSL rejected" certificate
error. I then agree to trust the error in future sessions. This may
repeat a few times as I keep hitting different servers. At some point I
get the status line error "SSL Negotiation failed, Certificate bad,
destination host name does not match but ignoring this error because
certificate is trusted. The connection with the server has been lost
cause 206"
If I then check the last SSL, it shows failed because of a bad cert, but
repeats the message about 'ignoring this error because cert is
trusted". The Cert info mgr shows the skull and crossbones. I add
the cert to trusted.
I've been keeping track of which servers/certs get rejected, I'm up to
over 50.
Every 5th or 6th attempt works, even though the notes in the SSL popup
still show the cert error is being ignored (without an accompanying
status error). In other words, sometimes I can check mail and sometimes
not, even with the exact same situation (certs forced trusted).
I'm over my head and don't know if this is related in some way to the
updated DLL files and which ones.
I am busy trying to reproduce this behaviour (so far without success) and studying the relevant code. I am no expert with certificates but may be able to figure it out.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am not making much progress with what I have. Would you please grab my latest update of Hermes QCSSL from https://www.maclean.com/downloads/QCSSL_Update.zip and install it. Read the release notes and make sure that it is creating a log file. Then try some connections until one fails and then send me the log file. That should give me more to work with.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Pete,
I was trying to figure this out myself so you wouldn't have to waste time. I didn't have too much luck, I'm just not knowledgeable.
On the receiving side: if I have a certificate fail and "add to trusted", I see how the certificate shows up in the 'trusted' list and in the usercerts.p7b, so I think that part is okay.
I wasn't having this problem before using the patch, which is why I considered the problem was related to the patch, but of course it could be coincidental.
I've attached a recent log file. As you can see, the SSL/TLS handshake fails when a bad certificate is found, even if it is 'ignoring this error because certificate is trusted'. Yet every so often, the handshake succeeds.
Let me know if there's anything else I can provide.
Separately, I appreciate all you have done to make the patches available. Do you have a way to accept donations?
p.s: I did see this in an old forum and have no idea whether is applicable.:
these are the steps that have worked for me - your mileage may vary a tad.
optionally, move the usercerts.p7b in your eudora directory to somewhere else
as many have said, go to the cert through personalities, drill down to the
skull icon, or the smiley face icon and hit accept.
but here's the twist - the actual cert for the mail server wasn't shown until i installed the top level certs. (installing just the root certs doesn't help...it's the cert from your mail server that you need)
export the skull icon cert in windows (this cert must be the one issued to your mail provider for that server / set of servers)
launch mmc.exe and add the certificates snap-in by pressing ctrl M and choosing certificates (then choose for local computer)
right click 'trusted root certificates' in the left pane, and choose import.
specify the location of this new cert you previously exported
you should get a popup from windows asking if the cert is indeed to be added to the store - choose yes.
I am working on this but have to acknowledge that I am very much out of my depth in dealing with certificates. I cannot say with any confidence that the problem is unrelated to the QCSSL update.
You might try retracting the QCSSL update and see what results. The purpose of the update is to make using Eudora with Office365 easy. It is not to make it possible. It can be done by setting the appropriate configuration in your Eudora.ini file following Katrina's guidance in the Eudora Win List.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am quickly learning a lot about certificates. While Windows has a central certificate store, Eudora maintains its own private store of client and user-trusted certificates on the file "usercerts.p7b". "rootcerts.p7b" is effectively a list of trusted certificate authorities. You can view these using Eudora's Certificate Information Manager.
So I am making some progress but the only thing that bears directly on your issue is that I have tried hard to reproduce it and, so far, have failed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Pete,
Thanks so much for continuing to look at this. Two pieces of information that may be of interest from my situation:
It appears that the QCSSL.dll file does play a role in the error I'm getting. If I revert back to a non-patched QCSSL (like the original one I have from 2005) I do not get the incoming mail certificate errors (but of course I get the outgoing TLSv 1.0 errors that the patch fixed).
The usercerts.p7b is appropriately getting updated as I add new certificates to 'trusted' when the popup asks me to.
On a related note, I confirmed that the results are the same (i.e. usercerts.p7b getting updated) if the certificate is added to the trusted list either by way of the popup box ("SSL server rejected" / "Do you want to trust this certificate in future sessions") or by going to Properties/Last SSL information, finding the skull and crossbones, and clicking Add to Trusted.
One interesting thing is that in the Last SSL info on a failed attempt, the negotiation status shows as failed, yet the notes say "cert chain not trusted/cert bad destination host name does not match" but ALSO says "But ignoring this error because Certificate is trusted". In other words, it seems to know that the certificate has been added to trusted, but still rejects it and the Certificate Information Manager shows the skull and crossbones.
I've sent a request to join the listgroup to try to find the post by Katrina you referenced.
Many thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the detailed report. I will continue to
study the matter.
Pete
At 03:00 PM 3/2/2022, B. Beor wrote:
Hi Pete, Thanks so much for
continuing to look at this. Two pieces of information that may be of
interest from my situation:
It appears that the QCSSL.dll file does play a role in the error I'm
getting. If I revert back to a non-patched QCSSL (like the original one I
have from 2005) I do not get the incoming mail certificate errors (but of
course I get the outgoing TLSv 1.0 errors that the patch fixed).
The usercerts.p7b is appropriately getting updated as I add new
certificates to 'trusted' when the popup asks me to.
On a related note, I confirmed that the results are the same (i.e.
usercerts.p7b getting updated) if the certificate is added to the trusted
list either by way of the popup box ("SSL server rejected" /
"Do you want to trust this certificate in future sessions") or
by going to Properties/Last SSL information, finding the skull and
crossbones, and clicking Add to Trusted.
One interesting thing is that in the Last SSL info on a failed attempt,
the negotiation status shows as failed, yet the notes say "cert
chain not trusted/cert bad destination host name does not match" but
ALSO says "But ignoring this error because Certificate is
trusted". In other words, it seems to know that the certificate has
been added to trusted, but still rejects it and the Certificate
Information Manager shows the skull and crossbones.
I've sent a request to join the listgroup to try to find the post by
Katrina you referenced. Many thanks.
New attempt today, Feb 20 2022. I updated the QCSSL.dll, ssleay32.dll and libeay32.dll with the version Feb 9 provided.
AND IT WORKS perfectly, as it was working long ago.
THANKS A LOT !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Indeed, I continue to receive the enigmatic message "Certificate bad: Destination Host name does not match host name in certificate But ignoring this error because Certificate is trusted"
But nevertheless, it works fine.
Bye
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Pete,
As you saw I did some checking at the very helpful Eur win list. I'm not really able to post there because they have a requirement for doing only inline responses, and with my eudora problems I'm using yahoo mail, which apparently doesn't 'separate out' the response part of the email, nor does is allow editing messages more than a given length, so I can't respond to long chains.
Here's some additional data for you.
I tried doing what Katrina kindly suggested and reverting back to a prior patch and then adding the line SSLSendVersion=9 <x-eudora-option:sslsendversion=9> to fix the TLS1.2 send issue. Unfortunately, I can't find a prior patched set of files that allow for the receive problem stated above to be fixed. The only one that works for receiving is a pre-patch QCSSL from 2005, which I assume is the original Eudora version. That allows receiving with no problem, but adding the SSLSendVersion=9 does not fix the send problem.</x-eudora-option:sslsendversion=9>
I also tried a QCSSL dated 4/30/20, but I'm embarrassed to say I can't remember where I got it. I believe it fixed another Eudura 'hang' problem. That works for receiving, but not sending. I'm attaching it for you in case it helps figure out what is different between this version and your patches, which might identify what changed to make receiving not work (I tried decompiling the DLL but that's way beyond me for finding the differences)
Many, but not all, of my receive errors have to do with the middleman bitdefender certificates. I had assumed that if I turned off my AV, then bitdefender would not get in between me and the mail server, but that doesn't seem to be the case: if I turn off the AV, I get the same exact error.
As before, what is confounding is that it works sometimes, but not others, with the exact same error sequence. In other words, the certificate name dose not match, but error is ignored because the certificate has been trusted, but then it doesn't make the handshake.
I don't know what role the rootcerts.p7b plays. I'm using the one in your patch.
The DLL you attached is actually the original Eudora one. Its internal date is 10/3/2006. It has no understanding of SSLSendVersion=9. I will look for differences between it and the current version in terms of handshakes for receiving.
My understanding of rootcerts.p7b is that it stores certificates of trusted certificate authorities. Generally Eudora does not change this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your confirmation that the problem persists after you disable your AV is very significant. It means that we must look for some difference between the original Eudora QCSSL and the latest Hermes QCSSL. I very much want to get to the bottom of this but, since I am unable to reproduce the problem despite having tried to in several ways, I can do this only with your help. I will probably need to give you a chain of versions to try with incremental changes between them until the critical change is isolated. I will get busy now to create the first of these and I suggest that, during this process, we communicate by direct email rather than using this mailing list.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have attached another zipped QCSSL.dll for for you to try. This build is as close as I can get to the original Eudora QCSSL.dll. The DLL is intended solely for troubleshooting this one matter; other people should NOT use it.
Hi Pete,
I got your message about direct email but don't have your email (the users.sourceforge.net bounced back).
Unfortunately the new test patch does not work. Same errors on receive -- checking mail gets the error that the certificate chain not trusted/bad because the name does not match/ignoring because Cert is trusted. As before, even though is says the cert is trusted, the CIM shows the skull and crossbones. Upon multiple attempts to recheck mail, the mail is retrieved even though I get the same error (and now the CIM shows the smiley face).
That post was in 2015 and the patch applied only to the slow checking of email on the first attempt. As you said it certainly predated your patches for the outgoing mail problem.
My usercerts file now has over 1200 certificates in it, most from Bitdefender. I'm wondering if that means that some new certificate gets generated at every check?
I have attached another zipped QCSSL.dll for for you to try. This build is as close as I can get to the original Eudora QCSSL.dll. The DLL is intended solely for troubleshooting this one matter; other people should NOT use it.
Thank you for trying. I think we may now need to give up. As I noted, the build I sent yesterday is as close to the original Eudora QCSSL as I can easily get. My presumption was that this version would work for you and that we could proceed by incrementally introducing changes until one of them reveals the source of the problem. But it did not work. And there is no easy way to work backwards. The only way to get closer to the original would be to disassemble the original and work through it instruction by instruction to find where it deviates. Doing that is within my capabilities but it would be a huge amount of work that I am not ready to take on at present.
I should note one important factor. For the most part it seems very clear that the Eudora code that was open-sourced is either identical to or very close to identical to the code used to build the final Eudora version. However QCSSL is a stand-out exception. For a start, the open-sourced QCSSL code does not even compile. Then, once a couple of simple changes are made to make it compile, it crashes on every connection attempt due to two very unsubtle bugs.
I do not like giving up on this, partly because I want to help and partly just because it is such a curious mystery. I cannot deny the conclusion that something must have changed in the QCSSL code but it seems that there must be something more to it. Consider that, first, nobody else, as far as I know, is having the same trouble -- and I am unable to make it happen myself. Then it is especially puzzling that the latest QCSSL works reliably for you for sending but not for receiving. The TLS-handshaking is performed independently of the email protocol being used so, if your TLS configuration is the same for sending and receiving, they should work the same! And then there is the fact that the problem does not occur on every attempted POP connection.
I am left wondering if the large number of certificates in your usercerts.p7b might have something to do with it. Yours has over 1,200 while mine has 15.
I will continue to think. To contact me directly please use pete@maclean.com.
Pete
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Thanks for the great Hermes patch for Eudora. We're currently using it with office365 e-mail and POP is working well with TLS v1.2. Unfortunately Microsoft has begun deprecating TLS v1/1.1 over the past few weeks and we're having issues with SMTP. No matter what settings I choose, e-mails are still being sent with TLSv1 (image attached). This causes the server connection to fail until we hit a server that hasn't been "upgraded" to remove TLSv1/1.1 capability yet. Changing to port 465, which I don't believe is supported by smtp.office365.com, leads to a timeout.
Right now we're able to limp by because a few of office365's many SMTP servers are still working with TLS v1/v1.1 so we can keep trying to resend over and over until we hit one that works, but that's taking longer and longer as they "upgrade" more servers so I'm afraid eventually we'll be completely out of luck.
All that said, is there any way to force Eudora/Hermes to send e-mails with TLS v1.2? I feel like I'm missing something simple.
Thanks in advance!
Last edit: Chris Kilroy 2022-01-25
Hi Chris,
There is a way to force a Hermes-updated Eudora to send with TLS
1.2. However it is rather complicated and I can offer a better
solution in the form of an updated version of the Hermes QCSSL DLL with
an enhancement to handle this particular difficulty.
Please download:
<x-tab> </x-tab>
https://www.maclean.com/downloads/QCSSL_Update.zip
Drop the three DLLs in this zip into your Eudora directory to replace
the existing ones (while Eudora is not running). Make sure that
your Office 365 persona is configured for "Required STARTTLS"
for both sending and receiving and all should be well. This is very
new and not widely tested but it works very reliably for me.
This enhancement works by detecting a persona's use of the Office 365
servers and overriding the default configuration with a configuration
made especially for Office 365 -- in particular forcing TLS 1.2 for both
sending and receiving. Only QCSSL.dll has actually changed; the
other two DLLs are the same as in the original Hermes package.
Pete Maclean
At 03:44 PM 1/25/2022, Chris Kilroy wrote:
Pete,
Wow. A million thank yous! We deployed your updated DLL on a few machines this afternoon and office365 is working perfectly now. Thanks again!
Chris
Chris,
Thank you for the confirmation.
Pete
At 08:08 PM 1/25/2022, you wrote:
This solution worked for me on Windows 7 and Windows 10 with Godaddy's Exchange Office365 smtp/pop server. I did though have to install the Hermes Eudora 7 edition, as our old Eudora 6 would not work with this solution.
Thanks again!
Pete,
Needed this update for Xfinity/Comcast as they are requiring TLSv1.2 as of April 17, 2023.. Made the update along with the ini changes and sent them a test email, reply came back with success reporting the connection was using TLSv1.2 ! Thanks for your work on this!
Bill
Pete, adding my thanks to your updated DLL. I had spent hours trying to get it to work prior.
The outgoing messages now send every time with TLSv1.2. However, with the updated DLL I'm getting a separate issue on receiving.
When I check mail, I get the "server SSL rejected" certificate error. I then agree to trust the error in future sessions. This may repeat a few times as I keep hitting different servers. At some point I get the status line error "SSL Negotiation failed, Certificate bad, destination host name does not match but ignoring this error because certificate is trusted. The connection with the server has been lost cause 206"
If I then check the last SSL, it shows failed because of a bad cert, but repeats the message about 'ignoring this error because cert is trusted". The Cert info mgr shows the skull and crossbones. I add the cert to trusted.
I've been keeping track of which servers/certs get rejected, I'm up to over 50.
Every 5th or 6th attempt works, even though the notes in the SSL popup still show the cert error is being ignored (without an accompanying status error). In other words, sometimes I can check mail and sometimes not, even with the exact same situation (certs forced trusted).
I'm over my head and don't know if this is related in some way to the updated DLL files and which ones.
Any help would be appreciated.
Many thanks.
Pete
At 11:42 PM 2/15/2022, B. Beor wrote:
I am busy trying to reproduce this behaviour (so far without success) and studying the relevant code. I am no expert with certificates but may be able to figure it out.
I am not making much progress with what I have. Would you please grab my latest update of Hermes QCSSL from https://www.maclean.com/downloads/QCSSL_Update.zip and install it. Read the release notes and make sure that it is creating a log file. Then try some connections until one fails and then send me the log file. That should give me more to work with.
Hi Pete,
I was trying to figure this out myself so you wouldn't have to waste time. I didn't have too much luck, I'm just not knowledgeable.
On the receiving side: if I have a certificate fail and "add to trusted", I see how the certificate shows up in the 'trusted' list and in the usercerts.p7b, so I think that part is okay.
I wasn't having this problem before using the patch, which is why I considered the problem was related to the patch, but of course it could be coincidental.
I've attached a recent log file. As you can see, the SSL/TLS handshake fails when a bad certificate is found, even if it is 'ignoring this error because certificate is trusted'. Yet every so often, the handshake succeeds.
Let me know if there's anything else I can provide.
Separately, I appreciate all you have done to make the patches available. Do you have a way to accept donations?
p.s: I did see this in an old forum and have no idea whether is applicable.:
these are the steps that have worked for me - your mileage may vary a tad.
optionally, move the usercerts.p7b in your eudora directory to somewhere else
as many have said, go to the cert through personalities, drill down to the
skull icon, or the smiley face icon and hit accept.
but here's the twist - the actual cert for the mail server wasn't shown until i installed the top level certs. (installing just the root certs doesn't help...it's the cert from your mail server that you need)
Last edit: B. Beor 2022-02-25
I am working on this but have to acknowledge that I am very much out of my depth in dealing with certificates. I cannot say with any confidence that the problem is unrelated to the QCSSL update.
You might try retracting the QCSSL update and see what results. The purpose of the update is to make using Eudora with Office365 easy. It is not to make it possible. It can be done by setting the appropriate configuration in your Eudora.ini file following Katrina's guidance in the Eudora Win List.
I am quickly learning a lot about certificates. While Windows has a central certificate store, Eudora maintains its own private store of client and user-trusted certificates on the file "usercerts.p7b". "rootcerts.p7b" is effectively a list of trusted certificate authorities. You can view these using Eudora's Certificate Information Manager.
So I am making some progress but the only thing that bears directly on your issue is that I have tried hard to reproduce it and, so far, have failed.
Hi Pete,
Thanks so much for continuing to look at this. Two pieces of information that may be of interest from my situation:
It appears that the QCSSL.dll file does play a role in the error I'm getting. If I revert back to a non-patched QCSSL (like the original one I have from 2005) I do not get the incoming mail certificate errors (but of course I get the outgoing TLSv 1.0 errors that the patch fixed).
The usercerts.p7b is appropriately getting updated as I add new certificates to 'trusted' when the popup asks me to.
On a related note, I confirmed that the results are the same (i.e. usercerts.p7b getting updated) if the certificate is added to the trusted list either by way of the popup box ("SSL server rejected" / "Do you want to trust this certificate in future sessions") or by going to Properties/Last SSL information, finding the skull and crossbones, and clicking Add to Trusted.
One interesting thing is that in the Last SSL info on a failed attempt, the negotiation status shows as failed, yet the notes say "cert chain not trusted/cert bad destination host name does not match" but ALSO says "But ignoring this error because Certificate is trusted". In other words, it seems to know that the certificate has been added to trusted, but still rejects it and the Certificate Information Manager shows the skull and crossbones.
I've sent a request to join the listgroup to try to find the post by Katrina you referenced.
Many thanks.
Pete
At 03:00 PM 3/2/2022, B. Beor wrote:
I am very curious for any solution, as I meet exactly the same problem.
New attempt today, Feb 20 2022. I updated the QCSSL.dll, ssleay32.dll and libeay32.dll with the version Feb 9 provided.
AND IT WORKS perfectly, as it was working long ago.
THANKS A LOT !
Pierre, were you having the TLS send error or the receive error (certificate problem)? Thanks.
Indeed, I continue to receive the enigmatic message "Certificate bad: Destination Host name does not match host name in certificate But ignoring this error because Certificate is trusted"
But nevertheless, it works fine.
Bye
Hi Pete,
As you saw I did some checking at the very helpful Eur win list. I'm not really able to post there because they have a requirement for doing only inline responses, and with my eudora problems I'm using yahoo mail, which apparently doesn't 'separate out' the response part of the email, nor does is allow editing messages more than a given length, so I can't respond to long chains.
Here's some additional data for you.
I also tried a QCSSL dated 4/30/20, but I'm embarrassed to say I can't remember where I got it. I believe it fixed another Eudura 'hang' problem. That works for receiving, but not sending. I'm attaching it for you in case it helps figure out what is different between this version and your patches, which might identify what changed to make receiving not work (I tried decompiling the DLL but that's way beyond me for finding the differences)
As before, what is confounding is that it works sometimes, but not others, with the exact same error sequence. In other words, the certificate name dose not match, but error is ignored because the certificate has been trusted, but then it doesn't make the handshake.
Thanks!
The DLL you attached is actually the original Eudora one. Its internal date is 10/3/2006. It has no understanding of SSLSendVersion=9. I will look for differences between it and the current version in terms of handshakes for receiving.
My understanding of rootcerts.p7b is that it stores certificates of trusted certificate authorities. Generally Eudora does not change this.
Your confirmation that the problem persists after you disable your AV is very significant. It means that we must look for some difference between the original Eudora QCSSL and the latest Hermes QCSSL. I very much want to get to the bottom of this but, since I am unable to reproduce the problem despite having tried to in several ways, I can do this only with your help. I will probably need to give you a chain of versions to try with incremental changes between them until the critical change is isolated. I will get busy now to create the first of these and I suggest that, during this process, we communicate by direct email rather than using this mailing list.
I have attached another zipped QCSSL.dll for for you to try. This build is as close as I can get to the original Eudora QCSSL.dll. The DLL is intended solely for troubleshooting this one matter; other people should NOT use it.
Hi Pete,
I got your message about direct email but don't have your email (the users.sourceforge.net bounced back).
Unfortunately the new test patch does not work. Same errors on receive -- checking mail gets the error that the certificate chain not trusted/bad because the name does not match/ignoring because Cert is trusted. As before, even though is says the cert is trusted, the CIM shows the skull and crossbones. Upon multiple attempts to recheck mail, the mail is retrieved even though I get the same error (and now the CIM shows the smiley face).
I found the source of the QCSSL file I had showed you that worked for incoming messages. It was from this post:
https://groups.google.com/g/comp.mail.eudora.ms-windows/c/UjM1-7_rLN8
That post was in 2015 and the patch applied only to the slow checking of email on the first attempt. As you said it certainly predated your patches for the outgoing mail problem.
My usercerts file now has over 1200 certificates in it, most from Bitdefender. I'm wondering if that means that some new certificate gets generated at every check?
Thanks
I have attached another zipped QCSSL.dll for for you to try. This build is as close as I can get to the original Eudora QCSSL.dll. The DLL is intended solely for troubleshooting this one matter; other people should NOT use it.
Attachments:
TLS v1.2 for SMTP
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/hermesmail/discussion/general/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Thank you for trying. I think we may now need to give up. As I noted, the build I sent yesterday is as close to the original Eudora QCSSL as I can easily get. My presumption was that this version would work for you and that we could proceed by incrementally introducing changes until one of them reveals the source of the problem. But it did not work. And there is no easy way to work backwards. The only way to get closer to the original would be to disassemble the original and work through it instruction by instruction to find where it deviates. Doing that is within my capabilities but it would be a huge amount of work that I am not ready to take on at present.
I should note one important factor. For the most part it seems very clear that the Eudora code that was open-sourced is either identical to or very close to identical to the code used to build the final Eudora version. However QCSSL is a stand-out exception. For a start, the open-sourced QCSSL code does not even compile. Then, once a couple of simple changes are made to make it compile, it crashes on every connection attempt due to two very unsubtle bugs.
I do not like giving up on this, partly because I want to help and partly just because it is such a curious mystery. I cannot deny the conclusion that something must have changed in the QCSSL code but it seems that there must be something more to it. Consider that, first, nobody else, as far as I know, is having the same trouble -- and I am unable to make it happen myself. Then it is especially puzzling that the latest QCSSL works reliably for you for sending but not for receiving. The TLS-handshaking is performed independently of the email protocol being used so, if your TLS configuration is the same for sending and receiving, they should work the same! And then there is the fact that the problem does not occur on every attempted POP connection.
I am left wondering if the large number of certificates in your usercerts.p7b might have something to do with it. Yours has over 1,200 while mine has 15.
I will continue to think. To contact me directly please use pete@maclean.com.
Pete