Hi there,
I just found what I think is a bug in 5.8.14's POP3 flush/keep behaviour.
I fetch my mail using "keep" and "uidl" in my ~/.fetchmailrc, and run a
script once a day that calls 'fetchmail -F' if the number of mails in my
mailbox exceeds a certain amount.
I recently upgraded from 5.8.[789] (don't remember exactly), and suddenly
received all my old mails again whenever the script that should flush my
mailbox was run. Running 'fetchmail -F -v' and checking the logs, I found
out that fetchmail did in fact flush my mailbox properly, but sent a RSET
just before sending QUIT to log off. This caused the POP3 server to undo/
forget about the previous DELEs, resetting my mailbox to its original (ie.
unflushed) state. The ~/.fetchids file did get flushed though, so the
next time fetchmail was run it saw all the old messages as new ones ...
Here's the relevant lines from the log:
Jul 18 08:20:32 sphere fetchmail[3936]: POP3< +OK GMX POP3 StreamProxy ready
<31906(_dot_)995437232(_at_)sproxy03>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jul 18 08:20:32 sphere fetchmail[3936]: POP3> CAPA^M
Jul 18 08:20:32 sphere fetchmail[3936]: POP3< -ERR Unknown command.
Jul 18 08:20:32 sphere fetchmail[3936]: POP3> USER *^M
Jul 18 08:20:32 sphere fetchmail[3936]: POP3< +OK May I have your password,
please?
Jul 18 08:20:32 sphere fetchmail[3936]: POP3> PASS *^M
Jul 18 08:20:32 sphere fetchmail[3936]: POP3< +OK mailbox has 225 messages
(1310866 octets)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jul 18 08:20:35 sphere fetchmail[3936]: POP3> STAT
Jul 18 08:20:35 sphere fetchmail[3936]: POP3< +OK 225 1310866
Jul 18 08:20:35 sphere fetchmail[3936]: POP3> UIDL^M
Jul 18 08:20:35 sphere fetchmail[3936]: POP3< +OK mailbox has 225 messages
(1310866 octets)
Jul 18 08:20:35 sphere fetchmail[3936]: POP3< 1
11280f6b777db6b211be6670bff9f747
[ ... ]
Jul 18 08:20:35 sphere fetchmail[3936]: POP3< 225
24006a8b496fec837c2bcbf5bc6dd88e
Jul 18 08:20:35 sphere fetchmail[3936]: POP3< .
Jul 18 08:20:35 sphere fetchmail[3936]: 225 messages (225 seen) for * at
pop.gmx.net (1310866 octets).
Jul 18 08:20:35 sphere fetchmail[3936]: POP3> LIST^M
Jul 18 08:20:35 sphere fetchmail[3936]: POP3< +OK mailbox has 225 messages
(1310866 octets)
Jul 18 08:20:36 sphere fetchmail[3936]: POP3< 1 62593
[ ... ]
Jul 18 08:20:36 sphere fetchmail[3936]: POP3< 225 3194
Jul 18 08:20:36 sphere fetchmail[3936]: POP3< .
Jul 18 08:20:36 sphere fetchmail[3936]: skipping message 1 (62593 octets)
flushed
Jul 18 08:20:36 sphere fetchmail[3936]: POP3> DELE 1^M
Jul 18 08:20:36 sphere fetchmail[3936]: POP3< +OK message deleted
[ ... ]
Jul 18 08:20:51 sphere fetchmail[3936]: skipping message 225 (3194 octets)
flushed
Jul 18 08:20:51 sphere fetchmail[3936]: POP3> DELE 225^M
^^^^^^^^^^^^^^^^
Jul 18 08:20:51 sphere fetchmail[3936]: POP3< +OK message deleted
^^^^^^^^^^^^^^^^^^^^^^^^^
Jul 18 08:20:51 sphere fetchmail[3936]: POP3> RSET^M
^^^^^^^^^^^^
Jul 18 08:20:51 sphere fetchmail[3936]: POP3< +OK mailbox has 225 messages
(1310866 octets)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jul 18 08:20:51 sphere fetchmail[3936]: POP3> QUIT^M
Jul 18 08:20:51 sphere fetchmail[3936]: POP3< +OK bye
Jul 18 08:20:51 sphere fetchmail[3936]: normal termination, status 1
Unfortunately I don't know whether this is actually a bug in fetchmail
or in GMX's (<http://www.gmx.net/>) POP server (call me RFC challenged
if you want :-), but the attached diff fixes the bug for me. YMMV.
HAND,
Thomas
--
=-------------------------------------------------------------------------=
- Thomas "ZlatkO" Zajic <zlatko(_at_)gmx(_dot_)at> Linux-2.2.19 &
Mutt-1.2.5i -
- "It is not easy to cut through a human head with a hacksaw." (M. C.) -
=-------------------------------------------------------------------------=
fetchmail-5.8.14-keep+flush-fix.diff
Description: Text document