-Otherwise it is going keep increasing the packet counters that fetchmail
-relies upon, triggering fetchmail into polling after its own delay
-interval and thus preventing the pppd link from ever reaching its
-inactivity timeout.</p>
-
-<hr>
-<h2><a name="O9">O9. Why does fetchmail keep retrieving the same messages
-over and over?</a></h2>
-
-<p>First, check to see that you haven't enabled the <cite>keep</cite>
-and <cite>fetchall</cite> option. If you have, turn <cite>keep</cite> off.</p>
-
-<p>There are various forms of lossage involving the POP3 UIDL feature
-that can lead to all your old messages being seen again after a line
-drop. I have given up trying to fix these, as the UIDL code breaks
-worse every time I touch it. The problem is fundamental; maintaining
-and garbage-collecting the right kind of client-side state is just
-hard. Whoever put UIDLs in RFC1725 and removed LAST should be hung
-up by his thumbs and whipped with scorpions. The right answers are
-either (a) live with the occasional breakage, (b) switch to IMAP4,
-or (c) fix the code yourself and send me a patch. Unless you choose
-(c), I don't want to hear about it.</p>
-
-<p>This can also happen when some other mail client is logged in to your
-mail server, if it uses a simple exclusive-locking scheme (and many,
-especially most POP3 servers, do exactly that). Your fetchmail is
-able to retrieve the messages, but because the mailbox is write-locked
-by the other instance yours can neither mark messages seen or delete them.
-The solution is to either (a) wait for the other client to finish, or (b)
-terminate it.</p>
-
-<p>James Stevens <James.Stevens@kyzo.com> writes:<p>
-
-<em>
-<p>We had a Linux box dialing the Net and collecting mail from an NT POP3
-server. Fetchmail was correctly collecting and deleting each e-mail
-one by one. However,the dial-up connection was very unreliable and
-would often just drop out in the middle of a session.</p>
-
-<p>Interestingly, unless the TCP POP3 connection was terminated normally
-(I guess with a POP3 "QUIT" command) NT would then roll back all the
-deletes !!!</p>
-
-<p>This meant if the first e-mail was very large it might just end up
-continuously collecting it, basically jamming the queue. Or, if the
-queue became very full itmight never get a long enough phone
-connection to retrieve the entire mailbox, and NT would roll back any
-deletes, so it would end up collecting (and delivering) the first few
-e-mails again and again. As the POP3 mailbox became fuller and fuller
-the chances of getting a connection long enough to collect theentire
-mailbox became smaller and smaller.</p>
-
-<p>Our solution was to make fetchmail only collect a few (say 5 or 10)
-e-mails at atime, thus trying to ensure that the POP3 connection is
-terminated correctly.
-</em></p>
-
-<p>Unfortunately, this is exactly the way POP3 servers are supposed
-to behave on a line drop, according to the RFCs. I recommend
-switching to IMAP and using a short expunge interval.</p>
-
-<hr>
-<h2><a name="O10">O10. Why is the received date on all my messages the same?</a></h2>
-
-<p>This is a design choice in your MTA, not fetchmail. It's taking
-the received date from the last Received header.</p>
-
-<HR>
-<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: 2002/06/21 09:06:59 $
+Otherwise it is going keep increasing the packet counters that
+fetchmail relies upon, triggering fetchmail into polling after its
+own delay interval and thus preventing the pppd link from ever
+reaching its inactivity timeout.</p>
+
+<h2><a id="O9" name="O9">O9. Why does fetchmail keep retrieving the
+same messages over and over?</a></h2>
+
+<p>First, check to see that you haven't enabled the
+<cite>keep</cite> and <cite>fetchall</cite> option. If you have,
+turn one of them off - which one, depends on why they have been set in
+the first place, and to a lesser degree on the upstream server.</p>
+
+<p>This can also happen when some other mail client is logged in to
+your mail server, if it uses a simple exclusive-locking scheme (and
+many, especially most POP3 servers, do exactly that). Your
+fetchmail is able to retrieve the messages, but because the mailbox
+is write-locked by the other instance yours can neither mark
+messages seen or delete them. The solution is to either (a) wait
+for the other client to finish, or (b) terminate it.</p>
+
+<h2><a id="O10" name="O10"><strike>O10. Why is the received date on all my
+ messages the same?</strike></a></h2>
+
+<p><em>The answer that used to be here made no sense and was dropped.</em></p>
+
+<h2><a name="O11">O11. I keep getting messages that say "Repoll
+immediately" in my logs.</a></h2>
+
+<p>This is your server barfing on the CAPA probe that fetchmail sends.
+Because some servers like to drop the connection after that probe,
+fetchmail will re-poll immediately with this probe defeated.</p>
+
+<p>If you run fetchmail in daemon mode (say "set daemon 600"), you will
+get the message only once per run.</p>
+
+<p>If you set an authentication method explicitly (say, with
+<code>auth password</code>), you will never get the message.</p>
+
+<h2><a name="O12">O12. Fetchmail no longer expunges mail on a 451 SMTP response.</a></h2>
+
+<p>This is a feature, not a bug.</p>
+
+<p>Any 4xx response (like 451) indicates a transient (temporary) error.
+This means that the mail could be accepted if retried later. Lookup
+failures are normally transient errors as a mail should not get
+rejected if a dns server is unreachable or down.</p>
+
+<p>A permanent reject response is of the form 5xx (like 550).</p>
+
+<p>You could tell your SMTP server to not lookup any addresses if you are
+not keen on checking the sender addresses. This problem typically
+occurs if your mail server is not checking the sender addresses, but
+your local server is.</p>
+
+<p>Or you could declare <code>antispam 451</code>, which is not
+recommended though, as it may cause mail loss.</p>
+
+<p>Or, you could check your nameserver configuration and query logs for
+dns errors.</p>
+
+<p>All these issues are not related to fetchmail directly.</p>
+
+<h2><a name="O13">O13. I want timestamp information in my fetchmail logs.</a></h2>
+
+<p>Write a <code>preconnect</code> command in your configuration file that
+does something like "date >> $HOME/fetchmail.log".</p>
+
+<h2><a name="O14">O14. Fetchmail no longer deletes oversized mails with
+--flush.</a></h2>
+
+<p>Use <code>--limitflush</code> (available since release 6.3.0) to
+delete oversized mails along with the <code>--limit</code> option. If
+you are already having <code>flush</code> in your rcfile to delete
+oversized mails, <em>replace</em> it with <code>limitflush</code> to
+avoid losing mails unintentionally.</p>
+
+<p>The <code>--flush</code> option is primarily designed to delete
+mails which have been read/downloaded but not deleted yet. This option
+cannot be overloaded to delete oversized mails as it cannot be guessed
+whether the user wants to delete only read/downloaded mails or only
+oversized mails or both when a user specifies both
+<code>--limit</code> and <code>--flush</code>. Hence, a separate
+<code>--limitflush</code> has been added to resolve the ambiguity.</p>
+
+<h2><a name="O15">O15. Fetchmail always retains the first message in the
+ mailbox.</a></h2>
+
+<p>This happens when fetchmail sees an "X-IMAP:" header in the very
+first message in your mailbox. This usually stems from a message like
+the one shown below, which is automatically created on your server. This
+message shows up if the University of Washington IMAP or PINE software
+is used on the server together with a POP2 or POP3 daemon that is not
+aware of these messages, such as some versions of Qualcomm Popper
+(QPOP):</p>
+
+<blockquote>
+<pre>
+From MAILER-DAEMON Wed Nov 23 11:38:42 2005
+Date: 23 Nov 2005 11:38:42 +0100
+From: Mail System Internal Data <MAILER-DAEMON@imap.example.org>
+Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA
+Message-ID: <1132742322@imap.example.org>
+X-IMAP: 1132742306 0000000001
+Status: RO
+
+This text is part of the internal format of your mail folder, and is not
+a real message. It is created automatically by the mail system software.
+If deleted, important folder data will be lost, and it will be re-created
+with the data reset to initial values.
+</pre>
+</blockquote>
+
+<p>As this message does not contain useful information, fetchmail is not
+retrieving it. And deleting it might slow down the server if you are
+keeping messages on the server, and the server would recreate it
+anyways, that's why fetchmail does not bother to delete it either.</p>
+
+<h2><a name="O16">O16. Why is the Fetchmail FAQ only available in
+ ISO-216 A4 format? How do I get the FAQ in Letter format?</a></h2>
+
+<p>All the world uses ISO-216:1975 "A4" paper except for North America.
+Using A4 format reaches far more people than (formerly known as DIN A4,
+from DIN 476) format. Besides that, A4 paper <em>is</em> available in North
+America.
+For further information on the Letter-vs-A4 story, see:</p>
+<ul><li><a href="http://www.cl.cam.ac.uk/~mgk25/iso-paper.html">Markus
+ Kuhn: "International standard paper sizes"</a></li>
+ <li><a
+ href="http://betweenborders.com/wordsmithing/a4-vs-us-letter/">Brian
+ Forte: "A4 vs US Letter"</a></li></ul>
+
+<p>Offering the document formatted for two different paper sizes would
+bloat the package beyond reason, and formatting in a way that fits A4
+and Letter paper formats would be a waste of paper in most parts of the
+world. For that reason, fetchmail only ships with an A4 formatted PDF
+document.</p>
+
+<p>To create a letter-sized PDF, install <a
+ href="http://www.htmldoc.org/">HTMLDOC</a>, edit
+<code>fetchmail-FAQ.book</code> in the source directory with your
+favorite text editor, replace <samp>--size A4</samp> by <samp>--size
+ letter</samp>, and type:
+</p>
+<pre>
+make fetchmail-FAQ.pdf
+</pre>
+
+<h2><a name="O17">O17. Linux logs "TCP(fetchmail:...): Application bug, race
+ in MSG_PEEK."</a></h2>
+<p>That's in fact a bug in Linux kernels around the late 2.6.2X versions,
+rather than fetchmail. Fetchmail has no race bugs around MSG_PEEK,
+as of version 6.3.9. The message can safely be ignored.</p>
+<hr/>
+
+<table width="100%" cellpadding="0" summary="Canned page footer">
+<tr>
+<td width="30%">Back to <a href="index.html">Fetchmail Home
+Page</a></td>
+<td width="30%" align="right">$Date$</td>
+</tr>