diff options
| -rw-r--r-- | NEWS | 4 | ||||
| -rw-r--r-- | fetchmail-FAQ.html | 32 | ||||
| -rw-r--r-- | fetchmail.man | 3 | ||||
| -rw-r--r-- | pop3.c | 20 |
4 files changed, 24 insertions, 35 deletions
@@ -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"><esr@snark.thyrsus.com></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) @@ -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); |