<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: 1999/06/25 18:12:02 $
+<td width="30%" align=right>$Date: 1999/08/21 06:04:18 $
</table>
<HR>
<H1>Frequently Asked Questions About Fetchmail</H1>
<a href="#G12">G12. Is fetchmail Y2K-compliant?</a><br>
-
<h1>Build-time problems:</h1>
<a href="#B1">B1. Lex bombs out while building the fetchmail lexer.</a><br>
<a href="#R6">R6. Fetchmail hangs when used with pppd.</a><br>
<a href="#R7">R7. Fetchmail randomly dies with socket errors.</a><br>
<a href="#R8">R8. Fetchmail running as root stopped working after an OS upgrade</a><br>
+<a href="#R9">R9. Fetchmail is timing out after fetching certain
+messages but before deleting them</a><br>
<h1>Disappearing mail</h1>
multi-platform user community has shown that fetchmail is as near
bulletproof as the underlying protocols permit.<p>
+Fetchmail is licensed under the <a
+href="http://gnu.org//copyleft/gpl.html">GNU General Public
+License</a>.<p>
+
If you found this FAQ in the distribution, see the README for fetchmail's
full feature list.<p>
sustained load of a high-volume remote mail server. Even Microsoft
itself knows better than to try this; their own Hotmail service runs
over Solaris! For extended discussion, see John Kirch's excellent <a
-href="http://www.kirch.net/unix-nt.html">white paper</a> on Unix
+href="http://unix-vs-nt.org/kirch/">white paper</a> on Unix
vs. NT performance.<P>
You can find sources for IMAP software at <a
<hr>
<h2><a name="F2">F2. The .fetchmailrc parser won't accept my all-numeric user name.</a></h2>
-So put string quotes around it. :-)<p>
+Either upgrade to a post-5.0.5 fetchmail or put string quotes around it. :-)<p>
+
+The configuration file parser in older fetchmail versions treated any
+all-numeric token as a number, which confused it when it was
+expecting a name. String quoting forces the token's class.<p>
-The configuration file parser treats any all-numeric token as a
-number, which will confuse it when it's expecting a name. String
-quoting forces the token's class.<p>
+The lexical analyzer in 5.0.6 and beyond is smarter and assumes
+any token following "username" or "password" is a string.
<hr>
<h2><a name="F3">F3. The .fetchmailrc parser won't accept my host or username beginning with `no'.</a></h2>
-You're caught in an unfortunate crack between the newer-style syntax
-for negated options (`no keep', `no rewrite' etc.) and the older style
-run-on syntax (`nokeep', `norewrite' etc.).<p>
+See <a href="#F2">F2</a> You're caught in an unfortunate crack between
+the newer-style syntax for negated options (`no keep', `no rewrite'
+etc.) and the older style run-on syntax (`nokeep', `norewrite'
+etc.).<p>
-You can work around this easily. Just put string quotes around your
+Upgrade to a 5.0.6 or later fetchmail, or put string quotes around your
token.<p>
-I haven't fixed this because there is no good fix for it short of
-implementing a token pushback stack in the lexer. That's more
-additional complexity than I'm willing to add to banish a very
-marginal bug with an easy workaround.<p>
-
<hr>
<h2><a name="F4">F4. I'm migrating from popclient. How do I need to modify my .poprc?</a></h2>
accomplish this. Thank James Laferriere <babydr@nwrain.net> for
it.<p>
+Some people start up and shut down fetchmail using the ppp-up and
+ppp-down scripts of pppd.<p>
+
<hr>
<h2><a name="C3">C3. How do I know what interface and address to use with --interface?</a></h2>
fault of our own, and someone informs us of their location, we can
provide the URL pointing to archive sites outside of the U.S.<P>
-Newer versions of the SSL patches make appear in the `incoming' directory
+Newer versions of the SSL patches make appear in the `new' directory
and stay there a while until they can be processed and moved to the SSL
-directory. Check for patches in `incoming' if you do not find patches
+directory. Check for patches in `new' if you do not find patches
for the latest fetchmail release.<P>
<hr>
</pre>
<hr>
-<a name="R8">R8. Fetchmail running as root stopped working after an OS upgrade</a>/h2>
+<a name="R8">R8. Fetchmail running as root stopped working after an OS upgrade</a></h2>
In RH 6.0, the HOME value in the boot-time root environment changed
from /root to / as the result of a change in init. Move your
.fetchmailrc or use a -f option to explicitly point at the file.
-(Oddly, a similar problem has been reported from Debian systems)<P>
+(Oddly, a similar problem has been reported from Debian systems.)<P>
+
+<hr>
+<h2><a name="#R9">R9. Fetchmail is timing out after fetching certain
+messages but before deleting them</a></h2>
+
+There's a TCP/IP stalling problem under Redhat 6.0 (and possibly other
+recent Linuxes) that can cause this symptom. Brian Boutel writes:<p>
+
+<blockquote>
+TCP timestamps are turned on on my Linux boxes (I assume it's now the
+default). This uses 12 extra bytes per segment.
+When the tcp connection starts, the other end agrees a MSS of 1460,
+and then fragments 1460 byte chunks into 1448 and 12, because
+is is not allowing for the timestamp.<p>
+
+Then, for reasons I can't explain, it waits a long time (typically 2
+minutes) after the ack is sent before sending the next (fragmented)
+packet. Turning off tcp timestamps avoids the fragmentation and
+restores normal behaviour. To do this, [execute]<p>
+
+echo 0 > /proc/sys/net/ipv4/tcp_timestamps<p>
+
+I'm still unclear about the details of why this is happening. At least
+[now] I am now getting good performance and no queue blocking.
+</blockquote>
<hr>
<h2><a name="D1">D1. I think I've set up fetchmail correctly, but I'm not getting any mail.</a></h2>
<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: 1999/06/25 18:12:02 $
+<td width="30%" align=right>$Date: 1999/08/21 06:04:18 $
</table>
<P><ADDRESS>Eric S. Raymond <A HREF="mailto:esr@thyrsus.com"><esr@snark.thyrsus.com></A></ADDRESS>