Exporting your email from Mozilla Thunderbird to Microsoft Outlook

I am a lover of open source, so I really enjoyed using Mozilla Thunderbird and Calendar until we started using Exchange Server in our office and I stopped receiving mail from my CEO and our VCs. Everyone else was fine, mysteriously. So, I had to plug in to the Exchange Server and figured it was a good time to switch to M$ Outlook so I could also start sending an receiving calendar events.

Trouble is, you can’t export Thunderbird mail messages directly to Outlook. The help docs and various menus and screens create the appearance of a possibility, but after some investigation I realized this was all a ruse.

After some web searches for “import thunderbird mail into outlook”, I found this somewhat-informative page on the Tech Guy Support Forums and fiddled my way to a solution.

There seem to be two options:

  1. Daisy chain a series of compatible export-imports.
  2. Download and use some freeware from a the poorly named ‘Broobles’ website.

Ever the cynical hacker, I opted for the former option, which took a mere 4 hours to complete, mostly due to failed attempts. Here’s my course of action, in case you find yourself in this unhappy predicament.

Daisy chains work because Outlook can’t read Thunderbird messages, but Eudora can read Thunderbird, Outlook Express can read Eudora, and Outlook can read Outlook express. So let’s line em up and knock em down!

Update: Using Gmail instead

Peter emailed an alternative suggestion:

Um… couldn’t you have:

  1. Subscribed to a Gmail account
  2. Set up Thunderbird to read that Gmail account
  3. Set up Outlook to read that Gmail account
  4. In Thunderbird, dragged all the mail, folder by folder, from the local Thunderbird folders into Gmail
  5. Switched over to Outlook and dragged it out of Gmail to something in Outlook?

And instead of Gmail, an IMAP account would let you move multiple folders at once, no? Again, this should work with Gmail or really any IMAP account. Though maybe it’ll munge the dates? Of that I’m not sure.

Thanks Pete!

Setting Up: Prepping the nodes in your daisy chain

  1. Download a copy of Eudora. You can uninstall it later. Don’t worry, you only need the free version, and it’s fun to see the ads that get run.
  2. Make sure you have a copy of Outlook Express. AFAIK, you can’t uninstall it, it’s just always there on a Win box.

For both apps, don’t waste time configuring your mail accounts any more than is absolutely necessary for basic import/export functionality – you’ll only waste more time. When the apps launch they’ll try to get pushy and make you enter remote server information, passwords, usernames, and whatever else. Just cancel out of those screens.

This is a good time to unplug your phone and refill your caffeinated beverage.

A Quick Aside: WTF is %AppData%?

Note that as you go searching for various mail files, a lot of system help files will include paths with an unhelpful %AppData% string included.

In most cases, this translates to C:\Documents and Settings\[User Name]\Application Data, where [User Name] is the name you use when you log in to Windows. If your system is configured differently, you can find your %AppData% by:

  1. Clicking Windows Start menu (lower left of your desktop)
  2. Selecting the Run… option
  3. Typing %AppData% into the black window that appears, and pressing the Enter key.

You will see the file path that represents your %AppData%.

Diving In: Wasting the rest of your day

  1. First, a bit of housekeeping: having more folders in your email client will make this process slower, so I’d recommend consolidating as many of your folders as possible.
  2. Second, trust no one! Back up a copy of your email. It’s probably located someplace handy like:
    C:\Documents and Settings\[User Name]\Application Data\Thunderbird\Profiles\[random string].default
  3. Import your Thunderbird messages into Eudora:
    1. Click on the File menu
    2. Select Import…
    3. A dialog box will appear. Click the obscure little “Advanced” button in the bottom left
    4. Select “Netscape Messenger”
    5. Click “Browse…” to find your prefs.js file. Mine was at:
      C:\Documents and Settings\[User Name]\Application Data\Thunderbird\Profiles\[random string].default\prefs.js
      I left the LDIF file field blank – AFAIK, it doesn’t exist for Thunderbird (I even did a system search for *ldif* and only turned up some unrelated Sun files)

All this crap starts flying into Eudora, including a *lot* of duplicate folders! As far as I could tell, these folders were actual duplicates.

The first time I attempted this process, it didn’t work. This was because I store all my mail locally (in my C:\Documents and Settings\[User Name]\Application Data\Thunderbird\Profiles\[random string].default\Local Folders directory). To fix this, I had to copy all of my Local Folders contents into my mail directory (mine was called mail.[server name].com). In my case, the files were so big that I just removed the mail directory and renamed “Local Folders” to the old mail directory name, rather than waste time with copy/paste.

Once all of the mail is imported into Eudora, you have to make sure it’s all indexed. To do this, double-click on each folder in the left pane of the Eudora UI, so the messages appear in the main pane. This action builds some kind of index file (you’ll notice it hangs a bit on larger directories), without which Outlook Express cannot find the messages. I discovered this after cursing Outlook Express for only importing my Inbox, which I’d opened to confirm that Eudora had imported the messages from Thunderbird.

Once everything is indexed in Eudora:

  1. Launch Outlook Express.
  2. Try not to lick your lips in anticipation – they’ll get chapped.
  3. In Outlook Express, click on the File menu.
  4. Select the Import option
  5. Select Messages…
  6. You’ll see a list of options, with “Eudora Pro or Light (through v3.0)” conveniently listed at the top.
    (Don’t be distracted by the presence of “Netscape Communicator” farther down the list, it’s a trap!)
  7. When you click next, you’ll probably see a curiously grey input field, accompanied by nonsensical text. Click the Browse… button and go find your Eudora messages.
  8. If you’re as unfortunate as me, you’ll have forgotten that Eudora is filed under “Qualcomm”, so here’s a tip: your messages are probably located in a directory like

    C:\Documents and Settings\[User Name]\Application Data\Qualcomm\Eudora\Netscape Messenger.fol
    (there’s that %AppData% string, coming back to haunt us)
    Remember, you’re looking for Netscape Messenger mail, not Eudora’s naturally-occurring mail directories. If you open the directory, you should see some familiar-looking subdirectories (keep clicking around, they’re there). If you’ve indexed the folders correctly in Eudora, you should see a .toc (table of contents?) file for every .mbx (mailbox?) file.
  9. Click import, pray, and hopefully your messages appear inside Outlook Express!

Now launch regular old Outlook, and

  1. Select the File menu
  2. Select the Import and Export… option
  3. In the resulting screen, select Import Internet Mail and Addresses
  4. Select Outlook Express and click “Next >”
    (I got chickeny so close to the end, so I opted to “Allow duplicates to be created”.)

Then, bite your nails and wait. Hopefully, you see a bunch of mail flying into your Outlook, you’re done, and it’s almost time to go home for the weekend.

Some problems I noticed and read about

  1. Sometimes, one step in the chain fails. My advice is to just fiddle with the settings until you get it right, or try focusing on a single message or subdirectory of mail. Don’t call me.
  2. Eudora created a lot of unnecessary folders for me. I’d rather have dupes than lose mail, so I just sighed and accepted this as a fact of life.
  3. I only worked with a single Profile/Account. If you have more than one, it seems that the solution is to import one Profile at a time, then remove the files from Eudora. I have not tested this.

If all else fails, you do have an alternative option: save your messages as .eml files one at a time.

How to debug a page

Part of the fun of producing web pages and applications is that we get to be medicine men: wave our hands, write some code, and suddenly the Golem springs to life. The truth of the matter is that we’re closer to Ed Norton’s character in the beautiful but mostly pointless movie The Illusionist. Behind every stage trick is a logical (and sometimes overwrought) explanation. The only real mysteries lie within our own hearts and desires, and we can master our environments by recognizing the distinction between mind and machine.

For my part, I am mystified by engineers who use cajoling as a debugging tactic. These are the people who talk to their dev environments like Han Solo, begging more speed from the Millennium Falcon: “C’mon baby, work for me… (screen refresh)… nooooooo! Why god, why?!”

The very term “bug” bespeaks a rational attitude towards the initially inexplicable. Software presents an extremely controlled engineering environment, making scripting bugs even easier to detect than the original moth in the vacuum tube. When a hacker anthropomorphizes or spiritualizes their product, they’re ignoring that useful fact, abdicating responsibility for their domain and retreating into a comfortably passive mindset where success is incidental rather than created. They join the unwashed masses.

Rather than stare at tea leaves or rely on emotional appeals, two faster, more effective approaches to debugging simple scripts:

1. Start at the beginning of the script, and follow along until it breaks.

This is how many debuggers function, and it’s easily handled by adding alerts (JavaScript) or trace (ActionScript) calls into your code, line by line. Eventually, you’ll hit the point where the function doesn’t alert the expected information. Typically, there’s a breakdown in a call to another object – it doesn’t exist, or you’ve handled scope badly, or it lives in an unexpected form.

