Tara sent me a link a few months ago about offlineimap, at a time when I was tinkering with an unrelated e-mail tool. I can say up front that I can see the potential in this.
If I understand it right, this would allow you to synchronize a remote mail directory — something like GMail, as above — to a local folder, and then use a traditional mail reader, like mutt, to … well … read your e-mail. 🙄
If that’s the case then I may have found a way around my usual need for a locally built e-mail system, and I can start whacking away at other e-mail tools that don’t really apply to Web-based services.
On the other hand, I’m not sure where offlineimap will help with sending e-mails, although I haven’t really worked much with it beyond what you see above. Science demands an answer.
Something tells me offlineimap has some sort of provision for that. It is, after all, 12 years old.
Sending or receiving, the first place to start would be (and was) the Arch wiki, which has plenty of sample configurations and a special one just for GMail accounts … which worked more or less perfectly for me. I’m such a copy-paster. 😳
Just for future reference, or if you want to tinker with offlineimap too, here’s what I used:
[general]
# List of accounts to be synced, separated by a comma.
accounts = gmail-remote
[Account gmail-remote]
# Identifier for the local repository; e.g. the maildir to be synced via IMAP.
localrepository = main-local
# Identifier for the remote repository; i.e. the actual IMAP, usually non-local.
remoterepository = gmail-remote
# Status cache. Default is plain, which eventually becomes huge and slow.
status_backend = sqlite
[Repository main-local]
# Currently, offlineimap only supports maildir and IMAP for local repositories.
type = Maildir
# Where should the mail be placed?
localfolders = ~/.mail
[Repository gmail-remote]
type = Gmail
remoteuser = k.mandla@gmail.com
remotepass = password
nametrans = lambda foldername: re.sub ('^\[gmail\]', 'bak',
re.sub ('sent_mail', 'sent',
re.sub ('starred', 'flagged',
re.sub (' ', '_', foldername.lower()))))
folderfilter = lambda foldername: foldername not in '[Gmail]/All Mail'
# Necessary as of OfflineIMAP 6.5.4
sslcacertfile = /etc/ssl/certs/ca-certificates.crt
You will, of course, have to adjust that to your liking. And I’m sure that could be streamlined a bit.
I can’t say if offlineimap is any better or worse than anything else available; I do see a lot of Remy’s NoPriv.py in this too though. Perhaps the two are not dissimilar.
I intend to come back and take a look at offlineimap again sometime soon. I can’t say for sure why — I just have a hunch that it will be useful in the months and years to come. 😐
Inconsolation 
Of course, IMAP has nothing to do with sending mail*, so unsurprisingly neither does offlineimap. IMAP is only used to access and organise mail stored on a remote server**, and offlineimap is just a tool to keep a local copy of the same mail in sync – useful in situations where you are not always online, your mail client’s IMAP implementation is flaky / non-existent, or just for backups.
Sending is always configured separately from receiving in your mail client because it uses a completely different protocol (usually SMTP) – your client may have some built in capability to talk that protocol, or it may call out to yet another external tool, such as msmtp, sendmail, etc.
* to be fair there are some extensions to the IMAP protocol that can allow it to send email (well, sort of anyway – so long as you ignore the fact you are still talking to an SMTP server to actually send the mail, but that it fetches the mail from the IMAP server you just uploaded it to instead of having to send it to two separate servers… and yes, this STILL doesn’t fix the problem that your connection can drop out at an unfortunate moment while “sending” an email and have it appear to succeed, have a copy in your “sent” folder (or worse – nowhere), but that the email didn’t actually get sent because those two actions are completely separate and there is no concept of having a transaction that covers the entire act of sending an email built into the protocol(s). Honestly email is pretty poorly designed, but then what do you expect – it’s a 30 year old technology we’re keeping together with spit and duct tape. And spam).
** in contrast to POP3 which is used to download the mail from the remote server, typically DELETING it as it goes so you have the only copy locally.
Thanks, Ian. Educational as always. 😉
There is also a program called isync (the binary is mbsync) which does the same thing but is written in C. I find it to be much less taxing on my cpu and quite a bit faster overall.
http://isync.sourceforge.net/
Pingback: sup: My pet procrastination | Inconsolation
Pingback: isync: Because the cloud is unreliable | Inconsolation
Pingback: lumail: You can probably do better | Inconsolation
Pingback: lumail: You can probably do better | Linux Admins
Pingback: notmuch: “Not much” is relative | Inconsolation
Pingback: alot: With notmuch help involved, and little more | Inconsolation