Let me step back a bit. Exactly _which_ clients are you interested in getting Kerberos authentication to work with qpopper? I ask because that has bearing on which protocol you want to support.
Like I said, part of the reason I let that code languish was that I didn't see a need any more for it. >Well, I was able to create my own patches that seem to work, but I >haven't been able to fully test them yet. I was just wondering if >anyone had patches before I went and re-invented the wheel. (I am >attaching them with this email.) Of course, what you're saying brings >up some *really* interesting questions. Are you saying that qpopper >does *not* need the --with-kerberos flag when running configure in order >to use GSSAPI protocol? That is correct. >If not, I take it that the purpose of the >--with-kerberos flag is to support the KPOP type authentication. Yes, that is also correct. >(Please pardon me if that is a re-statement of what you said above.) If >one does not need to use the --with-kerberos flag when running the >configure script, where can I find documentation on how to use >Kerberos/GSSAPI authentication? Ah, okay, well, that is perhaps one area that needs to be addressed a bit. Qpopper gets Kerberos/GSSAPI by virtue of the Cyrus-SASL library. That includes support for all SASL mechanisms supported by Cyrus-SASL, one of which is GSSAPI. In hindsight, part of me maybe thinks it would have been better to call the GSSAPI directly, as getting Cyrus-SASL working can be a bitch and a half (if you use one of the prepackaged builds that come with Linux, for example, it shouldn't be an issue). However, most of the problems I see people have with Cyrus-SASL is with saslauthd and database conflicts, and those are not an issue with the GSSAPI mechanism. There is documentation in the Qpopper manual about the various options that affect SASL. The only thing you need to know regarding GSSAPI is that the service principal for Kerberos is "pop/[EMAIL PROTECTED]". --Ken
