aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorEric S. Raymond <esr@thyrsus.com>1998-05-16 19:17:42 +0000
committerEric S. Raymond <esr@thyrsus.com>1998-05-16 19:17:42 +0000
commitf35ea15b76a5e1883e0c9fe259a3572f8d75bea7 (patch)
tree7e777440ec47c65fcb88d2ee2c45c2be3f524f3e
parentf97a589229104ed5ebf951d199162dd68587e537 (diff)
downloadfetchmail-f35ea15b76a5e1883e0c9fe259a3572f8d75bea7.tar.gz
fetchmail-f35ea15b76a5e1883e0c9fe259a3572f8d75bea7.tar.bz2
fetchmail-f35ea15b76a5e1883e0c9fe259a3572f8d75bea7.zip
Better fix for qpopper TOP problem.
svn path=/trunk/; revision=1790
-rw-r--r--NEWS5
-rw-r--r--fetchmail-FAQ.html11
-rw-r--r--pop3.c14
3 files changed, 22 insertions, 8 deletions
diff --git a/NEWS b/NEWS
index 2228f079..dd2da574 100644
--- a/NEWS
+++ b/NEWS
@@ -7,6 +7,11 @@
Release Notes:
------------------------------------------------------------------------------
+fetchmail-4.4.6 ()
+* Better workaround for TOP bounds-checking in qpopper 2.3+.
+
+There are 270 people on fetchmail-friends and 212 on fetchmail-announce.
+
fetchmail-4.4.6 (Sat May 16 14:16:49 EDT 1998)
* Fix a bug introduced by my 4.4.5 bug-fix release :-(
* Make the internal line buffer eight times longer to cope with idiot
diff --git a/fetchmail-FAQ.html b/fetchmail-FAQ.html
index 5f120d16..010275c1 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/14 01:35:48 $
+<td width="30%" align=right>$Date: 1998/05/16 19:17:42 $
</table>
<HR>
<H1>Frequently Asked Questions About Fetchmail</H1>
@@ -1774,11 +1774,16 @@ 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).<P>
+does not). It's been reported to me that the logic changed in 2.3.<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>
+(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 may have
+fixed this.)<P>
+
<hr>
<h2><a name="O2">O2. Every time I get a POP or IMAP message the header
is dumped to all my terminal sessions.</a></h2>
@@ -1910,7 +1915,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/14 01:35:48 $
+<td width="30%" align=right>$Date: 1998/05/16 19:17:42 $
</table>
<P><ADDRESS>Eric S. Raymond <A HREF="mailto:esr@thyrsus.com">&lt;esr@snark.thyrsus.com&gt;</A></ADDRESS>
diff --git a/pop3.c b/pop3.c
index 09565c33..7dce9264 100644
--- a/pop3.c
+++ b/pop3.c
@@ -531,7 +531,7 @@ static int pop3_fetch(int sock, struct query *ctl, int number, int *lenp)
* the server.
*
* The line count passed is the maximum value of a twos-complement
- * signed integer (we take advantage of the fact that, according
+ * 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.").
@@ -542,14 +542,18 @@ static int pop3_fetch(int sock, struct query *ctl, int number, int *lenp)
*
* 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. The
- * newer version doesn't bounds-check TOP requests to clip them
- * at the next end of message. Grrrrr...
+ * 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)
gen_send(sock, "RETR %d", number);
else
- gen_send(sock, "TOP %d 2147483647", number);
+ gen_send(sock, "TOP %d 2147483646", number);
if ((ok = pop3_ok(sock, buf)) != 0)
return(ok);