Return-Path: Sender: To: CGatePro Date: Fri, 05 Feb 2010 07:34:21 -0800 Message-ID: X-Original-Return-Path: Received: from linweb.is.net.tr ([213.143.236.25] verified) by mail.stalker.com (CommuniGate Pro SMTP 5.3.2) with ESMTPS id 58657079 for CGatePro@mail.stalker.com; Thu, 04 Feb 2010 07:57:06 -0800 Received-SPF: none receiver=mail.stalker.com; client-ip=213.143.236.25; envelope-from=emre.aksoy@gentek.gen.tr Received: from [92.45.192.2] (helo=gentek.gen.tr) by linweb.is.net.tr with esmtpa (Exim 4.69) (envelope-from ) id 1Nd46h-0002Y1-Q6 for CGatePro@mail.stalker.com; Thu, 04 Feb 2010 17:59:03 +0200 Received: from [192.168.1.250] (account emre.aksoy@gentek.gen.tr) by gentek.gen.tr (CommuniGate Pro XIMSS 5.3.3d) with XIMSS id 1280053 for CGatePro@mail.stalker.com; Thu, 04 Feb 2010 17:57:58 +0200 X-Mailer: CommuniGate Pro Pronto 3.2 Subject: Re: RPOP giving up From: "Emre AKSOY" X-Original-To: "CommuniGate Pro Discussions" X-Original-Date: Thu, 04 Feb 2010 17:57:58 +0200 X-Original-Message-ID: Content-Type: text/plain;charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - linweb.is.net.tr X-AntiAbuse: Original Domain - mail.stalker.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gentek.gen.tr X-Source: X-Source-Args: X-Source-Dir: Hi everyone, It seems that the bug has not been properly fixed yet even on 5.3.2. If you set the system time to a future date the service continues to poll accounts, but if you revert the time back the service no more polls any account. I think this is a bug specific to v.5.3x (Technical Support) This is a bug confirmed for 5.3. It's already fixed for 5.3.1 release. ***We use RPOP to retrieve messages from some Internet based mailboxes. Recently users have been not getting new mail because their RPOP requests have stalled. After a failed attempt to connect to the ISP (presumably because their server is overloaded or something) RPOP seems to give up altogether, instead of retrying a few minutes later. This is specific to each user+connection. Other RPOP connections, even for the same user reschedule as normal. Is this normal behavior? Can I force CGP to keep retrying? Is it possible to reset the RPOP module periodically via the command line? (ie similar to what happens if you update the users RPOP config).***