From: Gloops on 11 Oct 2007 15:32 John H Meyers a écrit, le 11/10/2007 18:45 : > Setting your options to not even use SSL is of course yet another way > to bypass all SSL and certificate issues, without needing > to remove any read-only attributes or rename any "root" certificate file. For sure, this seems much more simple, but it seemed ignored after I did it. Perhaps there was something I did wrong. At the beginning (I mean when beginning this thread) eudora.ini was write-protected, so perhaps I did not insist enough on disabling SSL after removing the protection on it. I found no answer at that moment, so I tried what I could, based on an association of ideas, and happened to be able to download my mail, which was the aim. So, by a way that is not the documented one, I happened to update the certificates, and be able to use Eudora again. You think it would be better I verify that roocerts.p7b is write-protected again ? Important or more for fun ?
From: John H Meyers on 11 Oct 2007 20:01 On Thu, 11 Oct 2007 14:32:25 -0500: >> Setting your options to not even use SSL is of course yet another way >> to bypass all SSL and certificate issues, without needing to remove >> any read-only attributes or rename any "root" certificate file. > For sure, this seems much more simple, but it seemed ignored after I did it. > Perhaps there was something I did wrong. "Checking mail" and "Sending mail" each have an independent SSL option, so examine both to see whether both were set to not use SSL. > At the beginning (I mean when beginning this thread) eudora.ini was > write-protected, so perhaps I did not insist enough on disabling SSL > after removing the protection on it. Indeed, "changes" to options will be silently ignored and not saved if Eudora.ini is read-only (a "save" normally occurs every time you even switch between option categories, not just at the end when you click OK, so changing to another option category and then back is one way to see whether your change has really been saved). > I happened to update the certificates, and be able to use Eudora again. When you "approve" (or "trust") a mail server certificate whose signature can not be verified via a "root" (CA) certificate, the server certificate is stored into the "usercerts.p7b" file, as previously indicated; the different "rootcerts.p7b" file which you said you adjusted is not altered (examine the "last modified" date/time of each file). Curiously, I also have a "RootCerts" folder in my Application (programs) directory (version 7 only), whose files all have a newer date than the "rootcerts.p7b" file; I don't remember whether these were installed with Eudora, or whether I exported them myself. If these were installed separately, I wonder whether they correspond with the "rootcerts.p7b" file? > You think it would be better I verify that roocerts.p7b > is write-protected again? Important or more for fun? It should not matter to the program, but being read-only helps to better guard against inadvertent deletion, moving, or renaming; has anyone long used any GUI system, without at some time having some accidental mouse click do something that shouldn't have been done, like "losing" an important mail message into some folder we can't find again? ;-) --
From: Gloops on 14 Oct 2007 10:34
John H Meyers a écrit, le 12/10/2007 02:01 : > "Checking mail" and "Sending mail" each have an independent SSL option, > so examine both to see whether both were set to not use SSL. This can be a way of exploration, although I only receive mails with Eudora. >> I happened to update the certificates, and be able to use Eudora again. > > When you "approve" (or "trust") a mail server certificate whose signature > can not be verified via a "root" (CA) certificate, the server certificate > is stored into the "usercerts.p7b" file, as previously indicated; > the different "rootcerts.p7b" file which you said you adjusted > is not altered (examine the "last modified" date/time of each file). It is right that I have no new rootcerts.p7b So, nothing to write-protect again :) |