From owner-freebsd-bugs@FreeBSD.ORG Sun Mar 28 18:07:16 2004 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 794FB16A4CE for ; Sun, 28 Mar 2004 18:07:16 -0800 (PST) Received: from thalia.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id C611143D45 for ; Sun, 28 Mar 2004 18:07:12 -0800 (PST) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-a135.otenet.gr [212.205.215.135]) by thalia.otenet.gr (8.12.10/8.12.10) with ESMTP id i2T27587017774 for ; Mon, 29 Mar 2004 05:07:09 +0300 (EEST) Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.12.11/8.12.11) with ESMTP id i2SB5KO1093924 for ; Sun, 28 Mar 2004 14:05:20 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.gr (8.12.11/8.12.11/Submit) id i2SB5KIb093923; Sun, 28 Mar 2004 14:05:20 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sun, 28 Mar 2004 14:05:20 +0300 From: Giorgos Keramidas To: Stephen McKay Message-ID: <20040328110520.GA93846@gothmog.gr> References: <200403261523.i2QFNhGS044804@gothmog.gr> <20040327040256.GA95621@xor.obsecurity.org> <20040327054536.GA68587@gothmog.gr> <200403281007.i2SA7LJ7016369@dungeon.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403281007.i2SA7LJ7016369@dungeon.home> cc: freebsd-bugs@freebsd.org Subject: Re: fetchmail-6.2.5 bug in FreeBSD-current X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2004 02:07:16 -0000 On 2004-03-28 20:07, Stephen McKay wrote: > On Saturday, 27th March 2004, Giorgos Keramidas wrote: > >Looking more carefully at the check, I found out that you're absolutely > >right. The check's logic is fine as it is, it's the way that the > >pop3_getpartialsizes() function is called that is broken. > > When I ran into this problem, I found a patch that is supposed to do > the right thing (ie not try to fetch multiple sizes when that isn't > possible). I'm pretty sure I found it in the fetchmail list archives. > [...] But I didn't bother to try the patch since adding > "fetchsizelimit 1" to .fetchmailrc is a successful workaround. Oh well, that was *so* very on the spot. I searched for the patch and found a siggestion for fetchsizelimit = 1, along with a note that POP3 works fine -- it's only APOP and RPOP that are broken (I should have guessed after looking at the code of fetchmail/driver.c, but somehow I failed to remember that I'm using APOP). The solution suggested by Sunil Shetye who wrote the nearby parts of driver.c was to set fetchsizelimit to 1 OR change driver.c to make sure that fetchsizelimit is automagically set to 1 for APOP and RPOP too. The following little diff fixed things for me, without having to make any changes to existing config files of my accounts or the accounts of other people: %% --- driver.c.orig Sun Mar 28 13:29:15 2004 +++ driver.c Sun Mar 28 13:49:42 2004 @@ -429,7 +429,8 @@ /* for POP3, we can get the size of one mail only! Unfortunately, this * protocol specific test cannot be done elsewhere as the protocol * could be "auto". */ - if (ctl->server.protocol == P_POP3) + if (ctl->server.protocol == P_POP3 || ctl->server.protocol == P_APOP || + ctl->server.protocol == P_RPOP) fetchsizelimit = 1; /* Time to allocate memory to store the sizes */ %% Many thanks for pointing me to the right direction :-) - Giorgos