Quoting from Matthias Andree's mail on Fri, Oct 17, 2003 at 12:17:00AM +0200:
This is harmful for POP3:
An immediate fix is to add "fetchsizelimit 1" to your rc file explicitly.
Could you specify what exact protocol you are using?
I suggest the enclosed patch to pop3.c.
The real fix is to specify more protocols in the code in driver.c where
fetchsizelimit is set. There, only "pop3" is listed. It should list "apop" and
"rpop" also.
NOTE that the current code need optimization, if I have unseen articles
3 and 47, fetchmail will happily request LIST for articles 3...47 rather
than just 3 and 47. In cases where the message numbers are far apart,
this involves considerable overhead - which could be alleviated by
pipelining the list commands, which needs either asynchronous reading
while sending the commands, or knowing the send buffer, to avoid
deadlocks. Unfortunately, I don't have the time to delve deeper into the
code and look around.
Once 'fetchsizelimit' is set to 1, optimization is done!
Please try this patch;
===================================================================
diff -Naur fetchmail-6.2.5.orig/driver.c fetchmail-6.2.5/driver.c
--- fetchmail-6.2.5.orig/driver.c 2003-10-16 00:52:31.000000000 +0530
+++ fetchmail-6.2.5/driver.c 2003-10-17 11:24:27.000000000 +0530
@@ -429,8 +429,11 @@
/* 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)
+ switch (ctl->server.protocol)
+ {
+ case P_POP3: case P_APOP: case P_RPOP:
fetchsizelimit = 1;
+ }
/* Time to allocate memory to store the sizes */
xalloca(msgsizes, int *, sizeof(int) * fetchsizelimit);
===================================================================
--
Sunil Shetye.