Commercial or Famous Applicattions.?
martin at address-in-sig.invalid
Wed Nov 10 16:19:16 CET 2010
On Wed, 10 Nov 2010 13:59:02 +0000, Nobody wrote:
> On Wed, 10 Nov 2010 13:07:58 +0000, Martin Gregorie wrote:
>> FWIW the thing that really irritated me about fetchmail is the way it
>> only deletes messages at the end of a session and never cleans up after
>> itself. If a session gets timed out or otherwise interrupted the
>> messages that were read in it are left in the server's mail marked
>> 'read'. Subsequent sessions won't re-read them but won't go expunge
>> them either. This leads to a gradual build-up of read but not expunged
>> messages in the server's mailbox.
> The --flush option will delete any "seen" messages before retrieving new
...and is described as dangerous, can cause message loss in the man page
along with a warning to avoid including it as a permanent option - good
enough reasons for not using it IMO.
> The --fetchall option will retrieve both seen and unseen
Again, not useful as a permanent option since I don't want to receive
In both cases using them 'as required' requires:
(a) monitoring the source mailbox for 'read' message build up
(b) when 'read' messages are seen, executing a sequence of
run it for one retrieval session
change config back
restart using the normal configuration
That's far too much hassle to be part of SOP.
Now, if ESR had fixed fetchmail to tidy up after itself (if getmail can
do that, there's no reason why fetchmail can't) or had even added the
ability for a daily or weekly cron job to enquire about 'read' messages
and, if any are present, tell it to silently expunge them in a special
session, I'd probably still use it.
Without equivalent fixes its just a buggy bit of software, making getmail
a superior replacement because it 'just works'.
martin@ | Martin Gregorie
gregorie. | Essex, UK
More information about the Python-list