Outlook, Mozilla Mail, MBOX files and UW IMAPD

Posted: November 17th, 2003 | 3 Comments »

The horrific fiasco that was the AC/DC gig

(But I’ve posted this, information pills so I must be a LiveJournal)

Pointless Things I Learned The Hard Way, order #1: Suggesting to an Outlook 2000 user that you solve their mail problems by “just” moving them to IMAP is similar in scope to suggesting that you “just” nip out and invade Russia.
All the products that you see listed in the title of this entry (so as to shine a search-engine-friendly beacon to any other similarly lost souls) have colluded in their mutual umbrage to provide almost ten hours of support calls in a week and remind me that Just Is A Dangerous Word.

Let these wind-withered markings scratched in the cursed rocks act as guidance to those who feel they must descend into this particular ring of lemon-scented hell:

1: Mangled mboxes

Received wisdom says that the easiest way of converting Outlook mailboxes to UNIX-friendly mbox format is by using Mozilla Mail’s “Import” function. Unfortunately, received wisdom was clearly not looking particularly hard at the results, because the emitted From lines look like this

From - Tue, 6 Mar 2001 10:38:43

when they should, of course, look like this

From - Tue Mar 06 10:38:43 2001

(though, really, they should look like this

From SOMEUSER@SOMEDOMAIN.COM Tue Mar 06 10:38:43 2001

but UW IMAPD seems to be perfectly content with Mozilla deciding to discard email addresses willy-nilly, and one of the most important lessons here is that UW IMAPD is the boss of me.)

So, did you guess that Perl would come to the rescue? No? Godless heathen.


#!/usr/bin/perl -pi
s/[1532]+$//; # lose the ^M and ^Z chars
s/^From - (w{3}), (d+) (w{3}) (d{4}) ([d:]+)/"From - $1 $3 ".sprintf("%02d"
,$2)." $5 $4"/e;


There. Call that mozboxfix or something and just run it on any offending mailboxes to fix them in-place.

2: Taking out the trash

Based on the assumption that you can’t move your user to a better IMAP client because they have their entire life in that hideous piece of shit, it’s best to show them what to do when Outlook decides to corrupt its own IMAP cache files so that it crashes on boot. (Yes, it will do that. It did it at least three times for me, usually when I had the audacity to try and fix the user’s .mailboxlist file.)

Outlook will create a cache file for IMAP data that’s named after the IMAP server name, and store it either in C:Documents and SettingsUSERNAMEApplication DataMicrosoftOutlook or C:Documents and SettingsUSERNAMELocal SettingsApplication DataMicrosoftOutlook.
(This assumes that the user is running either Win2K or WinXP, their Documents and Settings folder is on C:, and that you have the sense to substitute USERNAME for their login name. If they’re running Win98 or WinME, it’s probably somewhere in the WINDOWSProfiles folder.)
Anyway, find that cache file and KILL IT WITH AS MUCH PREJUDICE AS YOU CAN MUSTER. It will be reborn, fresh and innocent, when you next restart Outlook.

Of course, there may be some pain saved by ensuring that the Outlook install in question is patched and updated to the hilt. All the goodies can be found via Slipstick.com’s excellent Outlook resource.

3: Make sure you understand IMAP

Years of tinkering with IMAP have taught me far more than I ever wanted to know about the .mailboxlist file (you need to understand that file if you’re administering IMAP, and certainly in this particular scenario), subscriptions, and why when you first use a new IMAP client it thinks that all of the files in your home directory are mail folders. Of course, I still don’t understand it, but I do now know the various things to start poking at when IMAP’s misbehaving. Here’s a good place to start with the basics of IMAP client setup. Now you have to teach most of that to your user while still trying to maintain that IMAP is the best way to manage their email. Have fun!

---