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 | -- http://mail.python.org/mailman/listinfo/python-list