The problem likely has to do with the POP-3 LAST command. The LAST command
tells the
client what was the highest message number which has been accessed, i.e. it
tells you
which messages you've already seen. However, the LAST command was removed from
the
spec as of RFC 1725 (and the current standard). fetchmail still tries to use
this
command. If it can't, it tries to use the UIDL command and keep a local
database of
what messages have been seen. If you turn on -v for fetchmail you can watch what
commands it's trying to execute on the server. Note though that the UIDL
command is
specified by the protocol as option so your VMS POP-3 server may not even
implement
that, in which case fetchmail has no way of knowing which messages from the
server
you've seen and which you haven't.
The -k switch simply tells fetchmail not to delete messages from the server
after it
downloads them. From your description of the behavior this is working with
both
servers.
David Karlin wrote:
Hello,
I'm running exim/fetchmail on a slink box. I have a shell
account on a VMS machine which also holds my POP3 mailbox.
When I do fetchmail -k on my other POP3 box, any msgs
on the spool which I've already seen are not downloaded,
only the new ones which I've not yet read. None of the
messages are flushed. This the way that I thought the
-k switch is supposed to work.
When I do fetchmail -k for the POP3 box on the VMS
machine, all msgs in the spool are downloaded, whether
or not I've already seen them, but they aren't flushed.
So, fetchmail -k works differently on the two POP3
servers.
Has anyone else noticed this type of behavior?
Thanks,
--D
--
===
David Karlin
mailto:[EMAIL PROTECTED]
http://funk48.home.travelin.com
Powered by Debian GNU/Linux 2.1
===
--
Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
--
Jens B. Jorgensen
[EMAIL PROTECTED]
