Like Subversion which has two back-end types: BDB-based and File-based. Most email applications I seen are using database back-end, but the database is not so convenient to manipulate by end-user.

Currently I'm using Thunderbird, which also use database as back-end. I run Thunderbird in four machines, so there are 4 separate databases. And I have a lot of mail accounts, maybe 20 and more. (No, please don't tell me mail forward.) So, if the back-end is file-based, I can just setup a Git repository and synchronize them all. But Thunderbird has its internal database format, so it's very inconvenient to manage these separate databases.

  • 1
    A database would probably be much easier to manipulate than a set of files, if you have the tools to do so. I don't know any specifics, but I'd bet a lot of open-source mail clients are just using sqlite under the hood. Have you tried finding Thunderbird's actual data file and querying against it with sqlite? Commented May 21, 2011 at 6:42
  • Huh? The last time that I tried out ThunderBird, I definitely found that each message was stored in a separate file. In fact, plenty of the email clients that I tried were like this, include Windows Mail (and WMLive). (Though that’s not to say that they didn’t also create a bunch of other files and junk.)
    – Synetech
    Commented Jun 12, 2011 at 6:09

2 Answers 2


Maildir format for storing mail has been introduced that exacly does what you describe: one message is stored in one separate file.

And there are Maildir drivers (backends) for some mail clients, and some mail delivery agents, and some mail access servres (IMAP or POP or web interface).

Of course, if your mail is stored in Maildirs, it is most easy to put it under usual version control.

So, you can look for Maildir backends for mail clients.

But, actually, syncronizing your mail storage can be quite a bit more tricky than syncronizing directories of files -- because of various flags (new, read), labels, movements or copies of messages between folders, and--the most tricky part--the server-internal message IDs used by mail access servers (IMAP) or mail clients. What are these IDs about? Well, it's important to preserve IDs between several copies of your mail storage in order for, say, the caching procedure of your mail client to run correctly.

I have explored this issue and written down some notes here: research on HOW TO backup an IMAP account. (But then I didn't have to complete that task, so the notes and my practical solution wasn't complete.)

The general idea I have arrived at is that using a mail client and simply putting Maildirs under version control does not give you everything you might want from managing the revisons of your mail storage. It is better to combine it with real IMAP servers (either remote or local) for uniform access to the mail, and with special tools that run on top of IMAP for syncronizing different copies/repositories/branches of your mail storage (the special tools will take care of the flags, labels, IDs correctly). Usual version control is OK for inspecting the revisions and for reverting to a past revision, but for merging branches (= syncronizing) I'd consider a more complex procedure:

You want to merge branches A and B.

  • So you prepare the new state (revision) C that will hold the merged state by copying one of them, e.g., copy A to the new C.
  • Then you use a tool (like "imapsync"; choose the one that matches your needs; I have listed a few such tools in my notes) to bring the new changes from B to C: imapsync B to C.

(this might assume that you are accessing the mail storage via IMAP through a server)

  • Now commit C (as the result of merging A and B; before this, you might use an appropriate command in your VCS to write down the information that is the result of merging B to A, e.g., something like "git merge B -s ours --no-commit" in C).

Please explore the details yourself, I have only the general idea in mind, and I'm not running such a procedure in practice now.

I think this is a very interesting task to be done by usual well-known utilities, I'd like to hear more about successful setups to do this other people have come up with!

AFAIR I chose offlineimap for my task of backing up an IMAP account in Git. BTW here's an answer with an example configuration of offlineimap.


The best answer is to use a server designed for sharing email between clients - an IMAP server. Pretty much any email client will then be able to access the email on that server. You can set up your own, on ubuntu, or use Gmail, or if you're using an ISP for your email that ISP will probably allow IMAP access to your email there.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .