A response to the last thread "need help" reminded me of a question I've
been meaning to ask...
Is there a quick remedy to fixing a users mailbox when their connection is
terminated abnormally resulting in a lingering .username.pop lockfile?
Right now I just tell them to wait a short while, and the mailbox will
unlock itself. However, I'm waiting for the user that says "I need my mail
immediately!".
I've tried copying the .pop file back to the normal mail spool file and
deleting the lockfile, but that produced some strange results.
More specifically, I needed to check email from a remote location over a
dialup to find that someone sent an unwanted 5mb attachment. I terminated
the remote connection, copied the .pop lockfile back to the spool file,
deleted the lockfile, used an mua server-side to delete the email w/
attachment, then used my remote mua to check mail again just to find it was
downloading the same email w/ attachment that I thought I had removed.
Checking the mail spool directory again, I saw that the .pop lockfile was
recreated with the original filesize of the mail spool before removing the
attachment, even though the current spool file was considerably smaller in
size.
Did I miss a step, did I go about this the wrong way, or should I have never
even tried this in the first place?
Running Qpopper 3.1.2 via inetd on a RHL 6.1 box.
Thanks,
--
Brian Curtis