K5Client support broken when using KClient 3.0 compatibility API?

[Steven Michaud]

I'm trying to figure out why, in the latest version of Eudora for
Classic Mac OS (5.2 beta), "K5Client POP" no longer works.

I'm using KFM 4.0.3.  And yes, I did follow the "Read Me" file's
instructions to put an empty "k5cl" resource with ID 128 into the
"Kerberos Preferences" files (in "System Folder : Preferences" and
"System Folder : Application Support : Kerberos").  I also tested
Eudora 5.1 for Classic Mac in this environment, and it worked fine.

When I check my mail with one of the Eudora 5.2 betas, if I don't
already have a TGT the Kerberos control panel opens up and I get one.
But then Eudora fails with the error message "Cannot communicate with
Kerberos".  When I sniff the traffic to the mail server, I see that
Eudora opens a socket and then immediately closes it again, without
sending any traffic.

My mail server is Qpopper 4.0.3, compiled with Kerberos 5 support
("--with-Kerberos5"), but using its "Kerberos 4 compatibility" mode
("KRB5_KRB4_COMPAT").  Interestingly, everything works fine once I
turn on Kerberos 4 support at the client and on my KDC -- I don't need
to make any changes to Qpopper.

Looking at the Eudora 5.1 and 5.2 executables ("Eudora") in a hex
editor, I notice that 5.1 uses calls from the KClient 1.X API
(e.g. KClientNewSession, KClientGetTicketForServiceWithChecksum,
KClientDisposeSession).  So, presumably, did previous versions.  But
5.2 uses calls from the KClient 3.0 "compatibility" API
(e.g. KClientNewSessionCompat,
KClientGetTicketForServiceWithChecksumCompat,
KClientDisposeSessionCompat).

Could using the KClient 3.0 shared libraries have broken KFM's
K5Client support?