On Monday 05 May 2003 13:48, David Krider wrote:
On Mon, 2003-05-05 at 12:40, David Krider wrote:
On Mon, 2003-05-05 at 10:52, Constant Brouerius van Nidek wrote:
Can that be solved with a command that I have overlooked?
Basically, everything below leads to: do a `fetchmail -v' and inspect the output. It may just be that your _server_ is the problem, and fetchmail might not be able to do anything about it...
From the fetchmail man page, under RETRIEVAL FAILURE MODES,
The normal mode of fetchmail is to try to download only `new' messages, leaving untouched (and undeleted) messages you have already read directly on the server (or fetched with a previous fetchmail --keep). But you may find that messages you've already read on the server are being fetched (and deleted) even when you don't specify --all. There are several reasons this can happen.
One could be that you're using POP2. The POP2 protocol includes no representation of `new' or `old' state in mes sages, so fetchmail must treat all messages as new all the time. But POP2 is obsolete, so this is unlikely.
Under POP3, blame RFC1725. That version of the POP3 pro tocol specification removed the LAST command, and some POP servers follow it (you can verify this by invoking fetch mail -v to the mailserver and watching the response to LAST early in the query). The fetchmail code tries to compensate by using POP3's UID feature, storing the iden tifiers of messages seen in each session until the next session, in the .fetchids 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.
Another 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 fetchmail 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.
Yet another POP3 problem is that if they can't make temp files in the user's home directory, some POP3 servers will hand back an undocumented response that causes fetchmail to spuriously report "No mail".
The IMAP code uses the presence or absence of the server flag \Seen 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 \Seen 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 fetchmail --keep will be both undeleted and marked old.
In ETRN and ODMR modes, fetchmail does not actually retrieve messages; instead, it asks the server's SMTP lis tener to start a queue flush to the client via SMTP. Therefore it sends only undelivered messages.
Whatever the possible reason may be from all of the above, it seems to me that if Kmail with 'do not delete' checked for a pop server works, why shouldn't fetchmail?
-- David "Dunkirk" Krider, http://www.davidkrider.com Acts 17:28, "For in Him we live, and move, and have our being." Linux: Will you use the power for good... or for AWESOME?