Git Mail Discussion
mbox or maildir?
-- ?edward
Maildir. This works as well as it does on the basis of messages not actually changing all that much. You can automate commits and push/pull operations because you can trust that there's never really going to be a sticky or complicated merge. So git only has to worry about the tree, and moving files around, and not messing with the content of the files, which wouldn't be the case for mbox.
-- tychoish
This is super clever, but I can't help but think that really all you needed was a better IMAP server? I used to see the kind of flakiness you talk about back in 2001 or so, on UW-IMAP, and on Courier. But I've been running dovecot since, oh, 2004, or so, and I really haven't had any problems since.
IMAP is a very complex (some say overcomplex) standard, and most servers, and many clients don't properly implement their parts of it. But I think a lot of IMAP-hate is cached thoughts; people formed their opinions of it when the implementations available were much worse than the current ones.
-- jfm
I've definitely played with Dovecot configuration and setup in the last few years, but not actually used it consistently. My last real IMAP experience was in 2008/2009 using Google's IMAP service for gmail. The problems I had were: 1) if I sorted the mail on the server side using gmail's filters, the client I was using (Mail.app) couldn't easily or reliably track when new mail showed up in a folder. 2) Offline mail reading was difficult and often impossible. 3) If I accessed messages from more than one system, particularly if that system was going on-and-offline, I'd run into cases where I'd make a change (sometimes twice) and have the system undo the change because of some kind of syncing issue.
OfflineIMAP might solve some of those issue, but in general, I've come to prefer this solution because:
I know how it works, and I think it's pretty easy to understand particularly if you know how git works. I have no real understanding of how the IMAP protocol works, and I consider that to be a disadvantage.
Offline access is crucial for me, if not in actual day-to-day use, in the fact that I prefer to be able to unplug from the network for a few hours or a day without having all my work grind to a halt.
Multiple system use/concurrency is an issue for me. I definitely want to keep reasonably up to date copies of my email on two laptops (possibly more,) and I want to be able to switch machines with relative ease.
I don't want the IMAP server to be able to dictate how my Maildir's are organized, which can be a bit rough.
The mail clients I used when I started doing this (mutt) and the clients I use now (mutt and notmuch) which provide no real incentive to switch for me.
I'm willing to accept that Dovecot is good enough to satisfy these requirements, and/or that other people don't have the same requirements. How doe it fare against this use cause, in your estimation?
-- tychoish
Another thought I had: when I'm out and about, I'm constrained to relying on public WiFi for Internet connectivity. The standard configuration of public WiFi access points now seems to block IMAPS. This makes at least one excellent application (K-9 Mail) not very useful for me. Depending on how widely ssh is blocked, git-mail might be similarly constrained. My fallback has been to run roundcube webmail on my mail server, which then talks to dovecot. But that's a fairly ugly workaround.
-- jfm
Just to be fair, I've never had 22 blocked on a wifi network. It's very possible to run ssd's on ports other than 22, which works as long as the wifi doesn't block everything that isn't 80 and 443 (you could use 443... the chance of that being blocked is pretty low, but it means your server can't run SSL, which I think is probably not a huge loss.) Alternatively, all of my ssh traffic is or can be routed over an OpenVPN VPN, which as long as UDP 1194 (or whatever it is) is open, it's golden...
-- tychoish