[Dovecot] revision control on maildir possible?
Hi,
I was wondering if it is possible to put a dovecot managed maildir under a vcs like system, for example git or bzr. I'd like to have a seamless history of all mail going in and out of my mailboxes, so a vcs like system seams a good choice for me. I'm not quite sure however if that would cause any problems to dovecot and what the best way of handling commits would be.
If anyone on the list got any pointers regarding this, it would be much apprechiated.
Best regards, Markus
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser
On Sunday 14 February 2010 11:26:17 Markus Beyer wrote:
Hi,
I was wondering if it is possible to put a dovecot managed maildir under a vcs like system, for example git or bzr. I'd like to have a seamless history of all mail going in and out of my mailboxes, so a vcs like system seams a good choice for me. I'm not quite sure however if that would cause any problems to dovecot and what the best way of handling commits would be.
If anyone on the list got any pointers regarding this, it would be much apprechiated.
If thats not a secret, what is the reason why you can't be sure of things with just attaching a trusted timestamp header for each mail? Someone could edit or delete those mails? Well, if you'd be using a LDA like maildrop, you could easily just call some bash script or direct command to make a new commit as your VCS provide... After each newly arrived message. (I don't know about moved / deleted messages hooks!) But... That is quite a heavyweight solution. Can there be any other reason to use it than because someone could delete or change a mail without your knowledge?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, 14 Feb 2010, Markus Beyer wrote:
I was wondering if it is possible to put a dovecot managed maildir under a vcs like system, for example git or bzr. I'd like to have a seamless history of all mail going in and out of my mailboxes, so a vcs like system seams a good choice for me. I'm not quite sure however if that would cause any problems to dovecot and what the best way of handling commits would be.
Hmm,
- avoid to create ".*" files in your Maildir base directory. I don't know bzr, but IMHO git creates a single .git directory, hence, you should create the repo at the same level as the Maildir, e.g.:
.git/ Maildir/ Maildir/new Maildir/cur Maildir/tmp
Subversion won't work, because it creates a .SVN directory in each versioned directory. They will be misunderstood as mailbox.
avoid to version the index files, they are binary anyway.
avoid the content of all tmp/ dirs.
Maybe: instead of to blacklist files, use a whitelist: anything in cur/ and new/, subscriptions, maildirfolder, dovecot-uidlist, dovecot-keywords,& others like .dovecot-shared, .dovecot-acl, sieve/ ...
message files are renamed, when their status or keywords / labels / tags change, either you live with these duplicates or you need to keep track of the filename changes by looking at the filename stem (up to, but not including the colon); some VCSs can keep track of filename changes. The same applies when messages are "seen" and moved from new/ to cur/.
when you move/copy messages around, you could track them by their message id, in order to avoid duplicates.
You can use a script to wrap deliver to trigger add/remove for the Maildir. But I think to schedule the sync would be better.
====
IMHO, if you want to avoid duplicates, a VCS does not seem to fit. Or you could delay the checkin for, say, one day, one could argue that then the messages are read, spooled in the "final" mailbox, tagged a.s.o.
Regards,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBS3z92r+Vh58GPL/cAQJrWQgAuO3Y/e48wZZKLk6XDd8SZfLUrDfl22Pr JSh/vTvf2LAK2qtI3l7H+c2VccDJpYkng4KZ0Qgb0Ty3F3Ws/siumB81uIrEHu4Y CoTg3h1TMi+HYhizGF4OQ6f2YB4ELkioE3h1qReYRN4YGemzlbLYQNbOBpo/8jkD AxVRmXwJC47Us9Q9Vf8zyL0SARkeRU5X1OJ4c4z7owp8PpG1zuquEjxjVSiGwzNi p8CW2fRlB9PIrMemENhnj9THCTKHW6EMcGf89BU1t2RxEOkGf9Y7EK0z9lRh3JpB rQJER6p4y61mGAoo5air70CIq50+xeJsyppNbCFaVYBJSTzHNKFD0Q== =arzl -----END PGP SIGNATURE-----
participants (3)
-
Kārlis Repsons
-
Markus Beyer
-
Steffen Kaiser