]> Pileus Git - ~andy/fetchmail/blobdiff - fetchmail-FAQ.html
Fix a compilation screwup.
[~andy/fetchmail] / fetchmail-FAQ.html
index 2be323df3963c9225cb59a870087986b9d11a166..4f66e801bdf3ead142f5269791e8cffa65e59dcc 100644 (file)
@@ -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: 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>
@@ -40,7 +40,6 @@ IP address?</a><br>
 
 <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>
@@ -101,6 +100,8 @@ IP address?</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>
 
@@ -165,6 +166,10 @@ quality you can have.  Extensive peer review by a large,
 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>
 
@@ -346,7 +351,7 @@ broken (see item <a href="#S2">S2</a>) and NT cannot handle the
 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
@@ -666,27 +671,26 @@ Do similarly for any `<CODE>monitor</CODE>' or `<CODE>batchlimit</CODE>' options
 <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>
 
@@ -820,6 +824,9 @@ you can add to your .bash_login and .bash_logout profiles that will
 accomplish this.  Thank James Laferriere &lt;babydr@nwrain.net&gt; 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>
 
@@ -1682,9 +1689,9 @@ U.S. at this time, if the patches do leak out of the U.S. through no
 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>
@@ -1842,12 +1849,37 @@ option values that work:<P>
 </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 &gt; /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>
@@ -2425,7 +2457,7 @@ inactivity timeout.<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: 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">&lt;esr@snark.thyrsus.com&gt;</A></ADDRESS>