From 273ff7a0059deda40ec171db2c69f596e49302c3 Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Sat, 23 May 1998 18:25:18 +0000 Subject: Remove the fetchall kluge. svn path=/trunk/; revision=1810 --- fetchmail-FAQ.html | 32 +++++++++++++++----------------- 1 file changed, 15 insertions(+), 17 deletions(-) (limited to 'fetchmail-FAQ.html') diff --git a/fetchmail-FAQ.html b/fetchmail-FAQ.html index 0a6d1225..f185720b 100644 --- a/fetchmail-FAQ.html +++ b/fetchmail-FAQ.html @@ -10,7 +10,7 @@
Back to Fetchmail Home Page To Site Map -$Date: 1998/05/23 05:06:13 $ +$Date: 1998/05/23 18:25:18 $

Frequently Asked Questions About Fetchmail

@@ -1768,24 +1768,22 @@ no effect on the contents of the logfile if it already exists).

X5. Using POP3, retrievals seems to be fetching too much!

-This may happen in versions of fetchmail after 4.4.1, which use POP3's -TOP command rather than RETR in order to avoid marking the message -seen (leaving it unseen is helpful for later recovery if you lose your -connection in the middle of a retrieval).

+This may happen in versions of fetchmail after 4.4.1 and before 4.4.8. +Versions after 4.4.1 use POP3's TOP command rather than RETR, in order +to avoid marking the message seen (leaving it unseen is helpful for +later recovery if you lose your connection in the middle of a +retrieval).

-If your POP3 server fails to sanity-check TOP requests and clip them at -the next end-of-message, it will fetch the entire tail of the mailbox -starting with the current message. The qpopper 2.41 beta 1 server is -known to have this bug (though the qpopper 2.2 found on many Unixes -does not). It's been reported to me that the logic changed in 2.3.

+Versions of fetchmail from 4.4.2 through 4.4.7 had a bad interaction +with Eudora qpopper versions 2.3 and later. The TOP bounds check was +fooled by an overflow condition in the TOP argument. Decrementing the +TOP argument in 4.4.7 fixed this.

-To work around it, set the fetchall option. Under POP3 -only, this now has the side effect of forcing RETR use.

+Fix: Upgrade to a later version of fetchmail.

-(It is possible this tip is no longer necessary. At least one tester -has claimed that the bounds check works but was fooled by an overflow -condition in the TOP argument. Decrementing the argument in 4.4.7 may have -fixed this, in which case this FAQ item will soon go away.)

+Workaround: set the fetchall option. Under POP3 in these +fetchmail version only, this had the side effect of forcing RETR +use.

O2. Every time I get a POP or IMAP message the header @@ -1918,7 +1916,7 @@ Re-ordering messages is a user-agent function, anyway.

Back to Fetchmail Home Page To Site Map -$Date: 1998/05/23 05:06:13 $ +$Date: 1998/05/23 18:25:18 $

Eric S. Raymond <esr@snark.thyrsus.com>
-- cgit v1.2.3