We run clearopensmtp. We have not changed the cronjob since updating to 5.3.29 from 5.2.1, so if it needs to be changed, let me know. Here is the current crontab entry: 40 * * * * /home/vpopmail/bin/clearopensmtp 2>&1 > /dev/null
Now, I noticed this morning that it started doing this quickly after restarting qmail-pop3d instead of taking hours to start. Also, It is not taking long to authenticate (at least from the server point of view) because the logs show a successful login very quickly. For some reason, the client side just doesn't get the message that it has authenticated. One other thing that may be important: I changed the code to add the QMAILQUEUE varialble in open.smtp for qmail-scanner. It seems to be functioning fine, though. Trey Nolen > Check the roaming users setup. If it is turned on and clearopensmtp > is not run, tcprules will take longer and longer to build the > tcp.smtp.cdb file. > > Ken Jones > > On Wednesday 22 October 2003 8:11 am, Trey Nolen wrote: > > We upgraded to 5.3.29 and now, after a few hours, qmail-pop3d will fail. > > It is very weird, because in the logs, we get a successful login, but the > > client waits several seconds and then says that the password has failed and > > asks the user to retry. All other methods of authentication seem to be > > working (sqwebmail, imap, qmailadmin), although they are not used as often > > so the problem may not be coming up yet. Killing all the qmail-pop3d, > > qmail-popup, and the tcpserver processes that spawn qmail-pop3d and > > restarting them fixes the problem for a while. I'm not sure, but it > > *seems* like the authentication gets slower before it fails completely. I > > tried going back to 5.3.28 (we were on 5.2.1 before the upgrade) but the > > problem still persists. Our version of qmail-pop3d is not patched to > > support quotas, but we are not using quotas. We are using vpasswd > > authentication and roaming smtp. > > > > Thanks for any help. > > > > Trey Nolen > > >