Remove the fetchall kluge.

svn path=/trunk/; revision=1810

4 files changed, 24 insertions, 35 deletions

diff --git a/NEWS b/NEWS
index 350f2dff..c8225328 100644
--- a/NEWS
+++ b/NEWS
@@ -7,6 +7,10 @@
 				Release Notes:
 
 ------------------------------------------------------------------------------
+fetchmail-4.4.8 ():
+* Removed fetchall side-effect kluge, now that we knowe how to make TOP work
+  with qpopper 2.3+.
+
 fetchmail-4.4.7 (Sat May 23 08:26:58 EDT 1998):
 * FEATURE FREEZE IS NOW IN EFFECT!  No new features until after 4.5.0.
 * Better workaround for TOP bounds-checking in qpopper 2.3+.
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 @@
 <table width="100%" cellpadding=0><tr>
 <td width="30%">Back to <a href="index.html">Fetchmail Home Page</a>
 <td width="30%" align=center>To <a href="/~esr/sitemap.html">Site Map</a>
-<td width="30%" align=right>$Date: 1998/05/23 05:06:13 $
+<td width="30%" align=right>$Date: 1998/05/23 18:25:18 $
 </table>
 <HR>
 <H1>Frequently Asked Questions About Fetchmail</H1>
@@ -1768,24 +1768,22 @@ no effect on the contents of the logfile if it already exists).<P>
 <hr>
 <h2><a name="X5">X5. Using POP3, retrievals seems to be fetching too much!</a></h2>
 
-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).<P>
+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).<P>
 
-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.<P>
+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.<P>
 
-To work around it, set the <code>fetchall</code> option.  Under POP3
-only, this now has the side effect of forcing RETR use.<P>
+Fix: Upgrade to a later version of fetchmail.<P>
 
-(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.)<P>
+Workaround: set the <code>fetchall</code> option.  Under POP3 in these
+fetchmail version only, this had the side effect of forcing RETR
+use.<P>
 
 <hr>
 <h2><a name="O2">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.<P>
 <table width="100%" cellpadding=0><tr>
 <td width="30%">Back to <a href="index.html">Fetchmail Home Page</a>
 <td width="30%" align=center>To <a href="/~esr/sitemap.html">Site Map</a>
-<td width="30%" align=right>$Date: 1998/05/23 05:06:13 $
+<td width="30%" align=right>$Date: 1998/05/23 18:25:18 $
 </table>
 
 <P><ADDRESS>Eric S. Raymond <A HREF="mailto:esr@thyrsus.com">&lt;esr@snark.thyrsus.com&gt;</A></ADDRESS>
diff --git a/fetchmail.man b/fetchmail.man
index 7d818149..7c10341c 100644
--- a/fetchmail.man
+++ b/fetchmail.man
@@ -115,9 +115,6 @@ Retrieve both old (seen) and new messages from the mailserver.  The
 default is to fetch only messages the server has not marked seen.
 Note that POP2 retrieval behaves as though --all is always on (see
 RETRIEVAL FAILURE MODES below) and this option does not work with ETRN.
-This option has the side effect or forcing POP3 retrieval to use RETR
-rather than TOP for retrieval, working around buggy implementations
-of the latter in some POP3 servers.
 .TP
 .B \-k, --keep
 (Keyword: keep)
diff --git a/pop3.c b/pop3.c
index 7dce9264..5fcdc6ab 100644
--- a/pop3.c
+++ b/pop3.c
@@ -530,27 +530,17 @@ static int pop3_fetch(int sock, struct query *ctl, int number, int *lenp)
      * craps out during the message, it will still be marked `unseen' on
      * the server.
      *
+     * However...*don't* do this if we're using keep to suppress deletion!
+     * In that case, marking the seen flag is the only way to prevent the
+     * message from being re-fetched on subsequent runs.
+     *
      * The line count passed is the maximum value of a twos-complement
      * signed integer minus 1 (we take advantage of the fact that, according
      * to all the POP RFCs, "if the number of lines requested by the
      * POP3 client is greater than than the number of lines in the
      * body, then the POP3 server sends the entire message.").
-     *
-     * However...*don't* do this if we're using keep to suppress deletion!
-     * In that case, marking the seen flag is the only way to prevent the
-     * message from being re-fetched on subsequent runs.
-     *
-     * Also suppress TOP if fetchall is on.  This is a kludge to get
-     * around a really obnoxious bug in qpopper 2.41 beta 1 that must
-     * have been introduced sometime after the 2.2 I tested with (Erwan
-     * Mas claims it was in 2.3).  The newer version doesn't bounds-check TOP
-     * requests to clip them at the next end of message.  Grrrrr...
-     *
-     * (Erwan MAS <mas@nic.fr> thinks this was actually due to the TOP
-     * argument overflowing and recommended I decrement it.  Hmmm...
-     * maybe we can take out the fetchall kluge?)
      */
-    if (ctl->keep || ctl->fetchall)
+    if (ctl->keep)
 	gen_send(sock, "RETR %d", number);
     else
 	gen_send(sock, "TOP %d 2147483646", number);