diff options
Diffstat (limited to 'fetchmail.man')
| -rw-r--r-- | fetchmail.man | 41 |
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 |