offline-imap for backup (2010 edition)

[Anthony DiSante]

On 08/10/2010 06:53 PM, Ng Oon-Ee wrote:
> On Tue, 2010-08-10 at 22:30 +0200, Michael Williams wrote:
>> Has there been any changes to the suitability of offline-imap for backup (rather than bidirectional sync) since it was discussed on this list in 2007: http://thread.gmane.org/gmane.mail.imap.offlineimap.general/824/focus=835
>>
>> As discussed then, bidirectional sync risks user error/filesystem problems being catastrophically propagated upstream. A couple of rather hacky and fragile workarounds were suggested (including taking a backup of the backup, and checking the backup for changes since the last time offlineimap was run before allowing offlineimap to run again).
>>
>> It seems, however, that the most robust place to implement this would be in offlineimap itself. Any plans/news there?
>>
>> As far as I can tell, no other tool is ideally suited to this (see http://ask.metafilter.com/161868/IMAP-backup). imapgrab (a wrapper around getmail) comes closest, but does not retain read/replied/etc. flags, i.e. it is not an exact copy.
>>
>> -- Mike
>
> If you haven't noticed, the maintainer has announced his retirement from
> this project, and as yet noone else has stepped up to take over.
>

Well, I'd be interested in this one-way mode too.  I'm currently using 
offlineimap, both for backup, and for a way to get local copies of all my 
email for the purpose of running various scripts when certain emails come in. 
  I never modify the data directories, but I didn't consider the possibility 
of filesystem corruption causing problems to propagate up to the live mail on 
the server.

I haven't looked at the offlineimap code, and I'm more of a Perl hacker than a 
Python one; but doesn't it seem like, at least in theory, it'd be easy -- 
perhaps even trivial -- to prevent it from writing anything back to the server?

-- 
Anthony DiSante
http://encodable.com/
http://nodivisions.com/