Version française
Home     About     Download     Resources     Contact us    
Browse thread
Some hints for Mbox-module signature
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Robert Roessler <roessler@r...>
Subject: Re: [Caml-list] Some hints for Mbox-module signature
Oliver Bandel wrote:

> Hello,
> 
> some weeks ago I wrote a small tool to clean up mbox-files,
> throwing out multiple mails of an mbox file (throw away
> mails with same body).
> 
> Now I just had the idea to write a module that can be used
> for more flexible programming then, not specialized to do
> one certain task on mbox-files. So, wheras the mentioned program
> only is used to throw away mails with same contents of the body,
> the Mbox-module should be useful for many tasks, e.g.
> selecting mails with a certain header-entry or body-contents
> or something like that (maybe, selecting by size).
> ... 
> If you have any suggestions, please let me know about it.

Well, there is *one* thing I have always wanted from my mail system - 
and never seen implemented: I basically like to save *all* emails from 
and to anyone I have a business relationship with... BUT, sometimes 
these mails have large (hundreds of KB -> a MB) attachments, which are 
not really important.  The mail itself, along with a small "ghost" of 
the attachment (name and size) would be enough.

I use Mozilla mail which I believe does use the mbox format, along 
with its own indices which it builds as required.  So, if using a 
utility once in a while to surgically remove some attachments means I 
would have to delete the indices and let Moz mail rebuild them, no 
problem.

So, as long as your module and its interface make it "easy" to write 
my own Higher Order Mail Functions (HOMFs) to accomplish tasks like 
the above, I will be happy to test it for you. :)

More seriously, it does seem as if something like the tasks I outline 
would exercise a goodly fraction of your proposed functionality.

Robert Roessler
roessler@rftp.com
http://www.rftp.com