Well, about three days ago, I lost the ability to send any email. I'm using Eudora 7.1.0.9 on Windows XP. My account is through Cox.com, so the smtp server was smtp.cox.com. I woud get an error: "SSL negotiation failed. The connection with the server has been lost."
Multiple calls to to Cox tech support yielded a tech guy who referred me to HERMESSL. I installed it on my laptop at work, and on my secretary's computer, both of which run Eudora.
I did it on my secretary's computer first (of course). I got the same SSL negotiation error, but when I changed the account's "Secure sockets when sending" to "Never", the mail went through fine (even though cox said that sending HAD to be SSL'ed). I tried it with attachments. Everything fine without SSL. Yay!!
So I installed it on my laptop. Same thing. Wouldn't send unless "Never", but then it would send fine.
Now here I am at home with my laptop, and it won't send again with "Never". I get the same 550 5.1.0 error. Can't send anything.
HELP! Anyone have an idea of something else to try?
Cox says this is a known thing. They changed a vendor, or something, and now TLS 1.2 is required to connect with SSL to the smtp server.
I desperately don't want to change email clients, and I desperately desperately don't want to upgrade from XP. (Trust me, I'm backed up hourly to my teeth.)
I need to find a way to get Eudora to work with Cox, or I have to find another smtp source that will work with my Eudora.
Thanks in advance for any insight!!!
--Steve D.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am the person responsible for HermesSSL and I will try to help you solve this problem. I have just now made some attempts to open an SSL connection with smtp.cox.com and failed because there is, apparently, no such host. I mean that I am unable to get an IP address for it. Are you sure that smtp.cox.com is the appropriate server name?
Pete Maclean
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, Pete,
Oh, thank you so much for responding. I really appreciate it!
First of all, duh, I gave you the wrong cox smtp address. It's:
smtp.coxmail.com
And there's more info, still very confusing to me.
I'm back at the office now. In the accounts settings, under "Secure Sockets", if I select Never, it DOES send. It also WILL send if I select "required, alternate port".
But if I select Required, Start TLS or If Available, Start TLS, then I get that "ssl negotiation failed" error.
I guess I don't know what "alternate port" is or why it seems to be working on that setting. I'm using port 587. Cox told me that 25 was the default for smtp, but that I should use 587 or 465.
It works exactly the same on my secretary's computer:
Never -- works
If Available, Start TLS -- no work
Required, Alternate port -- works
Required, Start TLS -- no work.
Another clue? When I look at the certificates, I don't see anything from smtp.coxmail.com. I believe I used to, though. Would that matter? I could go to a year-old backup and get one, not very hard.
Hope that helps!
--Steve D.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The behaviour that you now describe seems reasonable and appropriate.
Email protocols (POP, IMAP and SMTP) started out in the old convivial days of the Internet when there was little apparent need for encryption and little standard means of adding encryption. The need/demand for encryption changed radically as the net grew and became a public resource and encryption options were added to these protocols, fortunately all in basically the same way. And this was done using two procedures. The first was by negotiating an encrypted connection before getting down to the work of transferring email. Which meant having two ports for each protocol, one for unencrypted sessions and one for encrypted. But ports are a limited resource and hence valuable so a second method was introduced, that of opening an unencrypted session to start with and then switching it to encrypted operation. This meant that a single port could be used for all sessions of a given protocol, encrypted or not. And this was accomplished by adding a new command to each protocol called "STARTTLS". This was done with good intentions but in practice it had problems so the preferred method has come to be having two distinct ports. It has taken years and years but now the use of unencrypted sessions is waning and more and more providers are discontinuing support for unencrypted use and maintaining only one port per protocol. Well, except for SMTP, where, for other reasons there are three defined.
The story I have just recounted is to try to explain that STARTTLS is being used less and less, and that it is no big deal if an email provider does not support it. There is still a use for it with SMTP port 587 but not otherwise. In Hermes, it should be safe and would probably be wise to remove the "If Available, STARTTLS" option -- it's a booby trap. Whether it would be also safe to remove the "Required, STARTTLS", I am unsure. The default should be changed from "Never" to "Required, Alternate Port" and few users should need anything different. And, for clarity, the default for each Alternate Port should be identified (465 for SMTP, 993 for IMAP and 995 for POP).
You say that you I don't know what "alternate port" is. Well I trust I have added a little light to this. For SMTP, the alternate port is the one for pure encrypted connections and is number 465. Oh, and in case it is not clear what a port is in the first place, a real-world analogy would be a large Post Office with multiple serving counters grouped for different purposes, say one for postage stamps, one for parcel post, one for banking and so on.
Bottom line again is that, from what you report, it seems highly likely that everything is working well and just as it should. Of course the fact that it works with the "Never" option means that Cox still supports unencrypted SMTP sessions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OMG this is fantastic! I looked everywhere for info like this and couldn't find it. I'm happy to see that I don't have to try to make my OS understand TLS 1.2. That's exactly what Cox said I'd have to do. If you Google "TLS 1.2" and "Windows XP", you find ways of getting it done, maybe, but it seems too dangerous and unknown to me, and frankly, I'm not even certain that the Cox tech guy really really knew what the answer was.
I can't wait for Hermes!
I still can send mail at my office, but I cannot find any configuration that will allow me to send mail when my laptop is at my house! That is not the end of the world, but ... Any ideas where to look? Could Cox be somehow different at my house? I'm using the same exact router. The cable modem is different. The service should be the same!
Thanks again! The thought of changing email clients right now was just awful!!!
--Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The only thing I can think of that is likely to be different at home is that your home ISP may block outgoing connections to port 25 (the port for unencrypted SMTP) while your office ISP would most likely not. Many ISPs globally block connections to port 25 for residential customers in order to reduce spam. However this would explain your problem only if you are using port 25 and, presumably, you are using port 465 (the Alternate Port for SMTP).
Pete
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks again.
Yeah. Well, it's not the end of the world. This might be something that the Cox tech people can shed light on. But at least I'm up and running again.
Another couple questions, if you have time: Does this have anything to do with Windows XP not having native support for TLS 1.2? And is this something that Hermes will help with if I don't upgrade to a later version of Windows?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
... I was reading about success with Comcast. I've never considered getting an account with anyone other than Cox, but would changing suppliers maybe be the answer?
/SD
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That would be a solution but it really should not be necessary. Please hang on for a while and let's see if we can fix things to work with Cox. If you need to send email in the interim, please consider that you may be able to use your ISP's SMTP server instead.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would using Stunnel resolve this? I recall having SSL issues last year with Eudora 7.1.0.9, Comcast as ISP and Google as the email account. After installing Stunnel, no issues at all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Stunnel would work; HermSSL is essentially our solution to remove the need for Stunnel, but it obviously doesn't work in all cases. I apologise for being completely missing over the last month-and-a-half.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Stunnel would work; HermSSL is essentially our solution to remove the need for Stunnel, but it obviously doesn't work in all cases. I apologise for being completely missing over the last month-and-a-half.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just started having the same issue as Steven's related to the SSL not working, or at least similar. What is wierd is I have five installs of Eudora and only two work. One is for gmail, and the HermesSSL fix took care of that issue months ago. (Thanks Hermes.)
But over the weekend three of the four others have stopped working.
Quick notes: I have a reseller account on my host because I used to play with various websites I created (though I don't actually use them, but for mail lately). So all the parameters are basically all the same for mail, only the names are different. The one that does work is not my main mail. (Bummer.) I am running 7.0.1.0 on all installations of Eudora, so it's exactly the same. (I know 7.1.0.9 is recommended.)
It does report that TLSv1.2 is being used in "Last SSL info" on the working one, but only TLSv1 on the others. It does seem to work when I change the setting to "never" like mentioned above, but I do want it to work securely despite me not doing evil stuff. I've sat and compared the the working one to the others and found nothing different in the settings.
One other note, my "suggested port of 995" is not changeable that I can find, SSL says it is 110. On another computer, I get the same TLS issue, but when I added the HermesSSL fix, it just sits there attempting to log in, until I tell it to stop.
This is going to make me quit Eudora, but I love it so much for the way it can be contained in one directory and backed up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Disclaimer: I use the POP protocol with my connection to Comcast, I don't know if the following note to set port 995 will work for IMAP.
In your designated mail folder, you should find the "eudora.ini" file, which can be opened in notepad. Many of these settings are defined in the tools/options menu in Eudora - you should recognize some of the line items. Other settings are a bit obtuse, it's best to change them from the options menu. Start by making a copy of the eudora.ini file, then check to see if you have a line entry in the settings section "POPPort=995" - if not add it. Restart Eudora and see if that helps.
I was never able to get HermeSSL to work with Eudora when I was running Windows 7. I recently upgraded to Windows 10 and on a whim, I loaded Eudora, added HermeSSL - and it worked! I am now able to connect to Comcast using SSL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Again, if you read my post above, you will see that I use Stunnel and have no SSL issues. So, why would you be so quick to abandon Eudora without trying Stunnel first?!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I don't see a 32 bit download for it. It is in 64bit. Current Win7 is 32 unless I want to reinstall Win7 with 64 bought from ebay for under ten bucks. (An option that means reinstalling everything I have now, if all is compatable.)
I was holding off until I was forced into Win10 in 2020. I despise Win 10 at this moment, although I do have a drive configured for Win10. (It doesn't like my video card, used for dual monitors.) Debating on Linux since Win10 is a "service"- which means the plan for annual payments for an operating system.
So with that, do you know how to force Eudora to go TLSv1.2 after I've I have copied the files from HermesSSL? I mean, that is my desire. As I said, one install does it, the others don't. I'd rather fix the problem than add a crutch, and the crutch appears to need a lot of changes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Arthur, I'll check into getting an older version real quick.
I spent the last day going through all my website logins and emails. Seems the host wanted 12 digits for a password now. I changed all passwords and now it's letting me get my mail despite using TLSv1. I still can't get HermesSSL to work on the other computer with only one install of Eudora, it still just sits there. (I went back to the original files now.) And I still can't get the other installs to go to TLSv1.2, but at least it is working
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, all,
Well, about three days ago, I lost the ability to send any email. I'm using Eudora 7.1.0.9 on Windows XP. My account is through Cox.com, so the smtp server was smtp.cox.com. I woud get an error: "SSL negotiation failed. The connection with the server has been lost."
Receiving email always fine.
If I change my account setting oo "Secure Sockets when sending" to "Never", I get the error "error 550 5.1.0 sender rejected. Refer to error code section at https://www.cox.com/business/support/email-errror-codes.html "
Multiple calls to to Cox tech support yielded a tech guy who referred me to HERMESSL. I installed it on my laptop at work, and on my secretary's computer, both of which run Eudora.
I did it on my secretary's computer first (of course). I got the same SSL negotiation error, but when I changed the account's "Secure sockets when sending" to "Never", the mail went through fine (even though cox said that sending HAD to be SSL'ed). I tried it with attachments. Everything fine without SSL. Yay!!
So I installed it on my laptop. Same thing. Wouldn't send unless "Never", but then it would send fine.
Now here I am at home with my laptop, and it won't send again with "Never". I get the same 550 5.1.0 error. Can't send anything.
HELP! Anyone have an idea of something else to try?
Cox says this is a known thing. They changed a vendor, or something, and now TLS 1.2 is required to connect with SSL to the smtp server.
I desperately don't want to change email clients, and I desperately desperately don't want to upgrade from XP. (Trust me, I'm backed up hourly to my teeth.)
I need to find a way to get Eudora to work with Cox, or I have to find another smtp source that will work with my Eudora.
Thanks in advance for any insight!!!
--Steve D.
Hello Steve,
I am the person responsible for HermesSSL and I will try to help you solve this problem. I have just now made some attempts to open an SSL connection with smtp.cox.com and failed because there is, apparently, no such host. I mean that I am unable to get an IP address for it. Are you sure that smtp.cox.com is the appropriate server name?
Pete Maclean
Hi, Pete,
Oh, thank you so much for responding. I really appreciate it!
First of all, duh, I gave you the wrong cox smtp address. It's:
smtp.coxmail.com
And there's more info, still very confusing to me.
I'm back at the office now. In the accounts settings, under "Secure Sockets", if I select Never, it DOES send. It also WILL send if I select "required, alternate port".
But if I select Required, Start TLS or If Available, Start TLS, then I get that "ssl negotiation failed" error.
I guess I don't know what "alternate port" is or why it seems to be working on that setting. I'm using port 587. Cox told me that 25 was the default for smtp, but that I should use 587 or 465.
It works exactly the same on my secretary's computer:
Never -- works
If Available, Start TLS -- no work
Required, Alternate port -- works
Required, Start TLS -- no work.
Another clue? When I look at the certificates, I don't see anything from smtp.coxmail.com. I believe I used to, though. Would that matter? I could go to a year-old backup and get one, not very hard.
Hope that helps!
--Steve D.
Steve,
The behaviour that you now describe seems reasonable and appropriate.
Email protocols (POP, IMAP and SMTP) started out in the old convivial days of the Internet when there was little apparent need for encryption and little standard means of adding encryption. The need/demand for encryption changed radically as the net grew and became a public resource and encryption options were added to these protocols, fortunately all in basically the same way. And this was done using two procedures. The first was by negotiating an encrypted connection before getting down to the work of transferring email. Which meant having two ports for each protocol, one for unencrypted sessions and one for encrypted. But ports are a limited resource and hence valuable so a second method was introduced, that of opening an unencrypted session to start with and then switching it to encrypted operation. This meant that a single port could be used for all sessions of a given protocol, encrypted or not. And this was accomplished by adding a new command to each protocol called "STARTTLS". This was done with good intentions but in practice it had problems so the preferred method has come to be having two distinct ports. It has taken years and years but now the use of unencrypted sessions is waning and more and more providers are discontinuing support for unencrypted use and maintaining only one port per protocol. Well, except for SMTP, where, for other reasons there are three defined.
The story I have just recounted is to try to explain that STARTTLS is being used less and less, and that it is no big deal if an email provider does not support it. There is still a use for it with SMTP port 587 but not otherwise. In Hermes, it should be safe and would probably be wise to remove the "If Available, STARTTLS" option -- it's a booby trap. Whether it would be also safe to remove the "Required, STARTTLS", I am unsure. The default should be changed from "Never" to "Required, Alternate Port" and few users should need anything different. And, for clarity, the default for each Alternate Port should be identified (465 for SMTP, 993 for IMAP and 995 for POP).
You say that you I don't know what "alternate port" is. Well I trust I have added a little light to this. For SMTP, the alternate port is the one for pure encrypted connections and is number 465. Oh, and in case it is not clear what a port is in the first place, a real-world analogy would be a large Post Office with multiple serving counters grouped for different purposes, say one for postage stamps, one for parcel post, one for banking and so on.
Bottom line again is that, from what you report, it seems highly likely that everything is working well and just as it should. Of course the fact that it works with the "Never" option means that Cox still supports unencrypted SMTP sessions.
Hi, Pete,
OMG this is fantastic! I looked everywhere for info like this and couldn't find it. I'm happy to see that I don't have to try to make my OS understand TLS 1.2. That's exactly what Cox said I'd have to do. If you Google "TLS 1.2" and "Windows XP", you find ways of getting it done, maybe, but it seems too dangerous and unknown to me, and frankly, I'm not even certain that the Cox tech guy really really knew what the answer was.
I can't wait for Hermes!
I still can send mail at my office, but I cannot find any configuration that will allow me to send mail when my laptop is at my house! That is not the end of the world, but ... Any ideas where to look? Could Cox be somehow different at my house? I'm using the same exact router. The cable modem is different. The service should be the same!
Thanks again! The thought of changing email clients right now was just awful!!!
--Steve
Steve,
The only thing I can think of that is likely to be different at home is that your home ISP may block outgoing connections to port 25 (the port for unencrypted SMTP) while your office ISP would most likely not. Many ISPs globally block connections to port 25 for residential customers in order to reduce spam. However this would explain your problem only if you are using port 25 and, presumably, you are using port 465 (the Alternate Port for SMTP).
Pete
Thanks again.
Yeah. Well, it's not the end of the world. This might be something that the Cox tech people can shed light on. But at least I'm up and running again.
Another couple questions, if you have time: Does this have anything to do with Windows XP not having native support for TLS 1.2? And is this something that Hermes will help with if I don't upgrade to a later version of Windows?
In this thread:
https://sourceforge.net/p/hermesmail/discussion/general/thread/dbf146a93d/
... I was reading about success with Comcast. I've never considered getting an account with anyone other than Cox, but would changing suppliers maybe be the answer?
/SD
That would be a solution but it really should not be necessary. Please hang on for a while and let's see if we can fix things to work with Cox. If you need to send email in the interim, please consider that you may be able to use your ISP's SMTP server instead.
Would using Stunnel resolve this? I recall having SSL issues last year with Eudora 7.1.0.9, Comcast as ISP and Google as the email account. After installing Stunnel, no issues at all.
Stunnel would work; HermSSL is essentially our solution to remove the need for Stunnel, but it obviously doesn't work in all cases. I apologise for being completely missing over the last month-and-a-half.
Stunnel would work; HermSSL is essentially our solution to remove the need for Stunnel, but it obviously doesn't work in all cases. I apologise for being completely missing over the last month-and-a-half.
I just started having the same issue as Steven's related to the SSL not working, or at least similar. What is wierd is I have five installs of Eudora and only two work. One is for gmail, and the HermesSSL fix took care of that issue months ago. (Thanks Hermes.)
But over the weekend three of the four others have stopped working.
Quick notes: I have a reseller account on my host because I used to play with various websites I created (though I don't actually use them, but for mail lately). So all the parameters are basically all the same for mail, only the names are different. The one that does work is not my main mail. (Bummer.) I am running 7.0.1.0 on all installations of Eudora, so it's exactly the same. (I know 7.1.0.9 is recommended.)
It does report that TLSv1.2 is being used in "Last SSL info" on the working one, but only TLSv1 on the others. It does seem to work when I change the setting to "never" like mentioned above, but I do want it to work securely despite me not doing evil stuff. I've sat and compared the the working one to the others and found nothing different in the settings.
One other note, my "suggested port of 995" is not changeable that I can find, SSL says it is 110. On another computer, I get the same TLS issue, but when I added the HermesSSL fix, it just sits there attempting to log in, until I tell it to stop.
This is going to make me quit Eudora, but I love it so much for the way it can be contained in one directory and backed up.
Disclaimer: I use the POP protocol with my connection to Comcast, I don't know if the following note to set port 995 will work for IMAP.
In your designated mail folder, you should find the "eudora.ini" file, which can be opened in notepad. Many of these settings are defined in the tools/options menu in Eudora - you should recognize some of the line items. Other settings are a bit obtuse, it's best to change them from the options menu. Start by making a copy of the eudora.ini file, then check to see if you have a line entry in the settings section "POPPort=995" - if not add it. Restart Eudora and see if that helps.
I was never able to get HermeSSL to work with Eudora when I was running Windows 7. I recently upgraded to Windows 10 and on a whim, I loaded Eudora, added HermeSSL - and it worked! I am now able to connect to Comcast using SSL.
Port 993 is for IMAP but I could never get it to work with Gmail IMAP. I only use POP, as I want all my emails on my server.
Again, if you read my post above, you will see that I use Stunnel and have no SSL issues. So, why would you be so quick to abandon Eudora without trying Stunnel first?!
Well, I don't see a 32 bit download for it. It is in 64bit. Current Win7 is 32 unless I want to reinstall Win7 with 64 bought from ebay for under ten bucks. (An option that means reinstalling everything I have now, if all is compatable.)
I was holding off until I was forced into Win10 in 2020. I despise Win 10 at this moment, although I do have a drive configured for Win10. (It doesn't like my video card, used for dual monitors.) Debating on Linux since Win10 is a "service"- which means the plan for annual payments for an operating system.
So with that, do you know how to force Eudora to go TLSv1.2 after I've I have copied the files from HermesSSL? I mean, that is my desire. As I said, one install does it, the others don't. I'd rather fix the problem than add a crutch, and the crutch appears to need a lot of changes.
Use an older version than 5.50! I'm running 5.46, 32-bit, in an x64 system. No issues.
Thanks Arthur, I'll check into getting an older version real quick.
I spent the last day going through all my website logins and emails. Seems the host wanted 12 digits for a password now. I changed all passwords and now it's letting me get my mail despite using TLSv1. I still can't get HermesSSL to work on the other computer with only one install of Eudora, it still just sits there. (I went back to the original files now.) And I still can't get the other installs to go to TLSv1.2, but at least it is working
Ah, I found it in the ftp archives. Verision 5.46 32 bit. Thanks.