This technique is less useful when you have many scripts or functions interacting simultaneously or nesting, in which case you may want to try the second approach…

2. Observe the buggy behavior, and list the possible causes.

This is the Sherlock Holmes method – assume that you’re assuming something incorrect. This is an inverse approach to the first one: start at the broken output and work your way upstream. Define the buggy behavior and list all of the possible causes for that behavior. The trick is not to think within the constraints of the script as you understand it: instead of thinking “what could I have done to turn the screen blue?”, try “what are all of the possible ways to turn a screen blue?”

This is a great method for debugging CSS: IE is unexpectedly in quirks mode, an unexpected style rule is affecting a DOM node. It’s also useful for more complex UIs where multiple scripts are present. It’s not as useful when there are a lot of possible causes for the phenomenon (as in with a blue screen on a Windows machine).

That’s it. The theme between the two techniques is that you iterate through enlarging and reducing a list of possible causes until you strike upon a solution. No magic there, just a simple list edit.

Next time you see a bug, instead of wondering about the morality of the situation, pause and think “now how could that happen?” Usually, there’s an extra factor that you didn’t anticipate in your controlled environment. Identify it, change it, and listen to the peasants ooh and aah.

A Respectable Initial Sprint

Update: Respectr is live!

Huned and I sat down today to attempt to complete a Rails Web app. The bad news is that we didn’t finish, though we made some great progress. Rails is extremely fast – had we been working with a different hacker language like PHP, I think we’d have gotten bogged down in the details and lost focus.

We’re hoping to finish up the build this week, so we can dive into a private beta release, then jump to a public launch when we’re confident the code scales well.

Aside from the obvious “Rails is so fast” lessons, some other lessons we (re)learned were:

  1. Even with a team of two, a shared SVN repository and wiki sped our progress considerably.
  2. Dev environment setup, on the other hand, cost me two hours. Boo eclipse. I should

Simple QA Cheat Sheet

Testing a complex website or web-based application can become especially tedious when you don’t have a good sense of when you’re “done”. After working on several projects where I’ve either handled User Acceptance Testing personally or outsourced to a temp, I’ve come up with a baseline boilerplate QA checklist.

If you’re a web designer or project manager, it might provide a nice starting point for QA. If you’re non-tech person looking to evaluate a website, it’s a nice way to make sure all of the bases are covered.

Step 1: New Functionality

Review any specs, work orders, mockups, etc.

  1. Does the site/application perform the tasks as expected?
  2. Are emails sent or confirmation/error messages displayed as expected?
  3. Are records saved and calculations performed correctly?

Step 2: Design/User Interface

  1. Text
    • Spelling
    • Capitalization
    • Spaces
    • Abbreviations
    • Are dates and times formatted correctly? (Programmers have a tendency to leave unfriendly system-generated dates and times in
      an interface.)

    • No remaining greeking or “Insert text here” messages
    • Is all functional text logically written? (Intro text, field labels, helper text, error messages)
  2. Images
    • Are images sized correctly?
    • Are images compressed appropriately? Nothing looks too grainy?
  3. Branding
    • Are all copyrights, trademarks, etc., displayed correctly?
    • Do site colors match any style requirements?
  4. Colors
    • Are hyperlinks underlined or otherwise marked?
    • Are titles displayed prominently?
    • Is all body text legible?
  5. Layout
    • Are all page elements aligned correctly?
    • Are widths and heights set correctly?
  6. Cross-browser testing. I usually make sure all pages look good in these browsers:
    • Windows Internet Explorer 5, 5.5, 6, and now 7
    • Windows and Mac Firefox
    • Mac Safari
    • Opera (sometimes)
    • AOL’s Browser (sometimes)

Step 3: Functionality

  1. Check every link from every page (there are some free automated solutions for small websites)
  2. Does the HTML/CSS validate?
  3. Do pages render correctly or display appropriate error messages when browsers’ JavaScript and Plugins are disabled?
  4. Do all filters and table sorting options work correctly?
  5. Does the application function appropriately for different user states (logged-out, member, etc.)?
  6. Does the application handle invalid form input appropriately?

Step 4: Goldilocks

And finally, the grandaddy of of gotchas:

Zero, one, many

The basic idea is to fill every dynamic content block or form field with zero, one, or many items and make sure the system works well with all three
situations. Try too little, too much, and none at all. Oftentimes, we design an interface expecting just the right amount of content or data –
this is the time to look for all those weird edge cases.

That’s it! Let me know if you think of anything I could add to this list.