Commercial or Famous Applicattions.?

Martin Gregorie martin at address-in-sig.invalid
Wed Nov 10 10:19:16 EST 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
> messages.
>
...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
> messages.
>
Again, not useful as a permanent option since I don't want to receive 
duplicated messages.

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 
       stop fetchmail
       alter configuration
       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
org       |



More information about the Python-list mailing list