HEY GUYS, OUR EUDORA IS BACK!!!!!
WE HAVE A FIX!!!!!!!!!!!!!!!!!!
THANKS & KUDOS to Danny Weiss of the amazing Eudorafaqs.com web site for thinking of the final step to make it work!
To recap, the situation is that since Verizon changed it's SMTP certificate, our beloved Eudora has been jamming on sending and receiving mail.
We learned that to get the incoming mail to work, we need to
(1) Try to check mail; get error message about SSL certificate
(2) Right-click on personality and select Properties
(3) Select 'Incoming Mail' tab
(4) Click on 'Last SSL Info' button
(5) Select Certificate Information Manager
(6) Click on each + in the chain of certificates listed under 'Server' until we find the skull-&-crossbones one
(7) Select it, and click on 'Add to Trusted'
(8) Close out carefully ("Done", "OK") & close Eudora
(9) Open Eudora and try again.
(10) If the error persists, repeat the sequence and find the next unTrusted certificate, get it Trusted, and so on.
We hear that to get the outgoing mail to work, we need merely to do the same thing, but use the "Generic Properties" tab instead of the "Incoming Mail" tab. BUT, for many of us, that simply hasn't worked. We select "Last SSL Info", but we just get an error message saying that we have never sent email using an SSL connection wtih this personality. Without access to the "Last SSL Info" > Certificate Information Manager, we can't get any further.
ENTER DANNY WEISS!!!
Danny suggested that on the "Properties" window (the window that pops up when we right-click the personality), on the "Generic Properties" tab, we should UNCHECK the box that says "Use relay personality, if defined."
So I unchecked the box. I closed the window. I repeated the steps.... IT WORKED!!! This time, when I clicked on "Last SSL info", I got a grey window similar to the one I had obtained on the "Incoming Mail" side. This time, I was able to select the Certificate Information Manager, find the skull-and-bones certificate, and "Add to Trusted".
Needless to say, the problem was Verizon's new certificate.
Please write and tell me that all of you are now sending and receiving again!
09-03-2015 08:03 AM - edited 09-03-2015 08:33 AM
Further notes on connection problems since Verizon changed their servers on 31 August:
I installed Eudora 6.2.4 on two different Intel Macs, one running OS X 10.5.8 and the other running OS X 10.6.8.
I set up the OS X 10.6.8 one with POP3 and SMTP access to my Verizon Email account. I enabled the plug-in Esoteric Settings 6.0 so that I could control the logging options. I then copied the Eudora Settings to the other Mac running OS X 10.5.8, so the settings are exactly the same.
Eudora under 10.6.8 could send and receive mail with no problem.
Eudora under 10.5.8 cannot download any mail from the POP3 server. It cannot upload mail to the SMTP server either. Outgoing messages remain queued.
Inspection of the two Eudora Log files shows that both connect to the POP server using port 995 and start to receive the certificate from Baltimore Cyber. However, midway in receiving it, 10.5.8 rejects it with SSLVerifyCert(0,xx) error = 7. 10.6.8 continues to receive it, gives a SSL_Handshake 1, then continues to receive information from the Oracle Communications Messaging Server, and successfully sends and receives Email.
The Eudora Settings are exactly the same, and the Verizon Email account being accessed is the same. New messages sent to that account from a third party cannot be downloaded by 10.5.8 but can be downloaded by 10.6.8. The SSLVerifyCert message appears at exactly the same point in the Eudora Log under 10.5.8
On both Macs, the Baltimore Cyber Trust Root certificate is present (expiring May 13, 2025) in the Apple Keychain. Behavior is the same whether the Trust settings are set to Default or to Always Trust. Eudora should be using the Apple Keychain for SSL. This Baltimore Cyber certificate controls connecting to Verizon Webmail using a browser. If the Trust setting is set to Never Trust ; I cannot connect to www.verizon.net using either Safari or Firefox. If the Trust setting is returned to the Default or Always Trust then connection to www.verizon.net using either browser is possible, using both Macs. The Baltimore Cyber Trust Root certificate seems to be relevant.
In a previous post by RadDadTX, a Verizon Public SureServer CA is also visible in the certificate list. That is not present in either Apple Keychain, and it is not mentioned in the Eudora Logs. Neither Eudora is informed that there is a new certificate that must be accepted, so I'm not sure that this certificate is relevant. Eudora under 10.6.8 can send and receive Email without it.
I have tried changing many of the Eudora settings mentioned in previous posts, including CRAM-MD5, and no change that I have tried will enable Eudora 6.2.4 running under Max OS X 10.5.8 to send or receive mail to my Verizon Email account.
I did this comparison to replicate the problem that originally arose, namely that on a third Mac with Eudora 6.2.4 running under Mac OS X 10.5.8, there was no trouble sending or receiving E-mails to a Verizon Email account on August 30, 2015. And on August 31, 2015, neither sending nor receiving E-mails was possible (up to and including today, 3 September).
I believe there must have been some additional changes in the POP and SMTP servers made by Verizon on 31 August that interferes with some mail clients communicating with the servers.
It is very frustrating that this change was not announced, and I hope that Verizon can restore the previous level of service. Some users of legacy Email systems have solutions to the problem; others do not have solutions yet; and by restoring the previous level of service, hopefully Verizon can solve the problem for everybody.
THANK YOU.... THANK YOU.... THANK YOU.... THANK YOU.... THANK YOU.... THANK YOU.... THANK YOU.... THANK YOU.... THANK YOU.... THANK YOU.... !!!!!!!
I have been using Eudora ever since it was first released at NIH, through all of the Qualcomm versions, for over 20-25 years. SO GLAD TO HAVE IT WORKING AGAIN!!!!!
... I get a "SSL certificate rejected," or something like that. .....
This sounds like a problem with an expired certificate, I think the following link from the Eudora FAQs web site will be helpful. It describes a complete procedure for telling Eudora how to accept a new certificate; see: