Re-Plumbing Mail

Well, my home server has decided to start crashing randomly (could be mis-seated RAM, its innards clogged with dust, or pretty much anything else), so I decided to bite the bullet and toss everything inside my .

I decided to go about it the utterly paranoid way, so I plugged an external Firewire drive into it solely for the mail store and user data (that way, if the machine has issues, the disk is mountable somewhere else, and if the disk dies I'll just restore a backup).

The old machine was very noisy anyway, so despite the major hassle of re-configuring procmail, fetchmail, , etc., , not having something noisily sucking dust into itself 24/7 is bound to be an improvement.

Hopefully the 's fan will age more gracefully. Still, this means my two will be the only machines running in my house on a permanent basis from now on.

To move my IMAP accounts, I settled upon imapsync. Despite it being Perl-based and suffering from the usual "...and the kitchen sink" quagmire of CPAN dependencies, it is very straightforward to use once installed and seems to be coping well with the job of throwing gigabytes of mail around.

is throwing a fit, obviously, since it now has to update several hundred megs of cached messages (I don't let it store local copies of my whole archive, just my "current" account). imapsync's options to preserve IMAP metadata (IDs, dates, etc.) seem to help a bit, but I'm still trying out different approaches.

There's a lot to figure out (for instance, how to back up the whole thing, since the IMAP server I settled on - Cyrus - doesn't use mbox natively), but one thing I'm completely sure of: It's going to take a long while...

2.0 Beta

Still on the topic of mail - I must be one of the last people to post regarding this, but Scott Morrison's excellent 2.0 has just become a public beta.

I've been testing it for quite a few weeks (and occasionally pestering Scott regarding handling of my humungous IMAP archive), and share Melo's opinion that right now, it's much better (and vastly more useful) than the "enhancements" we've seen in 's .

One thing I like about it is that the approach Scott followed to perform IMAP tagging is pretty much future-proof - all my platforms can see the extra X-Keywords and X-Project headers, with the exception of the X-Mailtags header, which contains a serialized NSDictionary with -specific stuff - I'd love to have all the data as plaintext headers, but I'll take what I can get.

Knowing , 3.0 is bound to be crammed with dependencies, and I'm willing to bet that notes and other new features won't work properly across machines - which, considering I rely on IMAP storage for just about everything these days, makes it somewhat, er... unappetizing, to say the least.

Still, isn't perfect yet - there's a drawback I've been discussing with Scott, which is that adding plaintext tags via other applications doesn't work - won't pick them up.

Which means automatic tagging in procmail or in (which I've already tweaked to tag (all) items from given feeds with pre-defined tags) is impossible right now, which is kind of a downer - sure, this is not something most people will need, but my idea of doing Bayesian classification of RSS items (whenever I finally get around to ) could benefit from this tremendously.

Anyway - anyone know how to generate a NSDictionary-compatible serialized data stream in Perl or on a non- platform? Might be entertaining to explore while all my mail crawls from one machine to another...

This page is referenced in: