Revise POP3 UIDL/LAST assertions in the manpage.

svn path=/trunk/; revision=4056

1 files changed, 14 insertions, 27 deletions

diff --git a/fetchmail.man b/fetchmail.man
index 893cc6f8..fdd349bf 100644
--- a/fetchmail.man
+++ b/fetchmail.man
@@ -446,7 +446,7 @@ than this size will not be fetched and will be left on the server (in
 foreground sessions, the progress messages will note that they are
 "oversized").  If the fetch protocol permits (in particular, under
 IMAP or POP3 without the fetchall option) the message will not be
-marked seen An explicit --limit of 0 overrides any limits set in your
+marked seen. An explicit --limit of 0 overrides any limits set in your
 run control file. This option is intended for those needing to
 strictly control fetch time due to expensive and variable phone rates.
 Combined with --flush, it can be used to delete oversized messages
@@ -1077,23 +1077,12 @@ representation of `new' or `old' state in messages, so \fIfetchmail\fR
 must treat all messages as new all the time.  But POP2 is obsolete, so
 this is unlikely.
 .PP
-Under POP3, blame RFC1725.  That version of the POP3 protocol
-specification removed the LAST command, and some POP servers follow it
-(you can verify this by invoking \fIfetchmail -v\fR to the mailserver
-and watching the response to LAST early in the query).  The
-\fIfetchmail\fR code tries to compensate by using POP3's UID feature,
-storing the identifiers of messages seen in each session until the
-next session, in the \fI.fetchids\fR file.  But this doesn't track
-messages seen with other clients, or read directly with a mailer on
-the host but not deleted afterward.  A better solution would be to
-switch to IMAP.
-.PP
-Another potential POP3 problem might be servers that insert messages
+A potential POP3 problem might be servers that insert messages
 in the middle of mailboxes (some VMS implementations of mail are
 rumored to do this).  The \fIfetchmail\fR code assumes that new
 messages are appended to the end of the mailbox; when this is not true
-it may treat some old messages as new and vice versa.  The only 
-real fix for this problem is to  switch to IMAP.
+it may treat some old messages as new and vice versa.  Using UIDL might
+fix this, otherwise, consider switching to IMAP.
 .PP
 Yet another POP3 problem is that if they can't make tempfiles in the
 user's home directory, some POP3 servers will hand back an
@@ -1101,14 +1090,16 @@ undocumented response that causes fetchmail to spuriously report "No
 mail".
 .PP
 The IMAP code uses the presence or absence of the server flag \eSeen
-to decide whether or not a message is new.  Under Unix, it counts on
-your IMAP server to notice the BSD-style Status flags set by mail user
-agents and set the \eSeen flag from them when appropriate.  All Unix
-IMAP servers we know of do this, though it's not specified by the IMAP
-RFCs.  If you ever trip over a server that doesn't, the symptom will
-be that messages you have already read on your host will look new to
-the server.  In this (unlikely) case, only messages you fetched with
-\fIfetchmail --keep\fR will be both undeleted and marked old.
+to decide whether or not a message is new.  This isn't the right thing
+to do, fetchmail should check the UIDVALIDITY and use UID, but it
+doesn't do that yet. Under Unix, it counts on your IMAP server to notice
+the BSD-style Status flags set by mail user agents and set the \eSeen
+flag from them when appropriate.  All Unix IMAP servers we know of do
+this, though it's not specified by the IMAP RFCs.  If you ever trip over
+a server that doesn't, the symptom will be that messages you have
+already read on your host will look new to the server.  In this
+(unlikely) case, only messages you fetched with \fIfetchmail --keep\fR
+will be both undeleted and marked old.
 .PP
 In ETRN and ODMR modes, \fIfetchmail\fR does not actually retrieve messages;
 instead, it asks the server's SMTP listener to start a queue flush
@@ -2242,10 +2233,6 @@ code in the kernel.
 The -f - option (reading a configuration from stdin) is incompatible
 with the plugin option.
 .PP
-The UIDL code is generally flaky and tends to lose its state on errors
-and line drops (so that old messages are re-seen).  If this happens to
-you, switch to IMAP4.
-.PP
 The `principal' option only handles Kerberos IV, not V.
 .PP
 Send comments, bug reports, gripes, and the like to the