From: Gloops on
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
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
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 :)