1) If I compile openssl support in qpopper 4.0.4, it works if I run it on port 995 (ie. "alternate port" and not "stls"), and mostly works if I run it on port 110 ... except that a very few of our Eudora clients complain and refuse to connect on port 110. (most of our Eudora clients are just fine, though, and all of our other POP clients work perfectly)
2) If I disable SSL on port 110, then I get an odd behavior. The "stls" command generates an error that stls isn't enabled (I expect that), and then it disconnects the session (not at all what I expect). I don't know if clients will react well to that (ie. reconnect and not try stls again). 3) If I reconfigure/recompile without SSL support, I get a completely unacceptable situation: it behaves exactly the same as though I had disabled stls in the config file. That's completely wrong. If I don't enable SSL support in the configure/compile steps, then it should act like an older pop3 server that simply doesn't recognize the command (and, I'll note, under qpopper 3.1, if you generate the stls command, it simply says its an unrecognized command). Ideally, case #3 should create a popper that treats the stls command in the exact same manner that qpopper 3.1 did. It would be nice if case #2 did the same thing (I wouldn't have to have multiple binaries, just multiple config files). It would also be nice to know if Eudora handles the stls error in case #2 gracefully (so far, Eudora is always our main "problem child" when it comes to handling things gracefully ... it didn't work with qpopper3.1+stunnel, for example, unlike every decent pop client). Does anyone have a solution or work around for this? Other than "only use qpopper4.0.4 on the SPOP port, and keep using qpopper3.1 on the POP3 port" , which is our current plan. Does anyone know how various POP clients deal with the behavior of case #2 when they want stls, but get rejected and disconnected? Do they sucessfully retry without stls, or do they leave the user out to dry?
