multimail: A rubberstamp endorsement

Looking back over the past week, I didn’t do as badly as I expected, considering my schedule. By calculations I owe a post each for Monday and Wednesday, so I’ll start with multimail.

 

There were two hurdles to the Debian version of multimail. The first is that, in a measure of infinite wisdom, the executable that is included in the Debian version is not called multimail, but is instead just mm. I lost 10 minutes this morning thinking the Debian package was just a bunch of configuration files. 😡

The second impediment, and then one I couldn’t clear myself, was to get mail packets in a format that multimail could swallow, and if the home page is any guidance, I was looking for any of about four different formats.

It may be possible to finagle something from Google in one of those formats, but all my attempts were left with garbled text or just general incompatibility. Of course, I do also have a track record for scrambling things before they ever get going.

In any case, I was running out of time on my multimail adventure, and attempts to glean help from the Internet ran dry when I realized there were dozens of unrelated projects named “multimail” out there, and were severely obscuring my quest.

So I’ll leave it to you to judge it on its actual usefulness; my intuition suggests it may be helpful to have a tool that will retrieve your e-mail from Google, if you also rely on GMail, and then step into multimail.

But that is a project for another day. For now I’m willing to give multimail a tentative gold star on just about every other point of evaluation: Full screen approach, keypress clues in plain sight, popup menus at every corner, gorgeous use of color (with drop shadows! 😀 ), extensive customizability and a decidedly friendly approach to mail reading. ⭐ And if you get it hooked into your GMail account, tell me how it worked. I’d like to try. 😉

isync: Because the cloud is unreliable

A while back I mentioned offlineimap, and Curtis mentioned isync in reply.

As you can see there, isync (or perhaps more accurately, mbsync) was quite willing to draw in more than 20,000 messages to my local hard drive. In that sense, isync did much as it was reported to do.

And considering I just stole a configuration file from Henrik Pingel, it was a piece of cake to get it working.

I’m no e-mail expert, but what that suggests is making a local backup of my cloud-based e-mail services is well within my grasp. Now I won’t have any more excuses for ignoring applications intended for organizing local e-mail collections. Darn. 😡

It also means that if you’ve come to distrust the pie-in-the-sky claims of the past decade — about cloud services being the wave of the future, and how everything will be online in the years to come — you can be a rebel, collect it all, and keep it locally. Print them out. Make a scrapbook. Invite your friends over for a party. 🙄

Of course, the real attraction in something like isync is to pair it with an outgoing message system, much like Ian described long ago, and put yourself in control of the entire process. Step up. Take responsibility. Clean up and move on. Go straight and choose life. 😉

I should mention that Henrik’s configuration will require you to put your password in plain text, unless you encrypt it in a separate file. I also noted that his default is to ignore some of the less interesting folders GMail uses by default — like sent mail or starred mail. Whether you include those in your e-mail coup d’état is up to you.

Personally I realize now the immensity of six or seven years of e-mail messages that are stashed on GMail’s servers, and that’s only one of my four or five accounts I use. I think maybe I shall save a little drive space for now, and let GMail wrangle all that for a while longer. … 😳

rdiffdir: A succinct sync

Forgive me if I jump slightly out of order. I wanted to work with rdiffdir today, and I promise to touch on rdiff-backup tomorrow.

Also please forgive me if I don’t have screenshots this time. I think I can adequately explain what’s happening, and rdiffdir isn’t particularly wordy.

I have practical experience with it, albeit a few years out of date. At a time when I quit lugging an ancient laptop back and forth to work to listen to music, rdiffdir made it easy to synchronize my main music archive at home with the remote one at work … without a network connection.

“What witchcraft is this?!” you might howl. I’ll give you the command sequence, and you work out what’s happening. Office machine first:

rdiffdir signature music/ music.signature

Then at home:

rdiffdir delta music.signature music/ music.delta

Carry that back to the office, and …

rdiffdir patch music/ music.delta

And that’s it (or at least what I remember of it). The signature command creates a distinct impression of what’s available on the office machine. The delta creates a file packed with changed material from the home machine, and the patch command merges it with the destination at the office again.

It’s very clever, really. What you avoid is rsyncing entire folders to USB drives, then USB drives to destination folders — hopefully saving time, and space on your intermediary drive.

I could see where this would also be useful for completely offline backups, where you want to preserve file arrangements and integrity on one machine with another that is completely disconnected. Which, in this day and age, isn’t a bad idea. 😯

rdiffdir is part of duplicity, which is available in Debian and Arch. Tomorrow, rdiffdir’s ugly kid brother. 😉

By the way, I should mention that everything I know about rdiffdir I learned years ago from this page. Credit where credit is due. 😀