At 13:15 20/09/02 -0700, John Rudd wrote: >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?
Uh oh, Groundhog day :) Please check the archive for recent messages from me (there aren't many) and Randell Gallens reply. The STLS command causing a disconnection when STLS is not compiled in is a bug that I ran into and worked around. Randell replied that yes it was a bug, so I presume at some point in the beta series of 4.0.5b it will get fixed. Regards, Simon
