Improvements re Slow SSL (and typing)?

[John H Meyers]

It's finally happened -- someone has sent me
a long, anonymous letter in the mail (snail mail!)
with detailed orders for me to follow!

Should I notify the authorities?

Actually, what this letter wants, of all things,
is for me to notify Eudora users about a suggestion
for setting the "Compatibility mode" property of Eudora.exe
(which you can also set via any shortcut for the program),
as a potential work-around for the issue of
"long delay on first SSL connection" in Eudora
(possibly for "slow typing" as well).

The anonymous informant said that even with Eudora version 7.1.0.9,
there were no such delays when using it on a Windows 98 system,
which gave him/her the idea to try to use "Compatibility mode"
when running the same Eudora on XP/SP3 (Pentium 3, 1 GHz).

Yes, this is for real -- I really got such a letter,
and I have dutifully tried out its suggestions --
not on my own every day "real" Eudora setup,
but by having Eudora start up
using an experimental separate mail folder,
in my Windows XP/SP2 system running on Intel CPU E2180 (2 GHz)

Here are my results, for what happens on an initial SSL connection
using "Required, Alternate Port" for "Secure Sockets when Receiving"

Compatibility mode Results

None (native XP) 7 seconds delay on first SSL with 7.1.0.9
No delay with version 6.2.5.6

Windows 2000 7 seconds delay on first SSL with 7.1.0.9
No delay with version 6.2.5.6

Windows NT4 (SP5) 7 seconds delay on first SSL with 7.1.0.9
No delay with version 6.2.5.6
(anonymous informant claims no delay with 7.1.0.9 on P3 w XP/SP3)

Windows 98/ME No delay, even with version 7.1.0.9

Windows 95 No delay, even with version 7.1.0.9

Although timings are not perfectly uniform,
due to ever changing and uncontrollable circumstances,
this general pattern seems to recur when repeating all the tests.

Okay, I'm surprised and impressed!

However, as my anonymous informant also told me,
setting the compatibility mode to various older Windows versions
may also have other effects, such as possibly causing something else
not to work (I experienced a single crash during all of this,
where Windows informed me that Eudora had to close, etc.;
the anonymous informant said that some mail "got stuck inside Eudora
and not deposited in the In box without some manual fiddling" for Win98
compatibility mode, which fixed itself in Win NT4/SP5 compatibility mode).

It is also possible that whatever initial activity is suppressed
in "older Windows versions" compatibility mode
might actually reduce security of the connection --
it is important, for example, to effectively "randomize"
the initial state of encrypted sessions, otherwise
you do not really have "128 bit security"
if the "session key" is much easier than this to predict,
and I have suspected that this has something to do with
why there is an initial delay, just one time,
at least on newer operating systems,
which may provide their own "random number generation" services.

What does "compatibility mode" really do?

I believe that when a program tests to see
under which version of Windows it is running,
it causes Windows to report itself to the program
as being the version that you force it to say,
and if the application program was written to act differently
under different Windows versions, then this may change
the behavior of the program, or which Windows features it uses, etc.

As to whether the "compatibility mode" setting
also changes how Windows performs certain things for the application,
I do not know. This should be regarded as an experimental area,
and you might want to back up your entire mail "Data" folder
(e.g. to a "zip" file, which also compresses all the data)
before proceeding to experiment with compatibility settings.

Under XP, there is also a compatibility property
"Turn off advanced text services for this program";
if typing plain text is being slowed down,
perhaps one should mark this box, and see whether it helps.

Here are compatibility mode settings for Vista or Windows 7:

http://www.howtogeek.com/howto/windows-vista/using-windows-vista-compatibility-mode/
http://windows.about.com/od/windowsosversions/ss/program_compatibility_mode.htm

If this helps you to remain compatible with and faithful to Eudora,
be sure to thank the anonymous contributor; if this speeds up Eudora
but disturbs her behavior in any other way, then I guess it was wise
for said person to remain anonymous :)

--

[John H Meyers]

If there is a "first SSL connection delay" in a Eudora session,
the length of the delay will depend on CPU speed and other factors,
with CPU speed certainly determining the minimum possible delay,
because one CPU is kept 100% occupied during this delay.

The patience of the server being contacted
then determines whether the connection will succeed anyway,
simply slowed down by the delay,
or whether the remote server will simply not wait,
"slam the phone down" on the caller,
and thus disconnect the session from the remote side.

In either case, barring any other untoward events,
all subsequent SSL connections succeed, with no delays.

Faster computers even succeed on the very first try,
after a little pause, while slower computers may fail on the first try --
very slow computers pretty nearly 100% of the time.

But no harm is done in any case -- when we try to strike a match,
a nice, dry, well made matchbook may let us light the match
on the first stroke, every time, while a worn or slightly damp
matchbook may require some re-trying. Luckily, with Eudora,
one always succeeds, either on the first or second try
after first launching Eudora, and then every time thereafter,
so long as Eudora remains running continuously.

If we want to even eliminate the chance of a first stroke "miss,"
on a slower computer, we can try fiddling with compatibility settings,
mindful of the cautions expressed earlier.

--