[MlMt] Local email archiving status/options?

[Benny Kjær Nielsen]

On 25 Aug 2015, at 12:33, Brian Scholl wrote:

> (I will also say that the degree of transparency available
> about the status of MM's development -- in Benny's many quick replies 
> in
> this list, plus the issue tracker -- seems like a *huge* plus.)

My Inbox seems to tell a story about an increase of 1-2 emails per day 
of “open” issues...

> I am facing a single roadblock, though, that is the lack of support 
> for any
> local message archiving.  Having read the list archives extensively, I 
> have
> the following two impressions:
>
> 1. A good number of people need/want this, in some form or another. 
> [...]
>
> 2. But the probability of Benny adding this option anytime in the
> foreseeable future seems to be somewhere between very low and zero. 
> [...]

Your impressions are (more or less) correct.

> [work flow]
>
> So my plea to the list members is just this: what are my best options 
> for
> doing this?
>
> 1. LOCAL EXPORT?
> Can I somehow export an IMAP folder from MM to any form of
> locally-accessible file/archive (such as an .mbox file)?  It appears 
> that
> this isn't possible, and this is what Benny isn't too keen on adding.

That is not correct. I have simply never implemented it. *Partly* 
because I suspect I'll have issues with the `.mbox` format which is not 
a well defined standard. I'm afraid no matter how I implement it then 
I'll have reports about it failing to be imported in some other app and 
in the end I'll need options for every variant of the `.mbox` format. 
But I won't really know before it's implemented. It might not be that 
bad.

Also, I mainly see the `.mbox` format as being about interoperability. 
 From the perspective of MailMate, it's an obsolete file format.

> 2. SNEAKY OFFLINE ACCESS TO MM'S LOCAL IMAP FILES?

*Don't do that.*

Emails are saved in a nice folder hierarchy in standard raw form. One 
file per email. But you should never move, delete, or assume anything 
about these files. It's just nice to know if something goes horribly 
wrong and you need direct access to the emails. (You won't of course, 
because they should all be on IMAP ;-) ).

> 3. RUNNING MY OWN MAIL SERVER?

Cons: Technically hard and if done on the local disk then it'll double 
the space usage. Pro: It works.

> 4. DIRECT EXPORTING TO EXTERNAL DATABASES/PROGRAMS?

You can enable some of these programs in the Bundles preferences pane. 
The main problem is to keep the mailbox name, but something could 
perhaps be done about that.

With the latest test version of MailMate you also have the option of 
simply exporting `.eml` files since emails can be searched via 
Spotlight. You could use mailbox rules to automatically save emails to a 
folder and delete them on IMAP, but (again) mailbox names might be a 
problem. It would be harder (but more flexible) to create a bundle 
command to do this. In fact, I should probably consider providing that 
by default.

> 5. LOCAL ARCHIVING TO MBOX FILES VIA A DIFFERENT EMAIL CLIENT?

I'll just skip that one.

> I really am keen to start taking advantage of all MM has to offer, but
> having some form of local archive is really non-negotiable for me.

Well, you already know that I always question this starting point... :-)

I think your best options are:

1. Force me to make exporting `.eml` files easier and then use Spotlight 
(or the Finder) to search locally archived emails.
2. Setup a dummy IMAP account in MailMate which is always offline and 
then see if you can use some variant of what I suggest in [this 
ticket](https://freron.lighthouseapp.com/projects/58672/tickets/733).

I hope this helps a bit.

-- 
Benny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freron.com/pipermail/mailmate/attachments/20150825/9aa3dd72/attachment.html>