Re: .pop lockfile

[Alan Brown]

On Fri, 17 Dec 2004, Lisa Casey wrote:

> Regarding .pop lock files: if most of your customers are using an MS mail
> client (Outlook Express, Outlook), try  increasing the server timeout in
> their settings. Microsoft's  default is one minute. We have found that, by
> increasing the  server timeout on their end we get a lot fewer pop locks.

In many cases it is easier to remove one's eyes with a rusty spoon than
to walk a customer through changing their settings.

This is particularly so with those insisting on using Outlook/OE


Many places have banned these packages for security reasons, many ISPs
have issued security warnings about these programs.

In preferenece to getting someone to change their timeouts, consider
migrating them to something more secure such as Thunderbird.

Re: .pop lockfile

[Lisa Casey]

Hi,

Regarding .pop lock files: if most of your customers are using an MS mail
client (Outlook Express, Outlook), try  increasing the server timeout in
their settings. Microsoft's  default is one minute. We have found that, by
increasing the  server timeout on their end we get a lot fewer pop locks.

Lisa Casey
Netlink 2000, Inc.

- Original Message - 
From: "Randall Gellens" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Subscribers of Qpopper"
<[EMAIL PROTECTED]>
Sent: Thursday, December 16, 2004 7:45 PM
Subject: Re: .pop lockfile


> At 10:48 AM + 12/2/04, <[EMAIL PROTECTED]> wrote:
>
> >  Is there a quick way to unlock a users mailbox after a failed pickup of
> >  emails? Currently, we have to tell our users if this happens they must
> >  wait approximately 20 mins for the mailbox to unlock itself and some
are
> >  finding this unacceptable.
> >
> >  We are running qpopper 4.05 on redhat9. It is also run in server mode.
>
> Try 4.0.6b3 (available at
> <ftp://ftp.qualcomm.com/eudora/servers/unix/popper/beta>).  It
> includes a work-around for a situation seen on some Linux systems
> where the timeout signal gets masked.  This might help in your case.
> Please report back.
> -- 
> Randall Gellens
> Opinions are personal;facts are suspect;I speak for myself only
> -- Randomly-selected tag: ---
> Just because your doctor has a name for your condition doesn't mean he
> knows what it is.
>

Re: .pop lockfile

[Randall Gellens]

At 10:48 AM + 12/2/04, <[EMAIL PROTECTED]> wrote:
 Is there a quick way to unlock a users mailbox after a failed pickup of
 emails? Currently, we have to tell our users if this happens they must
 wait approximately 20 mins for the mailbox to unlock itself and some are
 finding this unacceptable.
 We are running qpopper 4.05 on redhat9. It is also run in server mode.
Try 4.0.6b3 (available at 
).  It 
includes a work-around for a situation seen on some Linux systems 
where the timeout signal gets masked.  This might help in your case. 
Please report back.
--
Randall Gellens
Opinions are personal;facts are suspect;I speak for myself only
-- Randomly-selected tag: ---
Just because your doctor has a name for your condition doesn't mean he
knows what it is.

Re: .pop lockfile

[Ken A]

AFAIK, as long as the user isn't still connected, and the size of the 
$tempdrop/.user.pop file is 0 bytes, you can simply delete the .pop and 
.lock files. Qpopper might generate an error, but the poplock is cleared 
by force. If the user is still connected, or connects while you are 
'fixing' it, you can loose all of the spool file this way though. :-(

Ken
[EMAIL PROTECTED] wrote:
Hello,
I have checked the FAQ for this answer but could not find it :(
Is there a quick way to unlock a users mailbox after a failed pickup of
emails? Currently, we have to tell our users if this happens they must
wait approximately 20 mins for the mailbox to unlock itself and some are
finding this unacceptable. 

We are running qpopper 4.05 on redhat9. It is also run in server mode.
Thanks
Nick 

Re: .pop lockfile

[Ken Hohhof]

Try entering from the command line and also adding to /etc/rc.d/rc.local:
echo "5" > /proc/sys/net/ipv4/tcp_retries2
The Linux default value is 15 I think.  This will speed up the release of 
the mailbox lock by reducing the number of times the OS retries the TCP 
connection before giving up on it.  If you reduce it much below 5 you risk 
dropping connections that are experiencing packet loss, so this is a tradeoff.

This should only happen to customers who are on dialup links that drop 
unintentionally, or who get impatient and disconnect from the Internet 
without closing out the POP3 session, or who have misbehaving antivirus 
software.

The only other fix I know of, other than reducing the number of TCP 
retries, is to put the problem users on webmail which will always finish 
the POP3 session gracefully even if the web client disconnects.

Is there a quick way to unlock a users mailbox after a failed pickup of
emails? Currently, we have to tell our users if this happens they must
wait approximately 20 mins for the mailbox to unlock itself and some are
finding this unacceptable.
We are running qpopper 4.05 on redhat9. It is also run in server mode.