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
>
>
>



Reply via email to